A Technical Comparison of Distributed Social Media Protocols v3

calendar Mar 8, 2026 · 82 min read · tech protocols nostr activitypub atproto  ·

Hello, I’m back for round three of my social media protocol comparisons. I wrote v2 because of some mistakes on my part, although it’s been two years since writing it, and it’s become a bit out of date. It’s also a bit long, with a bunch of explainers and clutter right at the start of it, so for this round, I figured I’d get things up to date while shortening the text (or at least moving ramblings to footnotes) and move a lot of the explainers to the end.

In this version, I’ve added a section or so, such as moderation. While each protocol’s moderation features could likely be inferred from a coming together of their other aspects, it’s probably useful to compare how it works in practice. I’ve also removed a few sections, such as comparing communities and growth. Some of it is being more focused on a technical comparison, some because the protocols are less different now (e.g. all have similar community features, and all have stagnating userbases), and some because I’ve mixed those details into other sections (e.g. a note that says ActivityPub excels the most in communities instead of having a dedicated section).

A big thanks to those who shared my earlier versions or reached out with kind words and corrections. And, without further ado, let’s get into the customary meme, then jump straight into the protocols.

Table of Contents

Protocol Introductions

Protocol Comparisons

More Stuff

Protocol Introductions

A brief overview of the three protocols before comparing them directly.

ActivityPub

ActivityPub is the oldest still widely used protocol, its development starting in 2014, and its standardization as a W3C standard in 2018. It historically had the largest user base, although it’s been supplanted by AT as of recently.

ActivityPub is federated, which entails having individual centralized instances (servers). An individual instance is generally fairly monolithic: identifying users with the instance’s domain, processing & parsing posts, and hosting user data - a structure reminiscent of a standard social media service at first glance. However, ActivityPub allows one’s local instance to retrieve a copy of remote profiles and posts, serving the mirrored content and allowing reactions/replies to be sent to their originating instance.

Unique Strengths

ActivityPub is THE protocol for communities. While it varies across implementations, beyond a home timeline of people the user chose to follow, they’ll also generally have a timeline of members on their instance. Instances can be focused on a variety of interests, with varying rules and federation policies, offering a large variety of experiences while remaining part of the network. This creates the possibility of a more concrete community, instead of the more nebulous protocol wide ‘community,’ still capable of interacting with users across the network (de-federation notwithstanding).

Furthermore, being the oldest of the three, it has historically had the greatest adoption. There are communities going back the better part of a decade, and when other projects have entertained the idea of implementing distributed communication (Threads, Tumblr, Gitlab, etc), ActivityPub has generally been the one they’ve looked towards. Finally, being older and a W3C standard, ActivityPub is a rather mature protocol. Having an unchanging standard is very important when implementing the protocol into a project, as well as important to keeping projects properly federating with each other1.

Unique Issues

ActivityPub has an issue with de-federation, or more specifically, too much of it. On a larger, more well known instance, users will often find they’re unable to communicate with large swaths of the protocol - even amongst only well meaning instances - because their instance defederated with a very large number of remote instances or vice versa2. In short (see the footnote for further reading), the fediverse can sometimes be not one big community, but small isolated islands3.

Another issue, somewhat unique to ActivityPub, is the community’s toxicity. A good barometer of the community is the fact you can’t say “We should be nice to people who use Windows” without being attacked. I elaborated a bit more in the toxicity section of my previous update post, but in short, drama and community wars seem to be fairly common in many sections of ActivityPub. Be it operating systems, politics - or simple overuse of the content warning feature - ActivityPub has a handful of subcultures, which sometimes don’t play nice or easily welcome newcomers.

Third - and sort of an extension to the above issue - by nature of being the oldest of the three, a lot of fringe groups wound up on ActivityPub. Nazis4, Tankies, child abusers, and political fringes5 - the kinds not welcomed in more mainstream places - made their homes on the protocol. It’s not inherent to the protocol, it’s just a nature of it being first, and some of these communities have largely become isolated (places like Gab going so far as to disable federation entirely). Still, in contrast to the over de-federation, seeing an unmoderated public ActivityPub firehose is not a heartwarming experience; being considerably spicier than the other protocols.

Finally, and the only unique ActivityPub issue more directly related to the code, is that development tends to be slow and limited. This includes the protocol directly (e.g. standardized quote posts taking 15+ years), and in many individual ActivityPub implementations (e.g. don’t expect most servers to understand groups, despite them being around for a while).

Nostr

Nostr is the second oldest protocol6, with its development beginning in 2019, entering a fairly stable state in 2020. The smallest of the three large protocols, it had some fairly meteoric growth - coming close once to dethroning ActivityPub a few years ago - before its userbase heavily stagnated7.

Unlike ActivityPub, which uses a more standard server structure, Nostr is more partitioned. Users are identified by a key pair8, which is used to cryptographically sign posts. Users interact with the protocol using a client, a program or web app that signs posts, submitting them to relays of the user’s choosing, and fetching other people’s posts from relays. A relay is Nostr’s server, but relays are a lot simpler than an ActivityPub instance. There’s no form of cross relay communication, that’s handled by the client; instead, a relay is a simple repository of posts a client can pull from.

Nostr, at its core, is the simplest of the three big protocols9. However, it can expand its functionality through NIPs (Nostr Implementation Possibilities). For example, while a standard post on Nostr is plain text, NIP-23 posts - aimed at longform blogging - support markdown formatting. Dividing more complicated formatting into distinct types of notes allows better compatibility across clients, for example, a livestream client ignoring long text posts and a longform writing client ignoring livestreams10. While there are many clients aimed at a broad range of functions, it offers easy partitioning of more niche features to supported clients without complicating the protocol across the entire environment.

Unique Strengths

The most unique strengths of Nostr is its redundancy, and ability to permanently reference posts. As for redundancy, because most users generally use more than one relay, it’s the only protocol where a user’s preferred infrastructure can go down without them noticing. On any other protocol, if one’s infrastructure goes down, they either need to migrate (e.g. AT, Zot/Nomad), or their account is irrevocably lost (e.g. ActivityPub, DFRN).

Permanent reference is also part of this same structure. Posts are identified by hashes, and comprise of cryptographically signed json formatted text. Since they’re simple, standalone pieces of content, they’re not tied to any particular relay. Even if the relay(s) content was originally published to go down, as long as posts have been rebroadcast to new relays, they’ll still be locatable via the same hash. While this level of preservation is likely not necessary for short, Tweet like content, in terms of longform blogging and other more valuable standalone text or historical content, this may be a very valuable feature.

Additionally, Nostr is the most customizable of all three protocols. Because all processing is delegated to the client, and relays simply serve as a repository of posts, the user is given the most control over their experience. They decide which users to see and not, where their posts go (as well as who can see their posts if NIP-42 authentication is used), and who is allowed to reply to their content (if the outbox relay model is combined with a user trusted or controlled relay). In exchange for the time/knowledge cost of configuring such options, the user is granted the most control over their account and experience across all three protocols.

Finally, I’ve found the Nostr community seems less fractured, despite seeming more diverse in nationalities and schools of thought. I believe this developed because of two reasons: first, because the protocol is more connected to a community as a whole, unlike ActivityPub, where individual communities are often more isolated. I also believe that the protocol, being the most technical, has largely attracted people who are united in their interest in technology. People seem more likely to associate with others who hold differing beliefs, even acknowledging political differences and speaking well of each other despite them. While that’s not uncommon in person, it’s a rarity in the online world11.

Unique Issues

The community, however, cuts both ways. There is generally plenty of content within the cypherpunk type genres (crypto, privacy & security, Linux/technology, AI, etc), but people will often struggle to find consistent content on topics outside of those. While the content exists, it’s generally intermingled with other tech related content. Similarly, the community generally holds strong to a more idealized version of cypherpunk stuff. For example, when discussing the idea of key delegation12, I was called a fascist for my support of offering the option to people.

Additionally, on a more technical side, an account will be lost if it’s keys are lost (or if somebody else gets hold of them). This is inherent in any cryptographically based identification, although in Nostr’s case, there is no key rotation. In technical terms: no taksies backsies.

AT (BlueSky’s Protocol)

The AT protocol is the newest of the three big protocols; beginning development in 2019, but only more recently opened to the public in 2024. The largest of the big three protocols, even after losing roughly 80% of its userbase, it remains several times larger than ActivityPub and Nostr combined.

AT is the most partitioned out of the three protocols, first having users identified with a domain or key. While domains can be from the service host (e.g. user.bluesky.social), and keys can be delegated to a third party, the user is (theoretically) free to use their own domain or generate their own keys - in either case, controlling their own identity without needing to control their own infrastructure. The next layer is a PDS, which is a simple server that hosts a copy of a user’s posts. PDSs do not communicate with each other, only hosting a user’s content to be parsed by external services. Posts on PDSs are then parsed13 at the Relay/Appview level14, services that index content from PDSs; parsing the data, applying moderation/filtering, then serving it to clients. Finally, Clients, in program or web app form, serve the content to users15.

An important distinction, however, is that BlueSky is nearly the entire sum of AT infrastructure. Unlike the other protocols, which are more spread out, having one big centralized platform often causes the AT ecosystem to be somewhat different in practice from how the protocol would theoretically work. There will be a lot of times where I opine on how AT could theoretically work, but caveat with how it’s acting in practice due to a particular choice BlueSky has made.

Unique Strengths

AT, being broken into so many interworking parts, is really efficient for self hosters and power users. If one simply wanted to control their own identity, they could generate a key pair or update the DNS records on their domain, controlling their identifier without needing to host anything. If they only wanted to host their own account, they could do so by hosting a PDS, leaving the more resource intensive infrastructure like the Relay layer to others. Or, of course, it would still be possible to host that layer as well, if one wanted to host everything. AT is fairly flexible in terms of what layers are handled by the user, and what layers are handled by community infrastructure.

Additionally, AT seems to be focused on creating a somewhat flexible experience (somewhere between ActivityPub and Nostr). While the Relay layer would generally handle moderation, it would often be through labels that the user could manually enable or disable. Similarly, one could enable custom algorithms or moderation lists, seeing or avoiding their preferred kinds of content.

However, BlueSky - which is the overwhelming majority of AT - has moved away from this sort of model. They’re now applying moderation at every level16 (banning people from PDSs outright, instead of handling it at the Relay level as before). In practicality, most users of AT do not get much flexibility in terms of customized moderation.

