This article sets out to compare ActivityPub and ATProto, but what it really compares is Mastodon and BlueSky;
It is useful however as a 'user story' about the failure modes of the existing, Mastodon-dominated fediverse.
(1/?)
Discussion
Loading...
1) WebFinger IDs that tie accounts to domain names
These were part of OStatus, and Mastodon continued to support them when it implemented AP. With Mastodon servers as the majority of the AP network, other software was expected to keep using them too.
But BS style IDs are just as compatible with the AP spec. Also, as Takahē demonstrated, one AP server can support IDs using more than one domain name. Enabling the same BYOD (Bring Your Own Domain) that BS offers.
(2/?)
2) Admin Wars fragmenting the network. See the campaign against federating with Meta's Chains, or the recent drama around the political views of one Fosstodon mod.
This is a political problem more than a technical one. But there are forms of network management that could reduce the churn. I laid out a proposal here for a numbering scheme that could automate a lot of moderation work, allowing human mods to spend more time considering edge cases together;
https://codeberg.org/fediverse/fediverse-ideas/issues/88
(3/?)
3) Large Mastodon servers are expensive to host
The solution to this is a fediverse made up of many more, smaller servers. With more people actively involved in the governance and funding of the server they use. As well as using AP software other than Mastodon;
https://delightful.club/delightful_fediverse_apps/
Almost all of which makes much more efficient use of server resources than Mastodon's creaking Ruby-on-Rails backend.
(4/?)
Or as technomancy ( @technomancy?) put it;
"... for the Fediverse to be viable it has to move beyond Mastodon. Luckily this is already happening. My home Gotosocial instance federates with over 7000 servers and only peaks over 300MB ram when it’s processing media. Only rarely can I catch it showing up in top because its CPU usage is negligible.
... the greatest challenge to a growing, healthy Fediverse is overcoming the inertia of Mastodon."
https://lobste.rs/s/thsv0z/conceptual_model_atproto_activitypub#c_gmeahq
4) Full account portability
This is probably the most important differences between what BlueSky is pitching and what Mastodon offers. Fediverse apps like Hubzilla have offered this with Zot-only features like NomadicIdentity and ChannelCloning;
https://wedistribute.org/2024/03/activitypub-nomadic-identity/
Some work has been done to document how this could work with AP, in the form of various as FEPs;
https://wedistribute.org/2024/03/extending-activitypub/
(5/?)
Like Christine, I think the future of the fediverse will look quite different to the current Mastodon-dominated network, and more like the user experience offered by BS;
https://dustycloud.org/blog/how-decentralized-is-bluesky/
The raw materials already exist to build this evolution of the verse. The question is, how do we pull it all together?
(6/6)
@strypey my feeling is we haven't yet begun to see what a fully developed #fediverse looks like (including in this definition #atproto, decentral/distributed protocols but also forgotten "low-tech": anything that can be interoperable)
The current adoption landscape ( #rss, #bluesky, #mastodon) highlights various technical possibilities but doesnt span whats possible, nor what is needed.
These three datapoints define a plane of possibilities but the actual space is probably much bigger.
Or as technomancy (@technomancy?) put it
"... for the Fediverse to be viable it has to move beyond Mastodon. Luckily this is already happening. My home Gotosocial instance federates with over 7000 servers and only peaks over 300MB ram when it’s processing media. Only rarely can I catch it showing up in top because its CPU usage is negligible.
... the greatest challenge to a growing, healthy Fediverse is overcoming the inertia of Mastodon."
https://lobste.rs/s/thsv0z/conceptual_model_atproto_activitypub#c_gmeahq
Coda: The growth of BlueSky, and the novel features it launches with, point to a need for a 2.0 version of ActivityPub. One that fleshes out and updates the protocol based on dev experiences in the first decade of active use, and intentions going forward.
Ideally an AP 2.0 would include a formal mechanism for protocol extensions. One that learns from the experiences of the FEP process.
2 more replies (not shown)
I'm still on a billion block lists and everyone just auto-imports them and so I'm automatically blocked for new people who startup an instance and just think of a blocklist as some kind of standard anti-spam measure.
Proposal seems interesting, but it's not going to change all the existing blocklists and just kinda adds a shitty BluCry style moderation standard with extra steps.
Honestly, Nostr seems to have the best design when it comes to censorship and resiliency.
Proposal seems interesting, but it's not going to change all the existing blocklists and just kinda adds a shitty BluCry style moderation standard with extra steps.
Honestly, Nostr seems to have the best design when it comes to censorship and resiliency.
Bonfire
This is a bonfire demo instance for testing purposes
Automatic federation enabled