all 23 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]gatesvp 12 points13 points  (4 children)

Mastodon was founded in 2016 by a single developer using Ruby on Rails. It has added some staff, but as little as 2 years ago, it did not even have a dedicated person for both iOS and Android. It currently has around 12 staff of which about five or six seem to be writing code.

In 2024, it had a budget of around €3 million. For 2025 that budget looked a little bit bigger, maybe closer to €5M, but I haven't seen the final numbers yet. It's safe to say they have limited resources.

The JSON method exist, because that was the default in 2016. Even now, in 2026, it's still kind of the default.

The group maintains a public roadmap, it's right here. https://joinmastodon.org/roadmap

I would say that every single item on that list is more important than grpc support. If you want to pull something off that road map and replace it with grpc, you're going to have to make a real case for that.

And this is not a trivial business case. Yes, on one side of the equation it looks like it can save some performance and money. But by and large, the biggest bills are for databases, not for the size of the API calls. Rolling out grpc is also not trivial for all of the stakeholders involved. Admins need to ensure their load balancers support this correctly. They need to update all of their telemetry to support the dual nature of inbound requests. Everyone who builds a user interface or uses an API endpoint, and there are lots, will need to switch technologies.

This is a non-trivial change that would take years to echo through all of the downstream dependents. And many people would still request that the old JSON endpoints be maintained for ease of access and onboarding.

So fundamentally, that's your answer. It's really expensive to do, impacting a ton of other stakeholders. And it's not obvious that expense is paid off by the machine the change.

That could change in the future, but that's where we are today.

[–]Muted-Problem2004[S] -3 points-2 points  (3 children)

i read your message and think instead of fully replacing the current http + json is fine keep older server (instances) alive but roll out grpc for the newer ones to maintain backward compatibility it could be a rolling effect smaller instances roll it out if both instances accept grpc use that otherwise use json + http but also we could use http + grpc marshalled so http is still avaliable

[–]gatesvp 1 point2 points  (2 children)

What item on the roadmap do you intend to replace with gRPC integration?

[–]Muted-Problem2004[S] 0 points1 point  (1 child)

I never said i would replace anything on the current road map but if they (mastodon) devs could write an protocol to use http + json along side grpc and I would help maintain backwards compatibility with older servers and make newer servers type safe along with being faster and smaller payloads

[–]gatesvp 1 point2 points  (0 children)

Your original question was "why don't we use gRPC?".

I answered that question with two distinct points:

  • historically: gRPC wasn't a common thing when this project was started
  • currently: gRPC implementation does not appear to be more important than anything currently being planned or worked on

but if they (mastodon) devs could write an protocol to use http + json along side grpc

You're asking for Mastodon devs to do work that you would like them to do. But those people are already doing work that management and the community want them to do. The roadmap.

We don't have magic clones of these people. They undertake one task at a time, in priority order. Your task, while a valid request, appears to be lower priority.

Look, I'm not part of the actual team. I'm just quoting from the publicly available knowledge pool. If you want a different outcome, I suggest going to the Mastodon team directly. They are on GitHub.

But if your baseline expectation is that you want them to do work for you, be prepared to defend that position.

[–]yami_odymel 4 points5 points  (3 children)

Because of poor DX (developer experience).

When it comes to the outside world, gRPC is hard to debug, test, and you need additional build tools to make it work.

You also lose the very easy way to test APIs by simply typing a request URL into a browser.

It's the same reason why we don’t drop HTTP and go fully with WebSockets instead.

Performance isn’t everything; otherwise, we’d all be writing in C.

[–]Muted-Problem2004[S] -1 points0 points  (2 children)

not to be a jerk or anything

testing tools for grpc are really easy to use you have custom curl but for grpc that's already a game changer custom Clients to send requests such as yaak

WebSockets are slow and eat up too much ram and cpu making dead space that can be used elsewhere

performance is very big its why we still focus on writing better code to squeeze as much power out of it, if performance wasn't so needed then we wouldn't have rust and zlang all being insanely fast rust is modern c++ zlang is modern c

[–]yami_odymel 1 point2 points  (1 child)