Unique Issues

The first issue fairly unique to AT, related to the caveat on AT’s user flexibility above, is the fact things are centralized around BlueSky. BlueSky hosts a vast majority of AT, and most other platforms running on AT rely in part or whole on BlueSky infrastructure (although there are rare exceptions like Blacksky). This creates the ideological issue of effectively doing away with a distributed network, and the practical issue that anything BlueSky does (post type limitations, moderation, off protocol features17, etc) effectively applies to the entire ecosystem.

Additionally, AT is still in development. As of Q1 2026, migrations have been implemented, although they are somewhat janky, and the AT proto team has expressed an intention to further develop them. Identity management is still centralized, managing user IDs across the protocol in one big centralized database, with plans to decentralize it at an unknown date. Finally, there’s currently no private data (including DMs18), with again, intention expressed to add that functionality at some point.

Further, similar to Nostr, controlling one’s identity means taking on the risk of messing up said identity. Whether it be keys, and the risk of them being lost or compromised; or whether it be a domain, and the risk of improperly configuring it or forgetting to renew it - the freedom to control one’s account contains the freedom to lose it.

Finally, it’s rather impossible to bring up AT without touching on its partisanship19. BlueSky, as a platform (which again, comprises most of AT), has taken on an aggressively left-leaning partisan userbase and moderation practices. As with any explicitly partisan platform, it becomes a self fulfilling cycle, in this case driving away moderates and right-leaning people, moving further left. Many people who originally joined it with the intention of participating in a decentralized ecosystem and/or a mainstream leftist platform have abandoned the platform & protocol, citing an extremist bent and purity spirals.

Ease of Use

A protocol’s ease of use is both the most important, and least important, feature of a protocol - depending on perspective. It’s the least in the sense that every protocol (from email to AT) has only been popularized by platforms - generally for profit companies which build a user friendly on ramp, abstracting it from the more complicated underlying protocol. Even ActivityPub, which is arguably the easiest overall, was deemed too complicated by most non-technical people who considered joining. In another sense, however, it’s the most important. Before big platforms come, a userbase is needed, one of people using the protocol directly. Beyond that, even after platforms come along, the more cypherpunky idealists such as myself would certainly prefer some platform users eventually migrate to the protocol directly.

ActivityPub

In my original comparison, I gave ActivityPub the rating of “Moderate difficulty to join, moderate difficulty to master.” Joining ActivityPub requires one already know the basics: i.e. how federation works, and what type of instance or federation policies would be best. Joining an instance20 that’s either over moderated or under moderated, that is unstable, or that is defederated with people the user wants to communicate with is a quick recipe for ending the ActivityPub experiment of somebody who doesn’t understand how the protocol works.

However, ActivityPub as a whole is likely the easiest to understand. The “It’s like email” mantra isn’t far from the truth, and not a hard concept to grasp. And, with the basics learned, the rest isn’t too hard to follow. Once basic federation is learned, understanding concepts like defederation, how moderation works, or local/remote accounts would be rather straightforward.

Nostr

In my original comparison, I gave Nostr the rating of “Easy to join, difficult to master.” Joining Nostr is likely the simplest of the bunch; since relays are not connected to an account and are semi-interchangeable, joining the protocol is as simple as opening a website or downloading an app. Most clients will give the user a basic overview, which can be summarized to “Your NPUB is your username, your NSEC is your password. Don’t lose your NSEC!” From there, the user can immediately begin posting and following others.

However, beyond that, things take a more difficult turn. I can imagine trying to explain asymettric encryption to somebody who’s rather tech illiterate, only to pivot and explain they’re cryptographically signing messages and mirroring them on servers called relays, only to turn around and tell them to get and manually configure a NIP-05 domain based username so they’re less likely caught by anti-spam filtering would be a rather long conversation21. While easier to join, Nostr has a rather steep learning curve.

AT

In my original comparison, I gave AT the rating of “Difficult to join, difficult to master.” Similar to Nostr, the user will need to either understand key based accounts and generate one; then either simultaneously (or only if using a soley domain based username), understand DNS, and configure a domain to act as a handle. They will also need to understand the protocol itself - i.e. what a PDS is, which ones can be joined (or how to host one), and how to sign into an Appview with a remote PDS. However, while it has a similar structure to Nostr, since PDSs are not interchangeable the user needs to know all that information before joining - no opportunity to learn along the way.

Bluesky, however - as an example of how platforms make things easier - creates a very different experience from AT’s theoretical entry barrier. At the cost of likely not controlling your account, it’s possible to register with a username + password and go on using it like any other centralized service. In practice, the AT protocol has the least barrier to entry since it’s effectively just one big centralized service; letting people optionally set up their own infrastructure that communicates with the mothership.

User owned identifiers

User owned identifiers are, in my opinion, very important22. When infrastructure goes offline, or if the user is banned from said infrastructure, the question of what happens to their account will vary. Whether the user’s identity is lost, or if they’re able to carry on from other infrastructure23, is an important consideration when looking at protocols. Though I personally haven’t been banned24, I have had my account nuked when Nerdica’s SQL database was corrupted, so I’ve experienced firsthand the value of user owned identities.

ActivityPub

ActivityPub, with its more monolithic structure, handles identities at the instance level; identifying users with the instance’s domain name. Identities cannot be recovered if the instance goes offline, and there’s no path towards migration if a user is banned25. This is somewhat unique in that most other protocols 26 offer some degree of user ownership over their accounts.

There have historically been a few exceptions, such as Tahake27, which allowed the use of a user owned domain on a third party server (albeit Tahake remaining in control of the account28). There have also been rumblings of implementing Zot/Nomad’s nomadic identities, although that effort seems to have stalled out. Finally, some platforms like Streams/Hubzilla (Nomad & Zot respectively) offer limited user account ownership, bridging internally to ActivityPub. However, if a server went down, the user would retain their Nomad/Zot following while losing their ActivityPub followers/following.

Recently, however, Holos has provided a truely user controlled identifier within ActivityPub. While ActivityPub generally requires the server to control the account, it circumvents the requirement by making the client the ‘server’ - the Holos Relay a CDN or Nostr relay style server which keeps a copy of the profile online regardless of whether the client is. The client controls the account RSA key, allowing the use of custom domains, and even permitting offline migration. While Holos remains a very small portion of the ActivityPub scene, and requires Nostr levels of technical overhead (plus risk of a lost account from user error), it offers a truely user owned identifier.

Nostr

Nostr, unlike ActivityPub, separates identity management from infrastructure. Identities are key based, created and managed by the user. Additionally, there’s also optional NIP-05 usernames: a human memorable user@domain type username, pointing to the hash of a public key - which can be used with a user’s domain without requiring a user hosted relay. With identities separate from infrastructure, a user can continue using their identity on other infrastructure even if their main relay(s) go down or ban them. This works similarly to how one can continue using their domain if their host goes offline/bans them, or their GPG key if an email provider does the same.

AT

AT has two means of identifying users: keys and domains. Starting with keys, similar to Nostr, users can generate a key pair and control their account without needing to host their own infrastructure. Unlike Nostr, an AT account will be tied to a home PDS; however, as long as the user controls their keys, a migration can be performed on an offline or banned PDS. As an alternative to keys, users can also use a domain as a user identifier on the AT protocol. While key based accounts can still have a domain based username, using a domain as a main identifier forgos keys entirely and permanently ties the account to the domain itself; allowing one to control their identity without keys or hosting infrastructure.

It’s worth noting that, controlling account keys - if registered on BlueSky (using both their relay and PDSs) - is currently not possible. It is possible to use a user owned domain within BlueSky, however. It is also possible to use a user owned key based account on the BlueSky Relay, but that requires a self hosted or third party PDS.

Protocol Malleability/Compatibility

All three protocols are capable of doing more than a standard, unformatted, Tweet-like post; which is good, as social media is more diverse than simple microblogging. While each can do a variety of content types, some implementations are more hacky than others, and it’s important to consider how well different types of infrastructure or content interact with the ecosystem.

ActivityPub

Like most things open, ActivityPub can be used in a variety of ways - from a microblogging post on Mastodon (plain text & generally limited to 500 chars), to longform markdown enabled text on WriteFreely, to video on Peertube. Of all the forms in which public content is posted to social media, there is probably an ActivityPub enabled implementation that supports it.

Compatibility across the ActivityPub ecosystem is generally possible, although sometimes limited. Given instances interpret all data29, anytime there’s something the server doesn’t understand, things begin to break. There are times when things are aligned with the ActivityPub spec, but not implemented into the user’s instance itself. For example, Mastodon - which makes up a majority of ActivityPub - will display rich text incorrectly, or struggle to interact with groups30. When platforms do things outside of the ActivityPub spec, such as Peertube delivering videos via webtorrent, it’s even more limited; most other instances providing PeerTube videos as links to be viewed in a web browser instead of providing the video through ActivityPub itself.

Nostr

Nostr, likely the most malleable protocol, separates its functionality into NIPs - specs for how to interpret the formatting of posts. There are a little over one hundred official NIPs (longform markdown enabled content, videos, instant messaging, etc), as well as the ability to implement custom NIPs (such as for chess or geocaching). Most forms of public content is possible within Nostr, and if the use case is too niche, it’s fairly simple to add that functionality without breaking compatibility with other services.

Compatibility on Nostr works different from compatibility on ActivityPub. Since clients interpret all data, and since users can use multiple clients with the same profile, there is never any situation when a particular account is unable to participate within a portion of the network. However, clients still need to support a given NIP. The most heavily used ones (standard shortform notes, longform text, etc) will be supported by all clients, while more niche official NIPs (community forums, ecommerce) will only be supported by a handful of clients. Custom NIPs are generally only supported by a single client, such as Treasures.to with a custom geocaching NIP31.

AT

While the AT ecosystem is a little less broad (due to adoption, not due to the protocol itself), it supports a number of different post types from shortform content, longform content, video, and more. Similar to Nostr’s relays, AT PDSs are ‘dumb,’ generally hosting any content uploaded by the client to be retrieved and parsed by a separate layer of infrastructure.

