A major difference between the #ActivityPub federation and the #BlueSky#Atproto (#Atprotocol) federation is that under AcitivityPub, used by Mastodon, all servers that need to send or receive data from other servers need to make direct connections to each other. This means many queued jobs and many connections, maybe thousands. This leads to the classic sidekiq queue problems when Mastodon instances have numerous users with numerous follows, and relays.
In contrast, in atproto, the user's PDS, Personal Data Server, doing equivalent work of a Mastodon server, for example, only makes a few connections to the relay server's fire hose to deliver and pick up messages. It never connects to any other PDS directly. Theoretically, a tiny #PDS on atproto can handle a considerable number of users. This seems to be an advantage.
Mastodon admins spend a lot of time and money fighting performance issues, database connection counts, and sidekiq queues because the server has to talk directly to other servers. But the PDS only needs to talk to maybe one, or possibly a few relays to get and send messages.
Here's a diagram of the atproto architecture. It appears quite a simple architecture.
@admin I think the potential problems of the ActivityPub architecture are non-existent with smaller instances. The compute required for a few people is negligible and has the benefit of not needing to rely on an external entity for service.
@Jeremiah@admin Also, the perf issues with Mastodon are just that: perf issues with Mastodon, a thing that runs on Rails. If someone has a huge following such that heavy fanout is needed, there are (much) more efficient AP implementations out there.
@admin Thanks - super-interesting discussion. I've been spending my weekends trying to understand the key technical differences between the main protocols. Do you get the sense that if Mastodon were to reach huge scale, their architecture (without relays) would be able to support large volumes of posts (say, similar to that on Twitter in its heyday), or would that structure cause major slowdowns?
I agree that there is a natural limit on how quickly people can read new posts, but I'm not so sure that people will be satisfied with a slower feed-refresh rate than they're used to on Twitter. Especially in use-cases such as breaking news, I think people like the feeling of being on-the-pulse. It's ay have been caused by some other bug, but I've noticed periods on .social where I'm already experiencing a lag of several minutes.
It's not a perfect replacement for ActivityPub. Nobody, other than a corporation or rich dude, can run relay servers. So, yes, those who want nothing at all to do with a corporation or the rich person handling their messages will be better served on Mastodon.
Those who just want to keep their own personal data and identity away from corporations will be fine with the Bluesky architecture, where they have their own personal PDS or use a volunteer hosted PDS. This way, their private keys are not held by the corporations.
Neither have privacy, btw. I can read anyone's messages on Mastodon, even if they block me, by simply requesting their RSS feed. It's the same for Bluesky. I wager Meta is already scraping messages and trying to match users to Facebook and Instagram accounts. Some may not feel there is extra risk then having their messages handled by a relay. Others will disagree.
There are other differences too that matter to people. All messages and people are searchable on atproto because of the relay, but not so with ActivityPub. Stuff like this.
But, you are right. ActivityPub is more independent of corporations and for those for whom this matters, the choice is obvious.
Add comment