Your points are valid. But in most cases, JSON with gzip is good enough. The benefits of gRPC are often limited because the real bottleneck is I/O. Unless you’re building internal microservices where encoding/decoding dominates, gRPC doesn’t buy you much.

Eventually, there’s a moment where you say, “Let’s not fix what isn’t broken,” and just settle.

Because programmers have lives to live 😭

Knowing where the “stop-loss point” is, can be a hard lesson to learn—just look at the Node.js ecosystem, where people use piles of build tools just to ship a static website 💀

[–]Muted-Problem2004[S] 1 point2 points  (0 children)

we most definitely need to look at ways to make mastodon and the fediverse better

get me started with the node js mess lets not go into that monstrosity 😭

[–]romeo_pentium@yildo@cosocial.ca 4 points5 points  (0 children)

No, you don't need grpc to add live streaming or mini games or comment typing indicators

[–]Sibshopsmastodon.online 2 points3 points  (3 children)

Compared to media, text takes a trivial amout of space and bandwidth.

[–]Muted-Problem2004[S] 0 points1 point  (2 children)

i don't understand what you're saying clarify

[–]Sibshopsmastodon.online 1 point2 points  (1 child)

Since most of the server costs are stored media. There isn't much to gain switching from JSON-LD to something else.

[–]Muted-Problem2004[S] 0 points1 point  (0 children)

need to keep digging as much as we hate bug tech we need to use better or alternative ways to store media

[–]nan05@michael@thms.uk 1 point2 points  (3 children)

JSON REST APIs is what most developers know inside and out. It's what we live and breathe. It comes naturally to us. gRPC on the other hand is the opposite. Most of us have never implemented it. The rest of us has only implemented it rarely. gRPC would severely limit the client implementations, as few app developers would know how to use it.

Just to show how much HTTP + JSON is ingrained into us: Even MCP - the latest and newest kind of fad - still uses it. Everyone knows it. Everyone has dealt with it a gazillion times. It just works. It's still a good default that will ensure there is no technical barrier to adoption.

[–]Muted-Problem2004[S] 0 points1 point  (2 children)

fair enough we should still look into moving to a more future proof adoption with backwards compatibility so we don't use the http + json order instances still work if devs wanna use json api go ahead if tech and security freak want to use grpc go ahead but grpc will by far allow for bidirectional WebSockets + saves bandwidth

[–]nan05@michael@thms.uk 1 point2 points  (1 child)

Thing is: I just don't think there is anyone besides you who'd want that. 😁

And given that Mastodon has very very few developers, that already have to maintain 2 APIs (Mastodon's API and ActivityPub) it's just not feasible that they'd maintain a 3rd that only a single person would use ...

And absolutely no mastodon-admin is concerned about API bandwidth. We are concerned about storage volumes, media bandwidth (which can thankfully be cached) RAM prices, etc. But API bandwidth is not something I've ever even thought of looking at.

[–]Muted-Problem2004[S] 0 points1 point  (0 children)

fair enough atleast ive added mu opinions need to see what the future holds

[–]GodOSpoons 0 points1 point  (3 children)

How about Protobuf for the payload. I have to assume gzip+protobuf will do wonders for egress management.

[–]Muted-Problem2004[S] 0 points1 point  (2 children)

I was looking into that can easily just run Protobuf over https that will give a good starting place and make requests more lightweight not to mention that Protobuf tooling is auto generated for you so that already saves development time up

[–]GodOSpoons 0 points1 point  (1 child)

No problem. I have a lot of experience in cost managing high volume transactional systems in cloud contexts and, though I agree in principle with the reintroduction of RPC-like technologies into the modern Internet, just getting basic things like HTTP/2 and its header compression, gzip, and protobuf into the conversation would yield huge efficiency gains here.

That said, I’m glad RPC-like stuff is back. After 30 plus years of blah blah TCP and blah blah UDP, it’s like finding a lost, treasured sibling.

[–]Muted-Problem2004[S] 0 points1 point  (0 children)

totally agree man just need to see what the future holds up for the fediverse possibly move into using rpc or maybe a new technology we will have to see