Unlike Nostr, and more like ActivityPub, however; AT will generally rely on a service at the Relay layer to retrieve and parse data13. A Lexicon, the Relay layer’s instructions on how to interpret posts - as well as rules for what a post may or may not consist of - separates what is and is not part of any given ecosystem. This severely limits interoperability between services, as any post outside the bounds of the Lexicon (such as BlueSky’s 300 char. limit) cannot be viewed from within the service the Lexicon belongs to. This effectively partitions the network into different independent networks: BlueSky and similar shortform plain text content, WhiteWind and similar longform rich text content, etc32.

Portability & Migrations

Your favorite server goes down, you tried self hosting but want to call it quits, or you simply want to migrate and take your account elsewhere. Related to, but different from, user owned identifiers; how easy you can go from one piece of infrastructure to another is important for the longevity of your account.

ActivityPub

ActivityPub, being based on a server’s domain, is predictably not very portable. Users can perform migrations33, sending existing followers to a new profile, and most software will let you export a following list to import into other software. Some software will also let you import your posts from your old account, but not a lot of software supports that.

There are, however, some limitations. First, and most notably, the username is not kept. The old username still exists as a separate account, simply pointing to a new account with a different username. Migrations are also limited to compatible implementations. For example, while you can migrate from ActivityPub native software (e.g. Mastodon, Pleroma/Akkoma, GoToSocial) to one internally bridged via plugins (e.g. Friendica, Streams, Hubzilla), you usually can’t go in reverse. For example, while migrating from Mastodon (ActivityPub) to Friendica (DRFN, internally bridged) is possible, afterwards, the only possible next migration would be to another Friendica instance. Finally, without controlling the identifier, migrations can only happen if the instance is online and the account is in good standing29; followers only carrying over if they are federated with both the old and new instances.

Nostr

Nostr is by far the most portable, with accounts publishing which relays they’re utilizing, but not being tied to any particular relay. Relays can be updated at any time, with followers’ clients automatically fetching posts from the updated relay list. Old posts are not moved from old relays to new ones when the list is updated, but a rebroadcast will copy posts to the new relays, and a deletion request will optionally remove posts from the older relays.

AT

AT, similar to Nostr, uses user owned identifiers - foregoing the limitations of ActivityPub’s migrations. Unlike Nostr, however - and similar to ActivityPub - AT accounts are tied to a home PDS. Although PDS migration is still in development, it’s possible to migrate from one PDS to another PDS - even if that PDS is offline.

However, in the case of BlueSky (or a similar platform built on AT), migrations are more limited. Account identities are often tied to the domain of the service, and it’s often impossible to control account keys, making migration more limited or impossible for the vast majority of users.

Moderation

In many ways, moderation is the same across all three: admins can prevent particular content or identities from interacting with their infrastructure. Often, moderation tools on the protocols have as much intra-protocol variation as inter-protocol variation. However, what levels moderation occurs on, the effects it has on users & communities, as well as the degree to which the user can control the moderation, create practical differences across each protocol. I have also seen some confusion as to how moderation works on user owned identifiers, including by more technical people than I34, so using my limited reach to clarify things might be useful.

ActivityPub

ActivityPub most resembles a centralized social media service, with the user’s instance handling most moderation decisions. Local instance moderation is fairly straightforward: an admin can apply restrictions or a temporary ban to an account, and a permanent ban renders the account unusable. Admins can prevent the viewing of remote content, either by blocking individual remote accounts or entire remote instances. In which case, no content from that remote instance will be fetched by the local instance, and accounts or posts on that remote instance will not be available to users on the local instance. Some software has additional features, such as Mastodon’s ability to ‘silence’ a remote user or server (effectively a shadowban35), although moderation features like that are not universal across the protocol.

Individual users have a few, but limited, options to control moderation. Users are unable to alter admin set moderation, but in most cases, are able to apply additional moderation to their feed. Most ActivityPub compatible services permit users to block other users or entire domains, allowing them to add additional moderation to what their instance admins had set. Because the user’s instance rebroadcasts incoming replies & likes to their post, this blocking isn’t simply hiding content, but an outright prevention of replies, likes, or quote posts from the blocked user36. Beyond that, most clients support additional moderation at the client level - hiding keywords, users, or tags. Unlike other levels of moderation, however, filtering at the client level simply prevents the content from being displayed; the content still delivered to the instance/user, and any hidden posts/replies visible to all other users in local and remote instances.

Nostr

Similar to ActivityPub, moderation on Nostr can be performed at the relay layer. Owners of relays control what users are allowed to upload content to them; either only allowing a specific set of users by default - updating the list (manually or via some form of registration) to allow new users - or by allowing all users by default, but manually blocking/removing specific posts or users. Relays can, at any time, remove particular posts or prevent identities from using that relay; however, unlike ActivityPub, the user account still exists and is capable of continuing to participate in the network using other relays. The exact moderation features on any particular relay software vary, with some offering no more than a CLI tool to configure the mode (allow/deny unknown users) and to manually remove content/users. Others have much more fine tuned moderation features, such as Ditto, which support much more in depth content filtering options, and even support the Mastodon API for content/user management.

Individual users on Nostr have a fairly wide margin for controlling moderation. Using the OutBox model, users can set the relays that other users fetch their posts and send their replies; meaning if a user sets their inbox/outbox relays to ones they control - or hosted by a third party with the moderation policies the user is seeking - they can keep replies and interactions within a specific set of moderation policies. Similar to ActivityPub, most Nostr clients are also capable of filtering out content by keyword/tag, NIP-05 domain names, standard blocking, and/or automatically blocking people who were blocked or reported by several people you follow37. Unlike moderation at the relay level, and similar to client level moderation on ActivityPub, this moderation at the client level on Nostr will only prevent the content from being displayed to you and will not prevent it from being displayed to others.

Beyond relay and client moderation, however, Nostr’s simplicity often causes it to be moderated in a similar way to how RSS would be. Unlike ActivityPub, where servers directly reach out to other servers to transmit posts/replies, Nostr operates more like RSS, with a client simply fetching content from people it’s told to do so, on relays it has been configured to do so. On Nostr, if wss://jimbobgoober.example created a relay full of spam, if no clients are ever configured to reach it, then that content will never be fetched. Similar to RSS, most users simply ‘moderate’ their feed by choosing to follow specific users on specific relays that post content they want to see.

AT

On AT, moderation can occur at both the PDS and Relay layer, in addition to client side moderation. PDSs, which resemble Nostr relays or websites with RSS, are fairly simple and do not have any form of cross PDS communication. Admin(s) of a PDS can choose which users are allowed to join a PDS, as well as remove misbehaving users from their PDS if required. Users of a PDS cannot continue using a PDS they have been removed from; however - similar to Nostr - an AT user removed from a PDS can use their key (or domain) to migrate their account to another PDS. However, setting aside clients like Red Dwarf38, most clients pull content from an intermediary and not from PDSs directly.

At the Relay layer, AT relays pull content from PDSs to be rendered and distributed to clients. These relays choose which PDSs to index, allowing the admin(s) of a relay to prevent particular users or PDSs from participating in the service the relay is a part of. Different relay/appview implementations will likely be able to de-index content based on specific filters, and some will automatically hide content such as replies that have been blocked39. Many Relays require manual approval for a PDS to be indexed, for example: BlueSky previously required users to contact them via Discord to have their PDS indexed. And, similar to ActivityPub & Nostr, AT clients may support additional moderation features; hiding content based on keywords/tags or muting individual users. Although, like other protocols, client level moderation does not prevent that content from being shown to other users.

As with other aspects of AT, however, BlueSky’s dominance of the protocol changes how it works in practice. BlueSky makes up the vast majority of the network - with most alternative AT platforms using BlueSky hosted PDSs, and many alternative platforms using the BlueSky Relay. In effect, the BlueSky corporation has a centralized social media style moderation control over the vast majority of the AT protocol. Even the few people outside of BlueSky infrastructure will likely be following and followed by people on BlueSky infrastructure, in essence placing them under the same moderation policies.

Resource Requirements & Scalability

Resource requirements, while not as flashy as identifiers or cross platform compatibility, are certainly worth taking into consideration. On the single user scale, a small service piggybacking on an existing home server or VPS is a lot less likely to be decommissioned than something requiring a lot of dedicated resources or its own host. The cost of a small community platform, likely run off donations or - more likely - the pocketbook of it’s admin, is a lot more likely to stick around if the monthly cost is one or two figures instead of two or three. On the large platform scale, hardware/cloud costs could mean the difference between much more lax monetization practices and much more invasive monetization practices. While funding distributed protocols creates shared issues, which will have its own section, not all protocols are equal in terms of resource requirements.

ActivityPub

ActivityPub, with its monolithic instance structure, has fairly high resource requirements when compared to the other protocols here. At the cost of providing a more straightforward, universal experience across all users of a particular instance, the host needs to handle all forms of retrieving, processing, and hosting user content. Remote content is generally retrieved and mirrored on the local instance, either indefinitely or for a set period of time, depending on the particular implementation and configuration. There is, however, a lot of variance between different implementations. Something like Mastodon or Friendica will generally require a lot more resources than something lightweight like GoToSocial or Holos40.

Nostr

Nostr is generally the lightest of all three protocols. Relays are a lot simpler, offloading most processing to the client. While processing data locally is trivial for the device41, it quickly multiplies if a server is attempting to perform the same operations for a number of users. For example, when experimenting, I was able to run two relays and the Ditto front end on a single core, 1 GB of RAM VM. Even sending many posts to both simultaneously, they performed fine on a server that had failed to even install many ActivityPub implementations due to its lean resource allocation.

AT

AT, being effectively broken into three layers (PDS, Relay/Appview, and Client), makes quantifying AT’s resource requirements more difficult. PDSs, similar to Nostr relays, are generally very lightweight - hosting simple content to be accessed and processed by other devices. A user, community, or platform only wishing to host PDSs - relying on other infrastructure for everything else - would find AT to be very lightweight. Some clients, such as Red Dwarf, forgo the Relay layer entirely - operating similar to Nostr: infrastructure is lightweight, serving static content to be processed by the client. A personal relay can also be run on fairly lightweight hardware, likely similar in resources to most ActivityPub instances. However, most of AT runs on large semi-centralized platforms such as BlueSky. While I don’t know the resource requirements a platform like that requires - or if they would be similar to something like an ActivityPub platform of a similar size - by nature of centralizing an entire community or protocol around one service, the resource requirements are likely very high.

