Three federated social media protocols are vying for users. They are ActivityPub (Mastodon), ATproto (Bluesky) and Nostr.
Nostr is the simplest with best data ownership story, ATproto is most sophisticated and scalable, while ActivityPub is most mature, but also most complex.
I explore and think about their approaches, features and limitations from the point of view of an individual user considering sharing one’s own content.
Activity Pub protocol - Mastodon
Background
I moved out of Facebook in 2023 and have since on-boarded a smallish freedom of speech oriented Mastodon server.
While each server has its own policy on content moderation, these separate policies are also applied across server lines. Server A owner can ban entire server B, can ban a number of accounts on server C and thus hide content from thousands of their own server A users. For the largest of servers such as mastodon.social, this amounts to Facebook-like content moderation powers.
This often ideologically motivated over-banning of servers, is the weakness of Activity Pub and source of concerns for freedom of speech.
Tech
Activity Pub is a many-to-many distributed push-pull mesh of servers which exchange posts, likes and follow requests. Users are IDs within each server and subject to server rules. Modulo blacklists and shadow bans, one can access posts of any other user on any server transparently. In this respect each server is monolithic and provides all services for its users and interacts on their behalf with external servers. Client applications connect to server with one’s ID and through it interact with the entire federated network.
Activity Pub is based on JSON messages and can be thought of as a bidirectional RSS with push support. Today there exist dozens of server and client implementations of Activity Pub all interoperable with each other.
ATproto(col) - Bluesky
Background
Bluesky is owned by a single commercial entity, but is built on an open protocol intended to allow for scalability and delegation of functionality to distributed servers.
Tech
Bluesky foundation is that of PDS servers which store, own and authenticate content for a set of users. These can be easily ran as a single user instance, where the operator has complete ownership of their own data.
Relays are the next layer of distributed servers. They are responsible for crawling, monitoring and indexing PDSs. Additionally they shield PDSs from high traffic load. Bluesky runs their own Relays and independent Aggregator operators can run their own as well.
Aggregators are the next layer of distributed servers. They are responsible for providing ‘Feeds’ by crawling Relays and PDSs and aggregating them for followers. They make opinionated decisions as to which PDS content to act on and which to ignore. Top Aggregators today are provided by Bluesky themselves (such as ‘Following’ and ‘Mentions’ feeds), but many independent topic-focused feed aggregators also exist.
Lastly, applications such as bsky.app visualize content from followed feeds (produced by aggregators) and searches (from relays), and commit posts, likes and comments to PDSes.
ATproto is based on JSON messages exchanged through web-sockets with each of the layers of the network.
Today Bluesky controls the main relays and aggregators effectively having near full centralized control to moderate any and all PDSes and their content.
Nostr protocol
Background
Nostr is an open protocol intended to allow for scalability and delegation. No single entity “owns” Nostr and there is no centralized infrastructure.
Tech
Nostr is the simplest of the three. It is based on independent relays which store and forward messages sent to them by users. Users themselves own cryptographic keys which define their identity and allow sharing content with arbitrary sets of relays. Relays themselves do not exchange data with each other and only interact with users connecting to them.
To be “heard” by a recipient, a sender needs to utilize at least one relay which is also utilized by the recipient. This palaces high value on the few performant, large and popular relays to ensure reach. Each relay can in principle make opinionated decisions as to which content to store and forward, and which to ignore.
Nostr is based on JSON messages exchanged trough web-sockets between clients and relays.
Today there are half a dozen relays to which one has to forward messages to ensure very good reachability. This fan-out of messages makes centralized content moderation near impossible, but also makes running a good relay very expensive due to each such relay needing to store the entire set of recent messages for ALL users.
Clients need to make connections to all of their utilized relays which places high demand on key relays and will likely lead to them becoming the choke points for content moderation. Without user-network partitioning, it may be too expensive for there to exist multiple global-reach performant relays.
Summary Notes
… from an individual user wishing to gain more control over their content:
- Nostr provides best ownership control over data and least content moderation, at the expense of user<->user interoperability problems due to relay design and scalability bottlenecks as the global network grows.
- Nostr provides good search capability (subject to choice of relays and their data retention).
- Bluesky allows for very easy and affordable data ownership via single user PDS, but has the most centralized content moderation powers.
- Bluesky provides good search capability (subject to data retention of relays).
- Activity Pub provides good ownership control ONLY when self-hosted, which is much more involved and costly to run than bsky PDS. Content moderation is not centralized but a common problem for users on large shared servers.
- Activity Pub does not have a good search capability as it only indexes content from “follows” of its users. The smaller one’s instance is, the less useful search is for new content discovery.