ActivityPub/Nostr/AT-BlueSky Compared
Note: This post is out of date, here’s a more up to date version
Update August 5th 2024
I have some good and bad news regarding this post. First, I made two mistakes. AT crawlers are not in fact crawlers, they are called relays. Also, shared inboxes are actually part of the Activity Pub W3C standard as apposed to hacky additions to the protocol by third party servers. I was wrong about Activity Pub servers sending multiple messages to the same server remote to update it about a single post.
The good news is that this post really got shared around a lot. A week or so ago I was bored and ran one of those backlink checkers websites and found this post was shared around a lot, including in the ORiley Media trends newsletter, TechRights, Hacker News, and a handful of other sites and blogs. I assume that it was just because I posted this and then a week or so later BlueSky opened up (registrations at least, federation would come later) and I by random chance happened to be one of the few people who had written about this topic at that time. I just hope that my disclaimer of just writing as a layman about things that interest me was noted given there are at least two mistakes in the text below.
Also, as I said in the above paragraph, BlueSky did open up. First it was opened to registrations, but did not allow you to self host your own PDSs. Some time later the BlueSky relay did start crawling self hosted PDSs, so it’s fully opened up at the time of me writing this update.
With the mistakes, changes to BlueSky, and a general feeling I could have organized the post a bit better I am working on an updated version of this post that I’ll probably release sometime in August or September. Anyway, that’s all I wanted to update the post with, everything below this paragraph is the original post that I made ~8 months ago.
Distributed social media networks have been on my mind for a while, especially during my deep dive into Nostr over the last few months. Being on my mind I started writing a comparison between the big three, which sort of morphed into this. I should clarify that I’m a layman here: I’ve never participated in the development of any of them, or the development of anything built on top of them (nor the development of anything complex at all). I have tried to cover my bases by looking into each one and clarifying things I assumed, but with such a broad list of topics there’s a chance I’m wrong about something here.
Still though, I think a broad fairly technical bird’s eye view of how each compares could be useful, or if not at least somewhat interesting to those with similar interests to me. The plan is to introduce each protocol and then list off how I believe they perform in the following categories:
- Server Load/Simplicity - How resource heavy is it to run a server?
- Ease of Use - How easy is it to join, and after joining how easy is it to master?
- Account Ownership - What degree of ownership do you have over your account?
- Client Load/Simplicity - How much does your client need to process?
- Client Side Customization - How much does your client let you choose what you see and how you see it (as opposed to what’s set by a server)?
- Portability - How easy is it to migrate an account and data?
- Malleability - How easily can the protocol be used in other projects/platforms while still retaining some or all interactability?
- Direct Messages - What’s the state of direct messaging?
Afterward, I figured I would go over my thoughts on the state of the protocol as it’s currently being used:
- Growth - How has it been growing in use?
- Scaling Issues - What scaling issues do I foresee if we continue as it’s implemented now?
- Moderation & Community - Are there issues with quirks in the community or moderation protocol wide that could hinder the protocol’s adoption?
- Future Changes - As a layman, what changes would I propose that I believe could add value?
- The Perfect Model, and Conclusions - What’s the perfect use case and my final thoughts?
There’s no right or wrong answer - each protocol has different pros and cons - so let’s get started.
Activity Pub
Activity Pub is the oldest decentralized microblogging protocol still widely used today, which development started around 2014 and was adopted as a W3C standard in its current form in 2018. As the oldest of the three it has the most momentum in both userbase and adoption on more ‘mainstream’ platforms. Most projects that integrate Activity Pub resemble a traditional service at first glance (i.e. accounts and posts on a server in a local database), but the inclusion of Activity Pub allows accounts on remote servers to interact seamlessly in most cases, or partially if the two projects differ significantly.
Server Load/Simplicity
The comparison between email and Activity Pub is often used to explain federation, and I would like to extend that explanation by comparing how the server handles communication to an email mailing list for discussions. It’s not a 1:1 comparison, but fairly close. When somebody makes a post it’s stored in their server’s database, which then provides a copy of that post to all followers on other instances (as a side note, it sends a copy per follower, meaning if 10 users on one server follow the same user on a remote server that remote server sends 10 copies of the message). Any interaction with the post from a remote server (e.g. likes or replies) is sent to the server that hosts the account that made the post, and then that server broadcasts those interactions to all other servers similarly to how it broadcasted that original post.
The duplication and constant communication brings smoother federation and allows you to access content in a limited fashion even if the origin server is having difficulties. However, it also means there’s a considerably larger load on the server than on other centralized and federated/decentralized protocols.
Ease of Use
While a more subjective thing to compare, I would give Activity Pub a moderate difficulty to join and a moderate difficulty to master. Trying to put myself in the shoes of somebody who doesn’t work on tech for a living; figuring out what server to join, and the concept of independent servers interacting with each other would likely take a little reading, but otherwise isn’t a completely foreign concept - and the “it’s like email” explanation would probably give a good bird’s eye view of the protocol to anybody with tech literacy. With the basics of federation learned and an instance joined, the idea of learning things like defederation or account migration wouldn’t be a big jump in difficulty.
Account Ownership
On Activity Pub accounts are controlled by the server and not the user, and while in practice most servers will treat you well, the server and not the user has the final say over the control of an account.
Client Load/Simplicity
Because federation and accounts are controlled server side on Activity Pub, clients are lightweight. This is beneficial in both that a client is easier to make & configure, and in that a client won’t be bogged down even if it’s logged into an account that’s heavily federated or otherwise very active.
Client Side Customization
While a user can elect to block particular users, keywords, or instances; a majority of what the user sees and can interact with is setup by the server admins. This does allow people to join a server with policies in mind, but if those policies are changed or the user changes their mind on which policies are desired their only option is to migrate to a different server (if permitted by the local server) or start fresh.
Portability
Portability on Activity Pub is fairly poor. Accounts can be redirected from one server to another if both servers allow it, and followers will automatically follow the new account if their server is properly federated with both the old and new server; so Activity Pub is capable of allowing some form of portability. This, however, is about the limit to what sort of migration is possible. If the server is taken offline, the account is banned, or the server they’re migrating to is defederated then migration is limited or impossible. Defederation can mess with migration if the migrator’s original instance is defederated with the new instance or vice versa, and followers will not transfer over if a follower’s instance is defederated with the original instance or new instance of the person they are following. Migration of posts or changes to a server’s domain is generally not possible either.
Malleability
Again, while somewhat subjective, I would rank Activity Pub as moderately malleable. While Activity Pub is implemented into a wide variety of projects, and can usually interact with the various projects at some level, because everything is handled server side there are limitations to how it can do so. For example, Mastodon and Lemmy allow limited interactions but are unable to fully process posts cross-platform as well as with another instance running the same project.
Direct Messages
While direct messages are likely less of a dealbreaker than other features, they’re still worth bringing up in this comparison. Activity Pub offers fairly bare-bones messaging: a user can send a direct message to another user on most Activity Pub platforms, however, it remains unencrypted and since accounts are controlled by the server the messages can be intercepted or hijacked by a malicious or compromised server.
Activity Pub’s Current State
My opinions/interpretations on the current state of Activity Pub and its potential future.
Growth
Of the three discussed here, Activity Pub has had the largest growth by a considerable margin, and being first it has had the most established communities and the largest amount of recognition. This has also led to its adoption or planned adoption in various “corporate Twitter alternatives” such as Threads, TruthSocial, and Gab (in order from largest to smallest); as well as similar interest from non-microblogging platforms such as Tumblr, Getty Images, and GitLab.
Scaling Issues
I believe the largest issues Activity Pub will face when scaling up the network is the increasing need for computing resources to interact with large instances and fragmentation. The need to replicate such a large amount of content could disrupt one’s ability to interact with large servers from a small VPS or busy home server, and greatly increase the cost of running the large servers that can scale to meet the demands.
Beyond activity pub’s potential scaling issues due to its more resource-intensive nature, there’s also an issue with moderation/federation that I perceive to be a second potential issue. My summary is almost long enough to be a short blog post in its own right, so click the dropdown below at your own peril.
Problematic Communities and Problematic Defederation: a dropdown tale of epic complaints
Let me tell you a story, a long one, about internet drama.
Being the oldest to stick around, Activity Pub has been at the center of everybody trying to leave centralized social media platforms. This included people who like technology and the idea of owning their own “internet identity,” but it’s also included the misfits that social media isn’t too keen on (Nazis, child predators, tankies, etc), and as so far as Activity Pub has been the center of distributed social media it’s also been the hub for those kinds as well. My understanding is that those sorts of hubs have always quickly quarantined off, but things escalated when the then-largest instance Gab joined the network.
Lots of admins chose to defederate with Gab, but then a lot of instances also chose to defederate with any instance that didn’t also defederate with Gab. Given a few years followed by the influx of users from the hellscape that was, is, and always will be Twitter and defederation has gotten a lot more common - and in my opinion an overcorrection. Defederation can now happen many degrees separated from instances (A defederates with B because B is federated with C and C is federated with “the bad people”), and as the landscape of what people would think of as the mainstream “fediverse” has shrunken, the people demanding stronger defederation have gotten louder voice by comparison accelerating how aggressive it can be.
A good way to elaborate on this is to tell the saga of the defederation of infosec.exchange, a benign instance dedicated to information security. One day CISA (the US Federal agency focused on things like best cybersecurity practices) was being impersonated a lot on Activity Pub and chose to create an account. Not to use, but to sit there as a placeholder they can point to in order to decrease impersonation. Naturally, they chose the benign instance dedicated to information security.
All hell broke loose.
Alright, that may have been a bit of an exaggeration, but there was a mass defederation across the network from infosec.exchange. People following users on infosec.exchange couldn’t see their posts, and people on infosec.exchange couldn’t interact with many of the people they followed. Furthermore, because instances operate accounts, people migrating away from infosec.exchange couldn’t take a number of their followers with them since those followers were blocked from interacting with infosec.exchange. Anybody who chose to migrate away also lost all their post history and community.
And this was because CISA, what has to be like the least controversial portion of the government, registered a placeholder account on the server. It’s my opinion that as what gets defederated expands, it could become a serious issue for the growth of Activity Pub fragmenting and prevent real growth. There is probably a large number of servers that would be considered “mainstream Activity Pub” only federated with ~5%-20% of the Activity Pub network. With the calls to defederate with Threads, that could probably jump to many of the larger servers only being able to interact with ~0.1%-1% of the network.
With all that said, it’s my opinion that fragmentation and an unstable list of servers that can or cannot interact is a potential issue for the adoption of Activity Pub.
Moderation & Community
Mostly see my above dropdown, but to summarize Activity Pub currently houses some of the less-desired groups in its unfiltered form, and moderation of the unfiltered Activity Pub firehose can sometimes be an overcorrection.
Future Changes
Recommending changes to protocols is very much above my pay grade, but that won’t stop me from rambling on about it anyway. The first future change I see bringing value to Activity Pub would be to lighten the load on servers. This was already done for videos by canceling their duplication across federated servers and only linking to the original source, and I can imagine low hanging fruit would be to do the same for images and the like. I also foresee value in lightening how servers communicate while federating content, such as more efficiently pushing out updates.
Beyond that, I think an intentionally lightweight fork of something like Mastodon (beyond something like Pleroma or GoToSocial does) could also be beneficial. I can imagine a lightweight server with no federated timeline (duplication of all the known network), the above changes in the first paragraph, and possibly even one that hands the responsibility of outgoing communication and archival of remote posts to the client (pop3 instead of imap kind of deal) could be beneficial in creating a super lightweight server for those who’d be willing to accept the trade offs.
Finally, I think there would be value in some form of optional identification outside of the server’s domain, such as something that resembles Nostr’s key-based accounts, Hubzilla’s nomadic identities, or Nostr & AT’s ability to use your domain to identify your account. This would allow users to retain some level of ownership over their identity outside of a server that could go down, while also preventing malicious control of a user’s account by an admin, and providing somewhat more seamless migration regardless of the server’s state.
The Perfect Model, and Conclusions
I believe Activity Pub excels at what people have called “the islands” model. That being smaller interconnected servers, often having a lot of communication between members of the same server but also capable of communicating with anybody else on any other ‘island’. Smaller servers would negate the potential heftyness of the software, and allow self hosting to be really easy and use minimal resources. In a world where the future of microblogging protocols is largely made up of smaller self hosted systems for individual communities (from topics such as tech to small friend groups), Activity Pub would be the way to go.
Continuing with the landmasses metaphor, it’s also an alright model for large instances as metaphorical “continents” as well. I’m confident that Threads, Tumbler, Mastodon.Social, and similar large instances will have the resources to keep up with a relatively heavy load while offering communication between their various servers.
Last, I believe Activity Pub also excels in smaller groups with at least one ’techy’ guy or gal. Unlike some models such as Nostr, as long as somebody has the technical knowledge to set up a server the rest of its users won’t need any technical expertise beyond what it would take to set up a normal social media profile.
Overall, I believe Activity Pub is here to stay, and while I do think there are some minor issues to work around or through, I expect it to be a major player in the growing decentralized social media platforms and I expect it to bring a lot of value to a lot of people.
Nostr
Nostr is the newest of the three microblogging platforms, being released in 2020. Nostr is a decentralized social media platform that uses key pairs to identify accounts and sign messages, which are then pushed out to relays (servers) that mirror a copy of the posts. Posts are always only plain text, though links to files are generally displayed in clients as if they were embedded into the post, and the client itself handles the combination of content from relays into one large user defined network.
Server Load/Simplicity
Standard Nostr relays, given they don’t communicate with other relays or store anything beyond signed text, are very lightweight and by far the least resource intensive to run.
Ease of Use/Simplicity
While again, this is fairly subjective, I would consider Nostr easy to join but difficult to master. Joining Nostr is extremely easy: install an app and generate a key pair (which could be explained as a username and password that can’t be reset), and the app will already have you plugged into default relays and set to start posting. There’s no further registration, risks of joining on a bad-for-you instance, and a well explained 1-2 paragraph introductory by any good app during the account creation process.
However, beyond account creation, it takes a much more difficult turn. I imagine trying to explain to somebody relatively tech illiterate what asymmetric encryption is, only to quickly pivot to the fact you’re generating signed messages and mirroring them on servers called relays, would be a difficult conversation. Further, if keys are lost or stolen the account is irrevocably destroyed, which could spell a lot of headache to anybody who’s trying out the technology without fully understanding it.
Account Ownership
Because accounts are key pairs with posts mirrored on relays, the user is entirely in control of their account. While relays can restrict who can post to their specific relay or moderate what is posted on them, no person other than the holder(s) of the key pair can control the account itself in any way.
Client Load/Simplicity
Because clients handle the combination of data from different relays into one large “network” of the user’s configuration, Nostr clients have more work than clients of other protocols. With a low powered device or a slower internet connection, a client can be bogged down if it’s forced to process a lot of data all at once (such as viewing the global timeline of a large number of relays simultaneously).
Further, because of Nostr’s fairly broad ambitions to add large amounts of functionality, clients may or may not support all features that are possible within the network.
Client Customization
Because account ownership and interactivity between relays occur client side the user can heavily customize their “network” and how it operates. For example, by setting one or a group of relays to make up the global feed, or by prohibiting particular relays from delivering content such as direct messages from other users. Similarly, unlike Activity Pub it’s entirely up to the client what relays do and do not get communcated with. For example, if you wanted to follow a particular user on an otherwise problematic relay you can set that particular relay to stay out of the global timeline and not deliver private messages, but still allow posts from the user(s) you followed to show up in your home timeline. In this way, unlike a federated protocol, it’s up to the user to choose what is part of their network. While a relay can moderate what content is on that particular relay they cannot moderate what other relays users of that relay use or communicate with.
Portability
Because accounts are based on key pairs, and because Nostr users almost always have at least a couple relays set up, if a relay goes down (temporarily or permanently) the user will likely not even notice unless their client notifies them of such as their content (and likely the content of the people they follow) is spread across multiple relays. Similarly, if a user finds they want to change up what relays they do or do not want to participate in it’s nothing more than changing them and continuing without any need to migrate or relocate their account.
Malleability
Nostr as a protocol is very simple and has often been described as the spiritual successor to RSS. Its simplicity, its ability to support extended functionality through NIPs, and its overall lightweightness makes it particularly malleable and a good candidate to be built upon. Similarly, because account management is entirely client-side, as long as a particular client supports what is built upon Nostr there’s no need to worry if a server you’re on will support the particular features or services implemented.
Direct Messaging
Nostr is a mixed bag when it comes to direct messaging, and not ideal in my opinion. While messages are end-to-end encrypted and have the redundancy of multiple relays passing along the encrypted message, the encrypted message itself is publicly accessible like any other post. Though it cannot be decrypted unless one holds the private key, it does make a public record of who’s contacting who and provides the risk of future decryption if technology advances (keep in mind 38-bit encryption used to be military grade, now decades later it’s a joke).
Nostr’s Current State
My opinions/interpretations on the current state of Nostr and its potential future.
Growth
Nostr has experienced a particularly quick growth in the short amount of time it’s been around, growing at a considerably faster rate than the other two protocols discussed. Nevertheless, it’s still new and smaller, and some of the growth can be attributed to the Twitter exodus making the earlier days of decentralized social media a poor comparison to Nostr’s launch.
Nostr has also had some integration into other social media services such as Minds, which similar to Threads can offer infrastructure to users through a profit driven business model.
Scaling Issues
The largest scaling issue I foresee for Nostr is the scaling of “hub” relays. While many smaller relays exist to serve smaller groups, it’s likely many people will want to be capable of following anybody on the network and want to be capable of being followed by anybody on the network. This will likely mean that there will continue to be half a dozen to a dozen relays where everybody is a member of at least one or two that act as hubs of the network that keep everybody interconnected.
While the small gardening relay or the friend group who wants their own space probably won’t have difficulty paying the $3-6 VPS bill, the larger hub nodes will need to fund a much larger bill to continue to exist.
Moderation and Community
The English speaking portion of Nostr is currently heavily populated by crypto enthusiasts, with many of the remaining people being categorized as cypherpunks, technology enthusiasts, libertarians, or a combination of the four. While continued growth brings in a broader group of people, and user curation can create a network more curated towards particular interests, the concentration of those groups can push other people away.
Further, on moderation specifically, most relays do not require any sort of registration to participate and heavily rely on automated moderation tools. While in my experience the network I’m participating in has been fairly free of problematic people (minus the occasional spam or rude comment), I expect that if the community grows it may experience growing pains in the form of a sudden uptick in problematic posts as it’s fairly easy to generate many key pairs and then act with impunity.
Future Changes
Again, while not exactly my expertise level, I thought I would go over some things I would expect could bring value to Nostr. First is the idea of a DHT layer that acts entirely independently of relays. DHT, short for distributed hash tables, would be the idea of creating a decentralized network (almost identical to IPFS) that would allow any client/relay running the software to optionally distribute posts to and pull posts from any other account also using a client/relay with DHT. Something like this would allow a phone or computer to effectively host their posts or other’s posts of their choosing if integrated into a client, and could likely also allow the creation of ‘universal’ relays that can pull posts from anywhere or distribute someone’s post to anyone also using DHT. Given the small size of posts, this would likely be easily feasible, and if used in conjunction with normal relays this would likely serve as a means of solving the ‘hub relays’ issue I talked about above.
Further, I believe the protocol would benefit from having some means of better locating users on other relays. Whether that be having some relays ‘gossip’ (effectively some form of federation/duplication among relays that choose to do so), having some sort of search tool in clients that can find an event (post) from other relays even if it’s not added to the user’s relays, or have some sort of tagging on events as to where the post was originally mirrored on (though this is sort of accomplished oppositely by ‘broadcasting’ a post to all your relays if you re-post it).
Finally, for the possibility of large scale adoption, I foresee the need for a service (or set of services) to come out that hides keys and NPUBs (probably utilizing NIP05s in its place) on the backend. Something that allows users to register like a centralized/federated social media service but remain able to interact with other Nostr users. Something like Ditto or a more mainstream-friendly version of Minds are potential contenders for something like this, and would prevent the technical knowledge barrier to participating on the Nostr network.
The Perfect Model, and Conclusions
In Activity Pub’s summary I talked about islands, and in Nostr’s summary I’ll use the metaphor of roads. All roads lead to Rome (or so they say, I doubt that the roads I travel on cross oceans), and on Nostr all communities branch out in a number of ways, but most have their content make its way to the metaphorical ‘Rome’ which is those main relays I’ve been calling the ‘hub relays’. This is already happening as there are sets of communities branching out in different directions from the English and Japanese speaking Nostr communities (the two biggest languages I’ve witnessed on Nostr, albeit it’s happening across numerous different languages).
In this way, there’s a plethora of relays that house individual communities and groups, and those individual relays often could be grouped up into sets of relays with a lot of people participating throughout a number of them, and then almost everything eventually makes its way (by the original user’s relay configuration or by re-broadcasts) towards the center of the network and the hub relays. In this way I believe Nostr is at its best simultaneously in the two extremes, both in having insular communities interacting among themselves and as a ‘city center’ model where anybody can interact with anybody on the network if they choose to do so.
While being new, and having some potential issues to work through such as the expertise requirement and scaling the hub relays, I believe Nostr has a lot of promise and will play a large part in the decentralized social media landscape.
AT Protocol
The AT protocol was originally a secondary project within Twitter, which has since been spun off. It’s the red-headed middle child off playing alone in the corner of the three decentralized protocols I’m talking about today, coming out in 2019. I originally assumed it was “not made here syndrome,” where its developers liked Activity Pub but didn’t want to use something they didn’t have total control over. In researching for this post, however, I realized I was mistaken and AT has some unique ways of addressing a distributed social media protocol that both have a lot of promise and could be considered something of a hybrid between Nostr and Activity Pub.
But if it has some promise and is older than Nostr, why would I be referring to it as the red-headed middle child off in the corner and an interesting hybrid? Well, that’s because even though the protocol is older it only really exists on paper and as the base for BlueSky, which is effectively centralized and not really a good proof of concept of a decentralized network. As such, I feel the least confident in my ability to compare it as accurately as the others, but will go over what it could at least do on paper if utilized as a real distributed social media network.
Server Load/Simplicity
Discussing the resource requirements of AT is a little more difficult, as it splits most of its function across two types of servers: PDSs (personal data servers) and crawlers. PDSs are what you would think of as a server on a decentralized social media network, they house content from accounts that are a part of that PDS. PDSs are fairly simple and lightweight, they’re mostly just a simple repository of all content and interactions of the accounts on that PDS and don’t do much beyond house the account and its content.
Crawlers are the second layer on top of PDSs and access data to facilitate the a specific application built on AT. The crawler is what would access data from various accounts spread across PDSs and aggregate it for a client to use.
This makes AT fairly lightweight in the sense that it’s separated into two types of servers. Most individuals would likely be hosting a PDS, which is lightweight because it’s simpler and outsources the work of aggregating data to a crawler. A crawler is more lightweight than an Activity Pub based service because it only accesses content on remote servers instead of hosting on its service while duplicating content from remote services alongside processing and outputting the data for users.
Ease of Use/Simplicity
This is hard to say. How easy it would be to create and manage an account on a PDS, or to configure a client to use your own or a third party’s crawler, is hard to say outside of the more centralized BlueSky that I have not used (and could not without an invitation). To properly judge this not only would BlueSky need to be opened up but other projects/configurations would need to be added to the AT network.
Account Ownership
Accounts on the AT protocol are cryptographic and in the control of the user. While accounts are tied to a particular PDS, they are intended to be migratable to a new PDS as the user holds the cryptographic keys. Given AT is effectively BlueSky, and BlueSky is effectively centralized, further discussion of the pros and cons of AT’s account ownership in a decentralized manner would be more difficult.
Client Load/Simplicity
Clients, posting to a PDS and receiving content from a crawler, do not have to process much information.
Client Customization
The amount of configuration and customization you can get from the AT protocol is theoretically both very limited and very advanced depending on how you consider it. Given PDSs are fairly simple and can be accessed by any kind of crawler, the data on the network posted by accounts could be used in a very wide variety of ways by various crawlers. However, since crawlers serve a more specific goal the use of a client utilizing a specific crawler would likely be limited to the tailor-made experience setup by the crawler and client. Again, as AT is effectively BlueSky, and BlueSky is effectively centralized, a lot of this is more ‘on paper’ than ‘in practice’.
Portability
Because the AT protocol uses cryptographic identifiers accounts are intended to be portable between PDSs, but at the time of writing the protocol’s process of doing so is still in development.
Malleability
Exact answer as in “Client Customization,” a lot could be done with the data on PDSs, but data read from crawlers and output to a specific application would likely be less malleable.
Direct Messaging
The AT protocol doesn’t include direct messaging. Since PDSs don’t do much other than store data if there is direct messaging on an AT-based client or application it’s separate from the protocol itself. Direct messages may be implemented more officially at a later time, probably at the crawler or client layer, or in a similar fashion to Nostr.
AT’s Current State
My opinions/interpretations on the current state of the AT protocol and its potential future.
Growth
The AT protocol has experienced alright growth, all in the form of BlueSky, as many people left Twitter in search of a generic Twitter alternative (either in the form of ‘old Twitter’ or Twitter under the board right before Elon Musk). Being all Bluesky, however, it hasn’t received the same growth in the distributed microblogging space as Activity Pub or Nostr has and appears to be sought out as a generic Twitter alternative as opposed to a distributed one.
Scaling Issues
I am not aware of any portion of the AT protocol that would provide unique scaling issues beyond the generic scaling issues that I will touch on at the end of this post. However, that could change if AT were to be used in a decentralized manner instead of its currently centralized nature (for example, specific crawlers could become the center of everything, smaller PDSs could be excluded from the network, or other issues could rear their face if it were to be put in real production).
Moderation and Community
I can’t speak too much of community or moderation on AT. I have not used it so I can’t speak to its community much beyond I’ve heard it’s sort of old Twitter, and protocol wide moderation has not been seen as it’s still all on BlueSky which is effectively centralized.
Future Changes
The future change I would propose to AT is to decentralize. Again, BlueSky is the only main implementation of AT, and as BlueSky remains locked down it inhibits the use of AT as a decentralized protocol.
The Perfect Model, and Conclusions
I believe AT could excel with its compartmentalization. Accounts are owned by the user, data is stored on a PDS, and data is aggregated by a crawler. This compartmentalization would make it easier to build as its members can control little pieces of the network, and easier to build on as crawlers can focus on aggregating and processing content for specific purposes while not needing to host/duplicate the base layer.
Nevertheless, I am unsure if AT will play a part in the growing distributed social media landscape. AT is still just BlueSky, a locked down and effectively centralized platform. Its features are also not too unique to be implemented into other protocols as well. Nostr more or less can do it all already - Nostr clients are effectively “crawlers” running on a local device, and various other applications already built on Nostr (like Nostr blogging platforms) can already fulfill the function that centralized crawlers would do.
Activity Pub can also fulfill many of the same functions as AT. While Activity Pub servers are more monolithic making a “crawler” fairly impossible, there are several various Activity Pub server types (e.g. Mastodon vs Lemmy) that are mostly/partially compatible and would replace the need for crawlers. Throwing in user-owned account identification Activity Pub could also do everything AT can do.
While I believe the AT protocol itself has considerable promise, and again functions sort as a hybrid between Activity Pub and Nostr, if it remains locked down I foresee a lack of adoption and minimal/no participation in the distributed social media landscape.
Misc Ramblings
Universal Scaling Issue
Beyond the issues mentioned above, such as Activity Pub’s being fairly hefty or Nostr’s ‘hub relay’ issue, there’s the general issue in any decentralized protocol of getting volunteers to scale. Servers cost money and somebody has to host them. There will generally be certain flagship instances (such as Mastodon.Social or Primal’s Nostr relay) that are funded by the donations/revenue of major players in the development surrounding the protocol. There will also likely be “corporate” portions of the network, such as Activity Pub’s Threads or Nostr’s Minds, which can monetize themselves and offer an easy in to the platform.
There will also be people willing to pay a few dollars to host a community for their friends (online or in person), or for a community on a topic they like. The price of an (ever-growing) Netflix monthly payment would cover a small Activity Pub server or a moderately sized Nostr relay. Still though, there does come an issue with the funding of servers with a moderate or large size not affiliated with any project or group, and the development of third party clients, all of which may bring along revenue models like ads or subscriptions or die out if the donation model does not scale up.
Federated vs Decentralized
I kept saying federated, decentralized, and distributed throughout the post and figured it might be worth delving into here. Kevin Cox’s post Decentralized vs Federated is what I believe to be the best explainer you can write. Nevertheless, to summarize, federated services are any number of centralized servers that can communicate with each other. For example, with Activity Pub where [email protected] is an account with the centralized server example.com managed by said server, but can communicate accounts on any other server. Decentralized protocols exist when a particular user (and likely their posts) exist independent of a server hosting them (such as Nostr or IPFS). Usually using some form of cryptography, the content can continue to exist or easily be migrated even if the original server goes down.
Distributed doesn’t have an official definition (to my knowledge), but it’s hopefully self-evident. I’m just using it as a placeholder for any protocol that has content distributed across multiple independent servers, be it federated or decentralized.
Protocols can change
During this comparison, it’s important to clarify that protocols can change as their development continues. For example, with Activity Pub, duplicating every video across every instance was once standard. Of course that would have obliterated the network’s computing requirements at scale, so it was dropped and videos just link to the original source - crisis averted.
Things are interoperable
Another aspect worth clarifying is that in the world of open protocols it’s never a zero-sum game. You can already talk to people on Activity Pub with a Nostr account and vice versa. You can also usually follow BlueSky users on the AT protocol while on Activity Pub or Nostr, but of course interacting with them is impossible thanks to BlueSky being locked down and AT doesn’t really exist outside of BlueSky.
I sort of recently created a GitHub repo called Follow Anything Anywhere which tries to demonstrate just that, that you can follow just about anything through a variety of platforms. This of course means that open protocols aren’t really competing per se, and instead integrating into one larger distributed social media landscape,
Sum Up
So, like a lot of my posts, man did that turn out longer than I anticipated. Still though, hopefully it was interesting or useful in some way. Again, I’d like to reiterate that I’m not an expert here just combining some research with a surface-level to mid-level understanding going in to hopefully accurately portray the state the three protocols are in and how they compare and interact. Of course, as always, if I was incorrect about anything please reach out.