Spam Mitigation

Spam42 is universal across any ecosystem, not specific to any platform or protocol - but with anything distributed and lacking a single centralized gatekeeper - all three protocols risk getting hit especially hard. Spam has been fairly limited on all three, largely due to their obscurity, but both ActivityPub and Nostr have experienced several large spam attacks. AT has also had spam in the past, but to my knowledge, the only major spam attacks have been through bridges43. If the protocols themselves grow, expect spam to be an increasingly persistent issue.

ActivityPub

Likely the most spam resistant in theory, ActivityPub requires both a server and a domain to begin creating posts on the network. Instance admins control who is allowed to register, limiting the creation of unlimited spam accounts. Bypassing remote admins by creating a server and purchasing a domain, or hijacking an existing instance, requires some combination of money, hardware, and time - creating a barrier to entry for would-be spammers. ActivityPub’s main method of dealing with spam once it occurs is de-federation. While the vast majority of instances federate with all other instances unless actively blocked, creating an on road for a malicious/hijacked instance to spam, de-federating from the instance will immediately cause all spam from said instance to cease. While there could be an unlimited number of accounts on a spamming instance, blocking that instance’s domain would block all accounts simultaneously, forcing a spammer to cycle through a large number of domains.

Nostr

Nostr is by far the most susceptible to spam, requiring nothing more than a generated key pair to begin creating posts. Most relays do not require registration to post to them, making the most popular public relays an easy target. While Nostr’s RSS like structure prevents regular post spam from reaching most users, spam on replies or tags can quickly become overwhelming. Because of its susceptibility, there have been a number of methods of mitigating spam implemented in parts of the Nostr ecosystem. The first, and likely most widely used, is requiring NIP-05 domain based usernames. By not accepting posts from users (either new users with unestablished accounts, or all users across the board) who don’t have a domain based username, spam mitigation can be performed similar to ActivityPub. Some services will provide a NIP-05 username using their domain44, but require registration or a captcha to prevent mass use. Otherwise, spammers could register domains to use themselves, but all accounts within the spammer’s domain could be blocked in an instant.

Proof Of Work, or PoW for short, is a less widely used tool, but a rather effective way to prevent spam. PoW requires a client to perform a basic math equation, similar to anti DDOS tools like Cloudflare or Anubis, before making a post. While it may only take a phone or computer a second or so, barely interrupting one’s workflow; to a bot that intends to spam posts, it becomes extremely prohibitive.

Web Of Trust, or WoT for short, is another more experimental tool for combating spam. It uses a map of follows to determine who appears trustworthy. It can be configured to be more universal, starting with a well known figure or widely followed account. In that way, it would work something like X follows Y, Y follows Z, and Z follows you - meaning others should be able to trust you’re not a spammer. WoT can also be set by the user themselves, using their account as the center of the web, giving users a good idea of who runs in their circle (friends of friends, and friends of friends of friends, etc). WoT can be used as a more general guide, displaying all posts but providing a WoT score of the profile, or it can be used to hide content by default from untrusted accounts. WoT can be implemented at the client level (ranking and/or hiding content from relays) or at the relay level (individual relays not accepting events from untrusted accounts). However, WoT is new and experimental, so it’s not very widespread across the network.

Beyond specific tools, since clients process most data, moderation tools are also often used by clients to limit spam. Clients can automatically filter out specific keywords (e.g. the name of a ‘company’/‘product’ being spammed), specific pieces of content (e.g. a Blossom hash or link to a piece of spammed media), users who post more than a reasonable human could, or specific NIP-05 domain names. Some clients also support automatically blocking profiles that were publicly reported &/or blocked by people the user follows, providing a form of grassroots community blocking. Finally, there’s the ability to use uneffected relays. Some relays require payment &/or manual registration to participate, effectively cutting spam to zero. With the outbox model enabled, users can use relays that have been configured to reject spam in most forms (by the user or a third party), even if some public relays are struggling to mitigate a particular spam attack.

AT

AT has been, in practice, the most spam resistant protocol. While similar to ActivityPub & Nostr, it’s rather easy to spin up a PDS or generate a keypair, AT’s centralization around BlueSky has rendered it very resistant to spam. Most resembling a centralized service, in order to participate in the largest platform within the protocol, one will need to register with BlueSky to create an account there or to get their independent PDS to be indexed by the BlueSky relay. This centralized control has made AT nearly immune from spam attacks. To my knowledge, there has only been one notable spam attack, and that came from spammers who started on Nostr, only to chain the Mostr bridge and BridgyFed together to put spam on AT45. While the protocol may need to implement additional technical measures if it becomes more decentralized, with its current more top down structure, it remains the least susceptible to spam of all three protocols.

More Stuff

This officially wraps up the protocol comparisons, which is long enough already, so if you only wanted to see how the protocols compare you can close this tab. From here, however, I thought I’d go over a few different things: potential improvements, the state of funding, and some universal issues - as well as go over some definitions and clarify a few things.

Potential Improvements

It’s important to note I have a habit of sounding more knowledgeable than I am. I’m going to suggest a few different aspects of the protocols (and/or their implementations) that could be improved, but you may want to take them with a grain of salt.

ActivityPub

Identity management is likely ActivityPub’s greatest foil. Relying on the host’s database, as well as the host’s domain name, is a recipe for everyone’s account to be lost eventually46. Owning a domain is a potential solution. However, that requires a user pay for (and configure) their own domain, and on the vast majority of implementations, that also requires the user to host their instance. Something like porting Zot’s Nomadic Identities is also possible, using cryptography to verify ownership while mirroring an account on another host. The idea of porting it to ActivityPub proper seemed to float around for a while, although the effort seems to have stalled out.

The ideal solution to me, however, is cryptography. Changing to a key as the main identifier isn’t feasible on a mature protocol that’s always operated on the host’s domain, but creating a keypair on registration - then sharing it when servers request the user’s profile - would likely be more doable. It would be a lot less invasive than a major change - simply a recovery code provided to the user to be saved/printed. Using that key to verify the user’s identity, however, would allow the user to contact remote instances using their client/new instance and perform a migration regardless of the state their original host or domain is in47.

Patchwork Federation is the other big issue. While not an issue with the protocol itself, being such a pervasive issue across the ecosystem, it’s still worth bringing up. Every ActivityPub implementation is going to handle federation slightly differently, but all can block federation, and some like Mastodon have a form of ’limited’ federation (shadowbanning a user/instance), or are capable of blocking media from instances while allowing text content. Being more of a community culture issue than a technical issue, there’s not really a technical fix to it - much less a protocol wide solution. That said, if I were ActivityPub king for a day, I would make it so admins could allow domain blocks to be overridden by the user on a case by case basis. Admins must be capable of fully blocking things instance wide - be it for legal purposes, technological purposes (e.g. spam), or simple preferences (it’s their server, it should answer to them). However, some blocks are intended to provide a particular admin-prescribed experience, and offering the user the ability to customize that experience could go a long way.

Beyond that, while unrelated to the protocol or its implementations, it might be worth better clarifying federation policies on the various onboarding sites (joinmastodon.org, or the various join insert implementation type sites). Migration is somewhat limited on ActivityPub, so joining a server fit for the user on the first try is fairly important. New users are likely not going to know to open an instance, then check its federation policies (assuming that’s even public); much less know what things to look for (e.g. knowing Bridgy Fed & Mostr are bridges - or what bridges even are). Giving the user a basic idea of how federation works, as well as how strict a particular instance is, could be important for onboarding.

Finally, if you are managing federation policies on an instance, consider this reminder: ActivityPub is usually sold as an open protocol that allows you to interact across the entire network. Every time a well meaning instance, a platform like Threads, or the various bridges are blocked, it breaks that. If a new user picks a random joinmastodon.org instance and finds they can’t reach a large chunk of the network - if not an outright majority - they’re probably not going to scour the internet for another instance to join. They’re probably going to look at the arbitrary restrictions and conclude it’s no different from centralized platforms, then give up on the distributed protocol experimentation.

Nostr

Key rotation, or more specifically, the lack of it, is the largest issue I see facing Nostr on a technical level. Keys cannot be rotated, meaning that the single keypair generated upon registration - and used for every function of your account - remains the user’s sole identifier. One malicious client, compromised device, or accidental upload is all that stands between users and lost accounts. While there are some forms of delegation like an nsec bunker48, ultimately, the key will still need to be on a device exposed to the internet to use the protocol49. Adding some form of rotation, like supported on AT, would make accounts much safer and more easily recovered.

Similar to key rotation, domain based identification may also be worth considering. Whether it be truely domain based (e.g. the (sub)domain points to a list of JSON events to be parsed by the client) - or more likely, key rotation using a domain as the final authority50 - domain based accounts may be useful in a handful of circumstances. The largest use case I see for something like this would be platforms and bridges - services that might handle a large number of account keys on behalf of users. In that case, instead of a single rogue employee or unauthorized user effectively destroying the service (hijacking every account on the service), those who control the domain could ultimately restore access. Similarly, for a corporate account - or even a standard user who trusted their domain provider more than they trusted their ability to store a key - having a domain as an ultimate authority over an identity could be important51.

Finally, some form of platform like service (possibly in conjunction with domain based accounts) is likely vital for the Nostr ecosystem. Some form of self hosted service - or outright large platform - allowing users to join without needing to manage keys or anything technical, is effectively the only viable means of onboarding aside from luring in technical users from other protocols. While the in development DiVine - which already has promising interest - is a great example of the concept, a more general purpose implementation similar to a platform like BlueSky or a standalone self hosted Mastodon instance is likely a large factor holding back Nostr adoption.

AT

As far as AT goes, its ongoing development is covering some things I could see improving the protocol. The developers have expressed intentions to continue working on private data (such as DMs), improving PDS migrations, and decentralizing the PLC directory. Some form of private data and easier PDS migrations are important for the protocol. Changing how identities are cataloged, from a centralized database to some form of a decentralized system, is vital for getting a truly decentralized protocol.

Beyond protocol development, it would probably be beneficial to improve compatibility between platforms with different Lexicons. While there’s nothing - to my knowledge - in the protocol itself that would prevent better compatibility, platforms like BlueSky have rather aggressive restrictions on what posts will be indexed and served to other users. A transition towards less restrictive Lexicons, or the ability to view posts that fall out of the Lexicon’s requirements, would likely be a large stride towards decentralizing the network.

