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/?)
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/?)
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/?)
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/?)
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/?)
"... 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)
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
Ideally an AP 2.0 would include a formal mechanism for protocol extensions. One that learns from the experiences of the FEP process.
This is a bonfire demo instance for testing purposes