Further, it might benefit users if they were more easily able to use key based accounts on platforms. As it stands now, while users can use domain names on platforms like BlueSky, in order to use a key based account, the user would need to host their own PDS. Enabling users to more easily control their accounts with a key, offering them control over their own identifier without need to host their own PDS, would be a useful decentralizing feature. Like lexicons, this isn’t necessarily something in the protocol itself, just how platforms on the protocol currently seem to be operating.

Finally, decentralization from BlueSky is a necessity if AT is to take off. Being largely BlueSky, with its partisanship baggage creating a glass ceiling of a userbase, potential growth will likely have to be outside of BlueSky itself. Beyond that, the AT ecosystem has been growing increasingly under the control of the BlueSky corporation: both because BlueSky has been performing more strict moderation at more levels of the protocol, and because more external projects on the protocol rely on BlueSky infrastructure. Without somewhat rapid decentralization, AT will simply become BlueSky plus things that connect with BlueSky.

Universal Issues

Beyond comparing protocols, there are four different issues universal across them that are worth discussing here: private data, funding, the difficulty of onboarding to a decentralized system, and identity verification laws. While each protocol might be affected in slightly different ways, they’re very similar, and worth discussing as a group instead of comparing them separately.

Identity Verification

Identity verification is rapidly becoming required for any form of social media service52 in many nations and US states. While there is some precedent of US courts looking unfavorably on those laws, a preliminary injunction in a lower court is by no means concrete, and most other countries won’t have similar powers curbing such laws. I am, to be clear, absolutely against blanket social media or OS ID/age verification requirements; I hope they’re struck down so we in the US can be a beacon of freedom, offering information worldwide without the need for anyone to show their papers. But I’m also not going to go to jail, or get hit with a 6-753 figure fine, all so that I can run some infrastructure without requiring verification.

Verification requirements may hit the distributed protocols ecosystem like a freight train. If similar requirements become widespread, especially in North America and Europe where most of the infrastructure sits, a large majority of the ecosystem could become closed to registration or outright shuttered. Identity verification of strangers would likely entail paying for expensive third party services, or labor intensive manual verification (such as showing ID via video call) - requiring a lot of trust in a third party. Identity verification is also very unpopular within the technical crowd (perhaps a further indication it’s a bad idea), so even on services that do enable it, their userbase would likely never recover regardless.

These laws will likely not impact all implementations the same. Clients, just like a web browser, would likely not be affected by such laws. Some more infrastructure like components (AT PDSs, Nostr Relays, Holos Relays) might be able to skirt by, being closer to AWS buckets or Cloudflare than they are standard social media services - although I wouldn’t risk my freedom on a bunch of baby boomer judges and politicians agreeing with (or even understanding) my non-legal technical interpretation. Large platforms like BlueSky and Threads likely wouldn’t be affected as much, having the budget to verify their users, and self hosted platforms with closed registration (single user and/or IRL known users) also wouldn’t be affected.

Ignoring the laws, however, will not be an option. If these laws are implemented and enforced - and no feasible solutions to comply with these laws on these protocols are developed - expect a large chunk of community infrastructure on AT & Nostr, as well as most ActivityPub instances, to disappear from any jurisdictions with similar laws. First, as admins willingly take them down - be it because of feasibility, cost, or ideological aversion to verifying accounts. Later, with holdouts coming down when enforcement is acted out.

Private Data

In social media, private data generally comes in two forms: direct messages and posts only visible to friends (or another specified group of users). All three protocols struggle, or outright fail to implement, one or both of those.

ActivityPub supports direct messages. They’re not end-to-end encrypted, and occasionally different implementations will struggle to share DMs (sometimes accidentally making them public), but the protocol supports basic direct messages. Sharing posts to a limited audience is another story. Generally speaking54, private posts on ActivityPub boil down to ‘follower only’ posts. While you can choose to allow or disallow a follow on the protocol, it’s rather limited in terms of choosing who can or cannot see a ‘private’ post. There’s also no ability to prevent a follower from publicly re-sharing the post, and oftentimes other ActivityPub implementations won’t honor the followers only state and will instead list the post in the public feed.

Nostr has made progress in the direct messaging department. They have always been end-to-end encrypted, but under the old standard (NIP-04), the encrypted messages were public, and anyone could see who contacted who. The newer standard (NIP-17) has resolved that, providing more private DMs. Properly private posts, on the other hand, are not very supported. There have been attempts to handle ‘private’ posts similar to ActivityPub’s followers only solution - providing an unencrypted public post, but only to clients of specific users55. Still, support for them is very low, and there’s a lot of jank - not to mention the second a client re-broadcasts the event to a public relay (many do this automatically when replying/reacting/reposting) it becomes visible to everyone.

AT is a lot simpler, in that it has no support for private data whatsoever. There are direct messages built into BlueSky, but as mentioned above, they’re not part of the protocol and don’t work with non-BlueSky users. Everything you do on AT is 100% public.

Funding

All three protocols, as they are now, cannot financially scale. There are some exceptions: self hosted infrastructure is generally financially secure, you probably don’t worry about the $2 in electrical costs or $5 in VPS costs to run it. Flagship instances have survived so far56, protocol authors likely getting the brunt of donations in the ecosystem. But, there’s a lot more to a network than flagship and self hosted instances, and they won’t be so easily funded on the current model.

Most of the ecosystem today runs off the charitable nerd model. Instances are run and funded by volunteers who cover the costs, and/or users who make donations. It works for now, largely because there aren’t a lot of people in the ecosystem. ActivityPub and Nostr are both in the six figures of users (albeit ActivityPub closer to 7 figures, and Nostr closer to 5 figures). With such a small userbase, and the fact hobbyists like you and me are more willing to make donations to keep things running, everything has stayed online so far.

However, try scaling that to 9 or 10 figures; the kind of scale mainstream social media platforms have. Most social media users won’t donate or pay for something they’ve been conditioned to think of as free - if they can even afford to do so to begin with. Even a jump from 6 figures to 7 figures can already stress an ecosystem, as we’ve seen BlueSky forced to take on venture capital money, while still not having a monetization strategy. And BlueSky is mainly text, attempting to fund such an ecosystem surrounding images or video would be even more impossible.

Onboarding

While funding a diverse set of free to use services using the current model would likely fail, that brings up another problem: onboarding to those services to begin with. ActivityPub - likely the easiest overall to onboard - found that out the hard way during the attempted mass migration to it. Sifting through thousands of random services57 is already friction, and something that would likely turn the average user away - even if they did know what metrics to compare services by. Most new users, however, likely won’t understand how to choose the best infrastructure for them, so they wind up in more or less the following situation: Pick some infrastructure you don’t know how to compare, hosted by a random stranger, then use it to interact with a protocol you probably don’t fully understand. Let’s hope it’s still online by this time next year, and that they don’t randomly ban you or defederate from people you want to follow.

The other option, hosting things yourself, isn’t going to be the solution. It’s always been the nerd utopian idea, everyone having their own server in their closet. Everyone was going to host their own website, then everyone was going to host their own email, then everyone was going to host their own XMPP server, then now everyone is going to host their own social media service. Yes, self hosting isn’t that hard - but neither is buying cloth and making your own clothes, fixing your own car, or butchering your own meat. Like self hosting, none of those are particularly hard, and they can all bring their own benefits or cost savings. We live in a specialized society; people have limited time, and it’s more efficient to focus on certain things while outsourcing the rest. To any self rightchous IT guys58, try taking on one of those or something like it before you expect everyone else to do the thing you’re specializing in.

So, small independent infrastructure is unfundable and not feasible to onboard new users to, with self hosting remaining niche and inaccessible to the average user. That leads us into the next section.

Platforms, not Protocols

Platforms are the hardcore cypherpunk’s or self hoster’s monkey paw; you’ll get everything you ever wanted, but not in the way you want. But, to the more jaded realist, platforms that implement these protocols are the best guess as to what the internet will look like in the coming years. Like email, few people will host their own; most congregating around a handful of large services that make up the protocol. Unlike a centralized service like AOL Messenger or company intramail, however, it remains open - nothing’s stopping you from hosting your own or using a more niche provider that suits your needs better. The trend appears consistent across most technologies; something is niche and only used by nerds, until several companies provide a centralized option accessible to the average user - one usually winning out and engulfing the market. Time goes on, however, and eventually that single service is replaced by a semi oligarchical group of new services, all standardized around one or a couple open standards59.

First off, platforms have an incentive to implement the above protocols. There’s nothing new under the sun; every type of platform has already been built, and marginal improvements to something that already exists isn’t reason to try a platform that has no user base. Implementing one of these protocols alleviates that; day one users suddenly capable of communicating with millions of people across a number of different protocols and platforms (see bridges section). If, beyond the platform’s userbase, you can also follow and communicate with Threads users, WordPress and Tumblr blogs, BlueSky users, and everyone across native ActivityPub, Nostr, and AT - suddenly, the value proposition of a new platform with marginal improvements to an old formula increases. And, as more platforms implement at least one protocol, it becomes a self fulfilling cycle: a wider ecosystem brings more value, more value means more incentive to integrate, ad infinitum.

Secondly, and important to this discussion, platforms bring value to those on the native protocol. Suddenly, instead of being restricted to a handful of nerds who joined the protocol, you’re capable of interacting with a wider world from within your technological bubble. Without leaving your community or self hosted infrastructure, you’re suddenly able to reach anything and everything you would have on a centralized social media platform. More widespread use, and easy two way communication, also means more people migrating from the platforms to the raw protocols themselves. More users mean a bigger userbase outside of platforms, as well as better prices and more offerings on semi-self-hosted services60 (eg. Masto Host).

It’s not all sunshine and rainbows. Platforms are likely going to prioritize native content over remote content in their recommendations and algorithms. For more resource heavy content, like YouTube or its successor - if they implement one of these protocols - will still likely show ads or require payment when viewing video content. Further, unlike text content, content like video would likely be viewed in a browser or app; protocols relegated solely to following users and providing interactions. But, it’s not all bad. Lighter content like text will likely be transmitted over the protocols themselves, and even for content that’s not, that’s the two sided bargain of platforms. They might not play as nicely as community infrastructure, but they also provide the only feasible source of onboarding and funding; simultaneously becoming semi interchangeable61, and letting us interact from behind the more private and ad free barrier of our own infrastructure.

Bridges

ActivityPub, on its own, is a niche place where nerds who wish tech returned to the 1990s congregate. Nostr, on its own, is a niche place for cypherpunks and people overhyping new tech to congregate. AT, on its own, is mostly just BlueSky; a small platform locked to a somewhat extreme flavor of partisan politics, creating its own userbase glass ceiling. Without bridges, protocol usage becomes a zero sum game, the limited attention from a limited userbase of technical users in one subtracting from another.

Bridges act as translation layers, requesting profile/post data over the original protocol in the same way that any native server would do, before re-formatting the JSON data into the new protocol and serving it to the client/server that requested it. Bridging can be done by dedicated bridges (BridgyFed, Mostr, Eclipse), as well as through internal plugins (Friendica, Hubzilla, Streams, GNU Social, etc). When content is bridged, users across the bridge can view and interact with posts from a user on either protocol.

Bridges, and inter-connectivity in general, are the only means of legitimately growing the space62. Several niche ecosystems turn into one large one; every new user or platform adopting a protocol providing value to all three as a whole. Each protocol can shine in its own way, while bolstering each other’s userbase, and (hopefully) achieving escape velocity. While there is sometimes jank within bridges, especially when multiple are chained together (e.g. DMs not working or @s not showing up), it’s possible for somebody on one protocol to be following people across all three without having a non-native experience.

As of February 2026, there are a total of four large standalone bridges:

  • Bridgy Fed (ActivityPub <> BlueSky)
  • Mostr, and its fork Momostr (Nostr <> ActivityPub)
  • Eclipse (AT <> Nostr)

Honorable Mentions

If you’re a weirdo like me who likes reading about protocols, then you might enjoy reading about some of these protocols as well. Each one sets out to achieve the same goal as the three above, but have their own take on achieving it, bringing various pros and cons to the table. That said, they have a rather small userbase. For reference: ActivityPub, Nostr, and AT all have userbases in the six or seven figure range53, while each one below struggles (or fails) to pass four figures of monthly active users. Some can work alongside existing protocols (e.g. Streams, Hubzilla, & Friendica internally bridging to ActivityPub), so if you were looking to join the ActivityPub space, then those options may very well be a great choice63. Outside of that, however, you’re probably better off joining one of the big three.

  • RSS is something you’re probably aware of if you’re reading this blog. But, if you’re not, it’s the OG means of following content outside of platforms. It’s more or less simply a list of links and a description, which you can load in any RSS reader to check for new content and track what you’ve already read. It’s supported by most blogging platforms, as well as a surprisingly long list of centralized platforms (such as YouTube & Substack).
  • Webfinger is also worth bringing up. It’s rather obsolete, but provides a way for web servers to ‘ping’ each other, providing replies to posts or notification of mentions.
  • Ostatus, and its successor pump.io, were the first protocols to combine Webfinger with an RSS style list of posts; providing a social media like feed with two way communication. It’s still used today on occasion, although most compatible projects have migrated to ActivityPub; Ostatus compatibility being a relic of still maintained software that pre-dated ActivityPub.
  • SecureScuttleButt, and it’s attempted successors like PZP, are unique in that they’re the only truely peer to peer protocols listed here. Forgoing all forms of servers or infrastructure, users are identified with a key pair, then create posts to be hosted on their own device. Nostr is somewhat of a spiritual successor to SSB, being developed to offer similar features, except to cache posts on relays so content remains online regardless of the user’s device.
  • Diaspora, built for the social media server of the same name, is another protocol similar to ActivityPub in structure. Unlike ActivityPub, however, it’s built to provide a more Facebook style user experience (friend circles and detailed post viewing permissions) as opposed to ActivityPub’s more X/Twitter style experience (generally fully public). Diaspora also predates ActivityPub, however, unlike Ostatus, the Diaspora project never adopted ActivityPub64. That said, there is still a small community on Diaspora - with internal bridging to Diaspora available via plugin on Friendica and Hubzilla.
  • Zot, and it’s official successor Nomad, are built for Hubzilla and it’s successor Streams65 respectively. Both support Nomadic identities, which operate a lot like a standard ActivityPub setup at first glance (home instance with accounts identified by the instance’s domain). However, behind the facade, they hide the ability to mirror your account on multiple services for redundancy; in addition to a keypair for better account migrations. Both protocols also offer Diaspora style post permissions, again, giving a more Facebook style social network. Hubzilla and Streams internally bridge to ActivityPub, offering communication with ActivityPub accounts, while still offering advanced features (permissions, migrations, redundancy) when interacting with other accounts native to the protocol(s).
  • PolyProto, the new protocol on the metaphorical block, is experimental and not fully implemented into any server as of yet. Similar to Zot/Nomad, while it has ActivityPub style instances, it uses keys on the back end to provide easy migrations and user owned identifiers. It also, similar to Nostr & AT, supports custom extensions to the protocol, allowing interactions outside of the standard protocol if both servers/clients support it. A while back somebody on Lemmy asked people’s thoughts on the protocol, and you can see my more in depth ramblings here.

Definitions and Clarifications

A few notes on terminology.

Decentralized vs Federated vs Distributed

Decentralized and federated services are similar, but somewhat different, and it’s worth making a distinction66. Federated services consist of centralized services that can communicate with each other. Examples of federated social media protocols include ActivityPub or DFRN, and examples outside of social media would include email or the Matrix protocol. In short: you have your account on a centralized home instance, and your account/content is (more or less) tied to that particular instance. Your instance is then able to connect to other instances, getting copies of data from remote users and serving them as if they were part of your instance.

Decentralized services are protocols where users and/or data exist outside of any particular node/infrastructure. Examples of decentralized social media include Nostr and AT, and examples outside of social media include IPFS or the Briar messenger. In short: infrastructure hosts a copy of your posts and profile data, but your identity and post identifiers exist outside of any particular piece of infrastructure, moving between different nodes with minimal or no friction. Distributed is just my placeholder term that encompasses anything federated or decentralized.

Web 3

I used the term Web 3 a couple times in this post, and everytime I do, I figure it’s worth offering a quick clarification. Web 3, at least in the way I’ve come to understand the term, encompasses the wider (potential) shift towards a decentralized internet. Web 1 was the early nerds running closet web servers, and Web 2 was Facebook, YouTube, and Google. Web 3 covers a variety of things: from cryptocurrencies, to decentralized messengers, to file sharing protocols like IPFS. In the case of this post here, it mostly refers to distributed social media protocols.

If you’ve only heard of Web 3 in regard to NFTs, that’s because NFTs really didn’t have a selling feature outside of being trading cards built on decentralized web technologies. None of the protocols here are built on a blockchain or NFTs - a blockchain (distributed database) is useful for anything that requires consensus (e.g. transactions), but it would be unbelievably unwieldy to store all content on a social network in one database that’s distributed across every client or server.

Infrastructure & Services

I used the words infrastructure and services a lot through this post, and figured I should clarify those too. Throughout this post infrastructure simply refers to anything hosted - the sort of stuff you use outside of a client - such as ActivityPub instances, Nostr relays, or AT PDSs, Relays, & Appviews. I used services to refer to a setup hosted by somebody else, including one or more pieces of infrastructure. For example, I might call an ActivityPub instance, Nostr relay, or AT PDS a piece of infrastructure - and might refer to an ActivityPub instance or BlueSky (AT PDS + Relay + Appview) as a service. Like “distributed protocols” I’m just using it as my own made up terminology; agnostically referring to externally hosted things regardless of which protocol. The vibe is more or less aimed at infrastructure being anything somebody connects to or utilizes, and a service being a complete package a user might interact with through a client or web browser.

What I use, and why

If you’ve been following me for a while, you’ll probably know that Nostr is my favorite of the three. I like the protocol’s flexibility, and the protocol effectively gives you self-hosted ActivityPub instance level control over your experience - while not requiring you to host anything, and not barring you from participating in communities on other infrastructure. That said, I’m not married to the protocol, and I’m on all three (albeit less of AT lately, outside of bridged AT). That said, other protocols have their purposes too. You can’t beat ActivityPub’s ease of use and community building, and in plenty of circumstances I’d recommend it instead (or something like Streams bridged to ActivityPub).

And, of course, as time changes protocols might too - either changes to existing protocols, or entirely new ones being developed. This is, again, another reason why bridges are important. ActivityPub came along, likely only sticking around since existing projects internally bridged to it (Friendica, GNU social, etc); Nostr and AT likely benefiting from bridging in and out of ActivityPub. Things change rapidly - ActivityPub hasn’t even been standardized for a decade, and it was supplanted as the top dog several years ago. If/when platforms start adopting things, and as protocol development continues, who knows what will fall into place?

Footnotes

  1. Assuming that the spec is followed - which, I’ve heard, is not always the case. ↩︎

  2. Like I said, I’m trying to trim this post down a bit. That said, if you’d like to see my ramblings on the topic, you can check out the isolation section in my update post or the first part of the oddball activity pub issues in v2. ↩︎

  3. If you’re looking to avoid this issue, my recommendation is to find a smaller instance. Generally, the big instances won’t block small instances (as apposed to large instances blocking other large instances because of community bickering/drama, or because one instance doesn’t like the other’s blocklist). On the right smaller instance, you can be federated with just about everyone, at least everyone who’s a well meaning participant of the protocol. ↩︎

  4. When I say Nazis I mean literal Neo-Nazis, the kind of people who praise Hitler and have a swastica profile picture. I’m not talking about an “Anyone who disagrees with me is a Nazi” sentiment, which has caused the term to lose most of its meaning. ↩︎

  5. And I mean fringe people. Not the heavily partisan Bluesky kind, but the kinds of people on the right who make Truth Social look like Bluesky and the kinds of people on the left that make Bluesky look like Truth Social. ↩︎

  6. It’s the second oldest by completion date, to be specific. AT’s development started before Nostr, but Nostr was in a usable state and used in a distributed manner years before AT was opened up. ↩︎

  7. All three protocols, at the time of writing, have shrinking userbases. However, Nostr’s is the most noteable here since it went from the second largest (and close to the largest) to the smallest. See my latest update post for some late 2025/early 2026 context. ↩︎

  8. You are capable of identifying yourself with a username via domains on Nostr, however, on the back end everything always links to the key pair. ↩︎

  9. It’s been described as the spiritual sucessor to RSS by me and others. Although I feel like the most accurate, albeit less descriptive, summary of Nostr would be “The result of a love triangle between GPG, RSS, and Twitter.” ↩︎

  10. Because your keys, your client, and your preferred relays are different layers, you’re able to use different clients with the same account. Some clients are designed for specific purposes (e.g. long form blogging) while others are designed for general use (e.g. Amythest or Nostrudel). I’ll discuss this further in the compatibility section. ↩︎

  11. It’s also worth noting that, in the past, tech nerd hubs seem more likely to become mainstream than politically partisan places. The OG big tech social media sites (Reddit, Twitter, etc) were populated by tech nerds before they transitioned to a mainstream audience. I can’t think of any services that were primarily partisan, before transitioning to a more mainstream audience. ↩︎

  12. Key delegation is the process of having an external service manage your keys. While controlling your own keys is a very useful tool for controlling your own account, Jimbob Goober off the street isn’t going to know what asymmetric encryption is - much less the proper procedures of protecting one’s keys. Having the option of key delegation, alongside managing your own keys, is (in my opinion) the only means of opening the protocol to a wider audience. But trusting another service to manage your keys goes against the ethos of cypherpunk ideals, so it’s a somewhat controversial opinion to suggest that be an offered option. ↩︎

  13. There are a few exceptions, such as Red Dwarf, which is a client that directly retreives content from PDSs instead of relying on the relay layer, parsing it in the client locally in a similar way to Nostr. ↩︎ ↩︎

  14. A Relay and Appview are effectivly the same layer of infrastructure. A relay is a tool that fetches content from remote PDSs and makes it available in one centralized source. An Appview is a tool that parses a firehose of data (generally from a relay), and provides that content to a client. Some Appviews can fetch data directly from PDSs - forgoing a relay, and some clients may connect directly to a relay firehose - forgoing an Appview. For simplicity’s sake (and my two braincells not holding onto big words), I’ll going to refer the Relay/Appview combination as the Relay “layer” for the rest of this post like I normally do. ↩︎

  15. If you’re curious as to how this differs from Nostr, think of Nostr as an RSS client, and AT as Feedly. In your local RSS client - similar to Nostr - your device will manually reach out to each server that’s hosting a feed; parsing that data locally and providing it to you. On Feedly - similar to AT - a third party server has already fetched that data and parsed it on your behalf, providing it to you via a simple web interface or app. There’s pros and cons to both approaches: having a server parse it lessens the load on your device, provides a streamlined experience, and prevents you from needing to fix problems yourself when they arise. Having your device process things locally cuts out the middleman (nobody to tell you you’re not allowed to fetch a particular feed), provides you a greater degree of customization/control, and can’t go offline as a centralized service could. ↩︎

  16. If you’d like to read more about BlueSky’s abandonment of neutral infrastructure, I went into greater depth here in my previous update post. ↩︎

  17. For example, as I’ll talk about in a few paragraphs, DMs on BlueSky are not part of the AT protocol. Any BlueSky feature that is not part of the protocol itself could start interfering with how other people implement or use the protocol, as there’s no other ecosystem of services that could all come together and reach a consensus. ↩︎

  18. Again, BlueSky has DMs, but they’re not part of the protocol. They’re unencrypted and part of the BlueSky platform, not part of the AT protocol itself. ↩︎

  19. If you would like to read about things in a bit more depth, you can check out the partisanship and moderation/neutral infrastructure sections of my previous update post. ↩︎

  20. Telling people to just join Mastodon.Social is not always viable. First, because they have closed registrations in the past during sudden influxes of users. Secondly, because they have a rather large blocklist (including bridges), which may impair or entirely prevent a user from properly experiencing an open protocol. ↩︎

  21. It’s not that your run of the mill Jimbob Goober can’t figure out any of these protocols, and that they’re some arcane magic us fellow tech nerds can congratulate ourselves for understanding. For example, there’s a community of people from Tailand on Nostr because it went viral there on Tiktok. If Tiktokers can figure it out, it’s not all that crazy of a concept to understand. Still, like changing your car’s oil, it’s something the person would need to go out of their way to learn. ↩︎

  22. An example of user owned identifiers separate from social media protocols would be email. I used to host my email with Tuta, but had my own domain, so when Tuta had an extended outage, I was able to change a few DNS records and get incoming email sent to a different mail server. Had I been using an @tuta.io email address, my account would have been gone for as long as Tuta’s infrastructure remained offline. While having my own domain wouldn’t prevent Tuta from going down or banning me, it would allow me to keep my identifier (email address) regardless of which mail server I’m using. ↩︎

  23. Something to note, which I’ll delve into more deeply in the moderation section, is that portable identities/user owned identifiers do not affect moderation. On all three protocols, servers and communities can ban a user all the same, the only difference is that protocols with user owned identities can allow that user to participate in other places (that they’re permitted to participate in) using that same identity. ↩︎

  24. Many bans are warranted, and in a decentralized ecosystem (or any ecosystem really) it’s absolutely the right of admins to decide who’s allowed to use their infrastructure. That said, there’s also the issue of unfair bans to contend with (with ‘unfair’ being a relative term that will differ depending on who’s defining it). The fediverse in particular has some toxicity issues (see that section in my previous post), and this risk of losing your account after disagreeing on Linux distros or tax policy is probably something that should give you pause (or at least direct you towards using infrastructure run by moderators who are known to be reliable). Regardless, the question of what should happen to a user after they’re kicked off of infrastructure (for fair or unfair reasons) is something important to consider. ↩︎

  25. Theoretically, an instance admin/mod could inform a user that they’re about to be banned and not welcome on that particular instance, but allow them to migrate to another one. However, to my knowledge, no ActivityPub enabled software would allow a banned user to migrate to another service in spite of the wishes of their admins - except Holos. ↩︎

  26. Protocols such as Nostr, AT, SecureScuttleButt (and its successors like PZP) all use key based accounts nearly entirely. Protocols like Nomad, Zot, and the (in development) Poly Proto also all use some form of keys and/or alternative means of migration outside of relying on a single home server. While there are a few other protocols (DRFN, Diaspora) still in use that lean more towards an identity centralized around one’s instance, protocols newer than ActivityPub seem to have accounts somewhat or entirely separate from their infrastructure layer. ↩︎

  27. Tahake’s last commit was in 2024, and it has 10 monthly active users, so I’m unsure of whether it’s a legitimate potential option for users who want to control their own identity. ↩︎

  28. There is still the potential risk of losing an account even if you’re using your own domain. If you’re on something like Tahake, a mod could still ban your account (which may nuke your followers list), or a hacker could get into the server you’re on (such as a Tahake instance or your own personal server) and delete your account or migrate your followers list to another remote account that’s not you. Still, it gives you much more control than in other cases. ↩︎

  29. With the exception of something like Holos. ↩︎ ↩︎

  30. Groups, part of the Activity Pub spec, are the boards you’ll find in the Threadiverse (Lemmy, Piefed, Mbin), as well as communities in Friendica. You can participate within them from something like Mastodon, but it involves work arounds like @ing a community to post to it (with the first line being the title, the rest being the body - no support for link/image submissions). ↩︎

  31. If another client were to be developed to use the same custom NIP it would still work with the Treasures web app. However, if a custom NIP is written it’s likely going to be for a niche use case with only one or a handful of clients supporting it. ↩︎

  32. You can still use your same account and PDS across the different ecosystems, but can’t interact across each ecosystem. It’d be like if you could sign into YouTube and Facebook with the same account, and keep a local copy of your data, but couldn’t have any YouTube <> Facebook interactions (follows, replies, etc). Activity Pub and Nostr take a more laissez-faire approach - you may have some jank in Activity Pub, or need to use a second client on Nostr - but things remain interconnected. ↩︎

  33. Well, most ActivityPub enabled software calls them migrations, but I’m not quite sure migration would be the right word. I feel like re-direct would be more fitting: like an email, you might forward incoming mail to a new address and give your friends and services you use your new email, but the old account remains a separate, independent account. Then again, I’m just a dumbo arguing semantics. ↩︎

  34. Now, to be clear, I’m not really qualified to do too much in terms of deep technical stuff. I’m just a guy who finds things interesting. If you’re a dev or otherwise looking for a deep technical understanding, I’m probably not the person to go to. My point isn’t that I deeply understand technical things and that my thoughts should be listened to on such a level, just that I’ve seen technical people and devs who know a lot about other protocols not fully understand how moderation works on key based stuff like AT and Nostr - which made me think covering it would be a good idea. ↩︎

  35. To better clarify, it works by hiding content from ‘silenced’ people/instances - only being visible to those who specifically followed them. If I followed [email protected], but my hypothetical Mastodon instance silenced his instance/account, I would still be able to view his content like any other user. However, his posts would be hidden from anyone who didn’t intentionally follow him. His posts would not show up in the remote timeline, and if I reposted any Jimbob Goober content, my reposts would be hidden from all my followers who weren’t already following Mr Goober. While the word shadowban might have a negative connotation, it’s still the best word to describe it, though it’s worth noting that the silence feature isn’t inherently good or bad, just a tool that could be used in a good or bad way. ↩︎

  36. There are a couple exceptions to this. First, if user@domain blocks jimbob@goober, and jimbob replies to a post, people on the goober instance will still see the reply. However, people outside of the goober instance won’t be able to see the reply, as all other remote instances fetch the post and replies from the domain instance, which won’t forward that reply. Secondly, that’s assuming that events are not forged. ↩︎

  37. For example, JimBobGoober follows Alice and Bob. Alice and/or Bob blocked and/or reported TotallyNotABot. Many clients, such as Amythest, will automatically hide TotallyNotABot if configured to do so. ↩︎

  38. Something like the Red Dwarf client fetches content directly from PDSs, forgoing the AT Relay layer (similar to Nostr or an RSS reader). In that case, AT would function similarly to Nostr, pulling account data from PDSs that you chose to follow, with minimal to no intermediaries to set additional moderation policies. ↩︎

  39. For example, JimBob is blocked by Goober. While nothing in their PDSs will prevent JimBob from replying to Goober’s posts, some appviews may automatically hide JimBob’s replies to Goober from all users of that service. ↩︎

  40. It’s worth bringing up that, while I believe it would be much lighter in theory, I haven’t tested running a Holos relay. I did try giving it a go, but I went to install it and got some dependency errors I couldn’t resolve, and I’m lazy, so that wrapped up my experimentation for now (it’s still in development, I expect the script will be updated soon if it’s not by the time I post this). Still (theoretically), with it offloading a lot of processing and content caching to the client, it should be much lighter. But, with all the different implementations of all three protocols, the resource requirements/scalability are largely ‘vibes’ based, painting with a broad brush. ↩︎

  41. For reference, I often read Nostr on a very underpowered laptop, which sports a total of 2 GB RAM and an old Intel Bay Trail processor. Even with the Outbox model enabled on Nostrudel, likely the most resource intensive setup one could be in, slowness is fairly minimal. Any modern device, or even simply slightly less outdated devices, should be able to perform those sorts of functions without struggling. ↩︎

  42. To note, while spam and bots sometimes overlap, they don’t always. Spam here refers to a mass creation of posts, often identical, with several potential motivations: pushing out information (e.g. spamming links to a particular product or service), attempting to overload infrastructure with a large number of posts, or attempting to degrade the experience of people using the protocols. No protocol has specs that would prevent LLM powered bots that attempt to push propaganda, or something similar, that would appear to be a standard user at first glance. Those types of bots, to the limited cases where they could be detected, would have to be managed by real people performing manual moderation. ↩︎

  43. Meaning that the spam, while targeting AT, originated on Activity Pub &/or Nostr - using bridges to make its way onto AT. ↩︎

  44. If you’re unfamiliar, NIP-05 domain based usernames just point to your key - providing a human readable means of finding your key based accounts. While services to provide a NIP-05 username with their domain exist, that does not mean handing over the control of your account. Even if the service becomes malicious or goes down, users who followed you will remain since they follow keys instead of domain based usernames. While technologically not the same, think of it as clicking a link from a URL shortener and then bookmarking the URL that it lead you to. ↩︎

  45. In order to have the BlueSky relay index an unlimited number of accounts from your PDS you need a special exemption manually given to you. Bridges are one of the handful of services that have been granted that, and BlueSky would likely be hesitant to block a bridge to combat spam attacks, so that’s likely why the spammers chose a bridge. Outside of bridges, there are not a lot of inroads for spam that don’t require a clean IP, as well as email verification and captcha completion, to begin participating in mainstream AT. ↩︎

  46. To further expound on that, what’s the median lifespan of an instance? Sure, Mastodon.social is probably going to be around for a while, but not every instance is going to be as long lasting. Even long lasting ones go down eventually, like Nerdica.net, which stuck around for 10+ years before a SQL database error nuked it (and my account). People die - or abruptly give up on hosting an instance, domain renewal can be forgotten (or seized by the Taliban), and servers can be hacked or randomly go ka-boom. Your instance is probably going to survive the next year, but how about the next 10 years? 30 years? For people planning to have an account for the long haul, if identity management isn’t altered a bit, there are a lot of people set to be disappointed when they lose their account. ↩︎

  47. Holos does that, and if you’re looking for an account you control, then it might be worth looking into. However, this isn’t part of the Activity Pub spec, or doable in most implementations. Holos gets around the protocol with metaphorical duct tape and bubble gum, making a Holos client an Activity Pub server, and a Holos server more of a CDN than a standard Activity Pub instance. Implementing something that allowed a client to forcibly migrate from an offline instance is, in my opinion, a much needed tool. ↩︎

  48. An NSEC bunker, or remote signer, is generally an app on a phone or computer that signs events. For example, I can setup an NSEC bunker on my phone, then sign into a client on my laptop I take to work; my phone signing events instead of copying my NSEC to the laptop. Ideally, you would use an NSEC bunker for most clients and apps, having only one (hopefully) well trusted app that has your NSEC on a (hopefully) well trusted device. If anything else were to be compromised, or you wanted to delegate access to your account (e.g. a corporate account accessed by employees), you could revoke that access and not lose your account. However, you still need to trust the bunker app and the device it’s on. ↩︎

  49. There would be exceptions, like signing events offline and copying them to an online device to be broadcasted. Or simple hardware signers. But those are exceptions, not the rule, and would add a lot of friction to a protocol that already is not friction free. ↩︎

  50. To clarify, this would be separate from a NIP-05 domain based username. Under NIP-05, the username [email protected] might point to the key npub123xyz. However, if a user follows [email protected], then the NIP-05 username is later changed to point to npub321xyz, the user who already followed [email protected] would still be following npub123xyz. Under NIP-05 the key is the real identity; the domain username simply being a more readable shortcut to get the hash of the user’s key. In my hypothetical example, the domain would be the ultimate authority. In that case there might be a text DNS entry in the domain example.com that says npub123xyz=jimbobgoober. If the DNS entry was updated to npubabc321=jimbobgoober then people following [email protected] would go from following npub123xyz to npubabc321. ↩︎

  51. To any cypherpunks about to send me an angry email, yes, I prefer to control my own keys. And yes, I think most individual users would be better off controlling keys instead of controlling a rented domain. Still, that doesn’t always scale. “Not your keys, not your account” also translates to “Everyone who controls the keys controls the account” which would be bad in a corporate setting, which might prefer a domain name owned by the company - said ownership being enforced/reversible by courts - to be the final authority. It also wouldn’t matter in a situation the user is already delegating keys (platforms/bridges), in that case they don’t control the account either way, but the person they’re delegating to might be able to recover accounts or give them over to the user more easily. And finally, some people might just prefer to use their domain instead. Having that option (or something similar) could be very useful, and be a deciding factor in whether many people, platforms, and companies adopt the protocol. ↩︎

  52. That, and verification at other levels too (e.g. OSs). But this particular level is the only part relevant to these protocols. ↩︎

  53. Ha, six seven ↩︎ ↩︎

  54. Remember, software like Friendica - with it’s Facebook style friends lists and post visibility options - is native to DFRN. There are actually several protocols adjacent to Activity Pub like Diaspora, DFRN, Zot, and Streams that have more fine tuned post permissions figured out. It’s not that it can’t be done, just that none of the big three do it well. ↩︎

  55. Most notably, there’s Lockbox by Fiatjaf, a relay that delivers posts only to people you’re following, using NIP-42 for cryptographic verification. Just like Activity Pub, however, it’s a bit janky since the protocol is focused on public content. There’s also nothing stopping the user’s client from automatically re-broadcasting it to public relays, even accidentally (such as after a reaction or re-post). I also attempted to write a custom NIP to add groups style functionality to something like that, but current (working) client support is 0 - while still running into the same issue of things easily being re-broadcasted as public. ↩︎

  56. Well, I should say, they’ve survived so far on a very limited userbase. YouTube has ~2.6 billion monthly active users, and Facebook has ~3 billion monthly active users. Even a ‘smaller’ social media platform like X has ~600 million monthly active users. Something like Mastodon.Social has ~300 thousand monthly active users, and Activity Pub and Nostr as a whole have network wide userbases in the hundreds of thousands. Trying to scale them up, even to a tenth of what larger platforms have, would require radical changes to funding. We’re already seeing that with AT/Bluesky - even at 1% the size of X, it’s already needed to take venture capital funding because they don’t have a stable monetization strategy. ↩︎

  57. Mastodon.social has closed registrations before when there’s been mass influxes of people, so just joining the flagship service is not always possible. ↩︎

  58. No shade against people earnestly promoting self hosting, or self hosters in general (I self host several things myself). My complaint is directed more towards people who just assume everybody’s going to self host eventually (baking that into their mental model of how the ecosystem will work), and people who push it more aggressively. Ironically, it’s those people who’ll likely pave the way for platforms. “Yeah, of course, people will commit to forever hosting their own Peertube instance to share the occasional video” then “Oh no, why is our ecosystem not taking off?” ↩︎

  59. Aside from email, a few other examples could include: web browsers; instead of needing specific browsers like IE for sites, you can pretty much use any browser you want, even if most browsers are built on WebKit or Blink. Or operating systems, instead of just Unix, then Windows; most operating systems are based on the Linux or BSD family of OSs (such as Android, ChromeOS, SteamOS - even PlayStation and Apple devices, despite the latter two being closed source on account of the MIT license). And yes, as much as Windows still has a hold on desktop operating systems, Android is the world’s most popular operating system (not to mention embedded things from cars to fridges). SMS, Git for source control, even in the future potentially Matrix for chat applications, the list goes on. ↩︎

  60. For example, even if a static 5% of people changed their own oil, more drivers means more people changing their own oil. And, with that, come more stores stocking oil changing supplies at competitive rates, more online tutorials, and more people IRL to give guidance or advice on oil changes. ↩︎

  61. Like using RSS for content, if platforms implement the protocols, they become a lot more interchangeable. If you can follow people across many different platforms using one centralized account, migration from one platform to another becomes a lot more trivial. ↩︎

  62. There have been some, in my opinion, very misguided controversies over bridges in the Activity Pub space. If you’d like to hear my thoughts, check out the isolationism section in my Dec 2025 update post. ↩︎

  63. Streams, Zot, DRFN, and Diaspora all have all Activity Pub features, plus bonuses. If you join something like Streams, Hubzilla, or Friendica you’ll be able to participate in the Activity Pub ecosystem as if you’re on an Activity Pub native platform (I’ve seen plenty of people not even realize they’re based on another protocol). That said, the bonus features won’t carry over. For example, if you’re on Streams and your server goes down, your Streams friends will carry over while your Activity Pub friends will not. ↩︎

  64. Dennis Schubert made two posts on the topic of why Diaspora never adopted Activity Pub in the project if you’re interested: Activit Pub: One Protocol to Rule Them All & Activity Pub: One Year Later - Final Thoughts ↩︎

  65. Yes, I know, some people like to call it (streams) because it’s an “unbranded” project, and only the git repo has a name. But, come on, guys, that feels a bit silly. It has a name given to it in the codebase, and we need to call it something, so I’m just going to call it Streams. ↩︎

  66. For a more in depth read, check out Kevin Cox’s post on the topic ↩︎