Microblogging Protocols Compared v2
Update: September 20th, 2024: I was incorrect regarding AT’s (BlueSky) inability to fully delete things, the protocol DOES support fully deleting posts from the user’s repo and I’ve updated the post to reflect that. Read more. Big thanks to Ryan for providing the info.
Also, on a less important update (in regards to this post’s accuracy) - in keeping tradition with the original post - Bluesky has managed to change rapidly shortly after I finished this. It’s good news again, in this case a huge influx of users, many from Brazil after Twitter/X was blocked. Additionally, I also recently saw Frontpage, an AT based link aggregator. In the post I mention a few times hoping more will be built on AT now that it’s opened up, and it appears exactly that is happening.
Click Here to skip my introduction and the misc topics.
In January of 2024 I published a blog post comparing Activity Pub, Nostr, and AT, and this is a revised version of that post. There are a few reasons why I went about making an updated version. First, I got a couple of things wrong - specifically not realizing SharedInboxes were part of the official Activity Pub standard and mistakenly calling AT relays AT crawlers. There have also been some updates, most notably on AT. When I wrote my last post AT was 100% centralized with the BlueSky relay only crawling BlueSky PDSs exclusively in addition to requiring an invitation to join.
It is now possible to join on BlueSky without an invitation, which is also crawling self-hosted PDSs. I was a little negative towards AT at the time, and I would like to update this post to reflect my new thoughts on its state. Finally, I thought I would restructure the post a bit. Bringing all the misc notes and random explainers to the top might be handy, and organizing by attribute instead of doing each protocol in clumps might make for an easier comparison.
Further, it appears that my previous post was somewhat popular, which was really cool to see and is also a good reason to get a better version out. For a short period starting sometime after posting it I went from my normal hundreds of unique daily visitors1 to thousands of unique daily visitors. After running a backlink checker while bored a month or so ago (~July 2024) I found out that my post was shared a lot; including in the ORiley Trends Newsletter, Hacker news, a handful of blogs and social media sites, and even the French2 community news site LinuxFr.
With that said, before I begin let’s start out with some funny stuff. I shared this meme on my original post, but decided to up my meme game a tad.
Also, while I was working on this post I was simultaneously toying around with Suna, an AI that can make a song out of provided lyrics, so below I present to you the “Silly Goose Protocol Song” using a few different genres Suno recommended. Feel free to download and share elsewhere, the lyrics are Creative Commons and the songs themselves are AI-generated which are uncopyrightable.
Dropdown: Lyrics
they track us, they cheat us, they lie to our face
these centralized platforms are a blight on the human race
algorithms, echo chambers, endless bots too
these big social platforms are nothing but poo
twitter banned an outlet for reporting the news
people were stuck there with nothing else to use
Husky Musky bought twitter, he’d fix it you bet
but he only banned people who mentioned his jet
where can we go and what can we do
there’s non-centralized protocols for me and you
share your memes and experience a world that is free
the future of technology is always libre
activity pub builds many communities with ease
join a community of anything from tech to keeping bees
servers and instances across the web abound
give it a try you might stick around
there’s noster with accounts controlled by a key
the very model of a sovereign identity
redundancy and interoperability by design
noster is a great way to be online
A T is a place with skies of blue
partitioning of the network giving pieces to you
home servers can run with a minimal overhead need
or register on blue sky without tech knowledge at blazing speed
where can we go and what can we do
there’s non-centralized protocols for me and you
share your memes and experience a world that is free
the future of technology is always libre
there’s always bad actors and that’s a big clunker
theres threads by zuck who hides in his bunker
theres mastodon dot art that carpet bombs federation
and spammers who spam with constant elation
but your account is yours and you control what to do
because libre software serves not companies but you
and now that you know what to do
where can we go and what can we do
there’s non-centralized protocols for me and you
share your memes and experience a world that is free
the future of technology is always libre
since libre is open there’s no need for balking
bridges connect protocols for cross platform talking
theres open APIs for us to freely use
and no google or twitter or reddit who abuse
before we go there’s special mentions by the lot
diaspora, secure scuttle butt, oh status, and zot
but the big three are here and growing by the day
over a quarter of a billion users could be here to stay
oh where can we go and what can we do
there’s non-centralized protocols for me and for you
share your memes and experience a world that is free
the future of technology is always libre
Misc Notes and Definitions
Before I begin directly comparing the different protocols I thought I would go over a few concepts that I either think are important to give context to my comparison, or are good to clarify before I get started. On my last post I tagged these on in the end, but it might be handy to have here first instead this go around.
Bridges
First off, though it’s a comparison, keep in mind that protocols aren’t exactly in competition. Thanks to the wonderful world of bridges anybody on Activity Pub, Nostr, or AT can follow anybody on any one of those protocols. On one protocol I follow all three, and you can even bridge things in and out of RSS too. For every cool new feature or new group of users one protocol gets everybody benefits.
Dropdown: Bridge Controversies
As bridges have gotten more popular there have been some controversies about them in the Activity Pub community. Generally, it’s people getting upset that their account is being mirrored on a bridge without them giving the okay. However, I think this controversy is due to a misunderstanding of how the protocol works.
A bridge out of Activity Pub requests a copy of the posts and profile data of a user using the Activity Pub protocol, creates a local copy, and then serves that data to clients on the Nostr or AT protocol. Problematic, right? The user didn’t agree to that. However, let’s say we’re sticking within Activity Pub and a user wants to follow a user on a remote server. The remote server requests a copy of the posts and profile data of the user, creates a local copy, and serves that data to clients via the Activity Pub protocol.
I can see how at first glance bridges could look weird, and it’s totally fine to ask for permission first (like the BlueSky bridge does). However, every server on Activity Pub duplicates content, with bridges working the exact same except translating it for clients on other protocols.
There’s also a slow trickle of multi-protocol clients too. I made a crude one that works with all three discussed here today, and something like Nootie offers a similar more polished experience 3 (for IOS exclusively). As more and more trickle in, and hopefully as we get some both read & write clients, we’ll probably see the communities within each protocol all melding together.
Most People Won’t Care
I believe 99% of people will never use these protocols, it’ll always just be a few nerds who use them. Hold on, put down your pitchforks, let me explain.
When Twitter/X drama was going on and people were trying to find alternatives a whole lot of people wound up confused and giving up while trying to join Mastodon, and the instructions were about as simple as going to joinmastodon.org and picking a server. Now imagine trying to convince somebody who doesn’t make a living or hobby out of technology to manage cryptographic keys (Nostr & AT-Proto). It’s far from impossible, most clients make it pretty easy and explain it well, but there’s friction and learning required to access something that the average user will simply see as a Twitter clone. Now, that doesn’t mean it’s all doom and gloom for people who like some or all of these protocols, I’m playing kinda fast and loose with definitions to make a point.
People will, however, likely use platforms that run on top of these protocols. While Mastodon is currently sitting at ~800 thousand monthly active users, Threads4, which is built on top of Activity Pub is currently sitting at ~190 million monthly active users. I do expect the protocols are going to be out there a lot, but I guess that most people will be interacting with them using a platform as a layer of abstraction to separate them from the protocol itself. Another good example is BlueSky, which is pretty much synonymous with the AT protocol (though not fully synonymous anymore since they have opened it up a fair bit as of late). You register on BlueSky with a username and password, with either some or most people completely unaware of the fact that there’s a DID (decentralized identify, aka cryptographic keys) that identifies their account. Nevertheless, I could set up my own PDS (personal data server - will touch on that in a sec) and join the network.
Same as with email, how many people host their own server or have their own domain but outsource to a hosting provider? I have had to explain on more than one occasion that, yes, the email I just gave you is name@domain and not name@[email protected] - but my email works with other people’s email all the same5.
Dropdown: the next generation is often FOSS underneath
It seems to me that many areas of software tend to drift towards derivatives of libre software as time goes on. Take operating systems for example, round one there’s Unix and Microsoft NT. Then, as time goes on, we get open source alternatives to them such as the Linux kernel and the various BSDs. Then as the next round of things come about they’re all libre under the hood. Android, ChromeOS, your TV and probably even things like your car are all powered by the Linux kernel, and devices from Apple to Playstation are based on BSDs. It’s simply much more economical to take something that’s already there instead of building something from scratch.
The same could likely go for social media. Twitter, Facebook, Myspace, etc. were all originally built from the ground up. Then as alternatives come around such as Threads, Truthsocial, and Minds they’re all based on things like ActivityPub or Nostr under the hood. And just like how on ChromeOS you can pull up a terminal and start installing Linux software, on those platforms you can (potentially after checking a few boxes to enable it) venture out into the greater decentralized social media landscape. This is beneficial, fellow nerds, techies, and cypherpunks because we can all hang out in our little corner while also being capable of interacting with others elsewhere.
Decentralized vs Federated
I’d reccomend checking out Kevin Kox’s blog post on the topic for a great explainer, but in short:
Federated services are ones where numerous centralized services can communicate with each other. For example, sending emails between servers or interacting with posts on remote servers. This would include something like Activity Pub.
Decentralized services are ones where users/content generally exist separate from the servers they’re on. You’re obviously still fetching data from servers and/or peers, but data can be migrated or mirrored to other ones without much of a hassle (and is generally identified via cryptography). These include protocols such as Nostr (or something like IPFS).
Distributed social media protocols are, as far as I know, my own little made up term to encompass both. I’m just using it as a placeholder to refer to all three regardless of being federated or decentralized.
Web3
I’ll use the term Web3 a few times here, and every time I bring it up it’s worth offering a quick clarification. In short ‘Web 1’ is often used to refer to the older internet, blogs, message boards, and other smaller independent websites. ‘Web 2’ is often used to refer to the big consolidations into various ‘Big Tech’ services (Facebook, Twitter, YouTube, Reddit, etc) that replaced them.
Web 3 just refers to the internet’s (potential) shift back towards its more decentralized roots, often using various servers/peers that communicate using new-fangled protocols. That includes all three protocols discussed today, various protocols like IPFS, various messenger protocols like Matrix, cryptocurrencies, and arguably various self-hosted websites like this blog6. If you’ve only heard of Web 3 in regards to NFTs that’s because their only gimmick was that they were trading cards but delivered via Web 3 technology (an image’s cryptographic hash on a distributed database, often delivered on IPFS).
An example of this would be how people post content online. In Web 1.0 it would be a self-hosted blog with RSS, and on Web 2.0 it would be on Facebook. A Web 3 version would be something you post on one of these protocols here today. This is often (but not always) accompanied by something like federation or P2P communication, using something like cryptography to identify people or files, and/or separating identity from the servers that host content.
Dropdown: Replacing Older Technologies
Speaking of Web 3, I do both expect and hope that these protocols start to become part of the web outside of microblogging as well. Take a website like this for example, you point a domain at a server and host a single site - which then can be accessed in a web browser and subscribed to with RSS.
With these protocols you could potentially just create an account on the protocol with an existing server(s). The server could host hundreds of people becoming a lot more efficient than a single server for each of them. Identify the user with a public/private keypair (free, but requires some technical know how) and/or a domain (paid, but cheaper than a hosting plan - could also use a subdomain from the server, but that would hand control of the site to the server’s admins).
Well actually this site is hosted on GitHub pages which does benefit from doing things at scale, but I assume you get my point.
You could still access the account in the browser like any other website, in a client, and could subscribe to it with the protocol the server is using (or just about any other protocol with a bridge). With something like this, it could make having your own little corner of the web cheaper, easier, and more efficient. There are already things coming to be like WriteFreely or Nostr’s NIP-23 for creating a blog on those protocols. As much as it might be blasphemous to the older blogging crowd, I think it would be a good thing to begin replacing static sites, CMSs, and things like RSS with some newer protocols.
The protocols
Here’s where I thought I would give an overview of the three protocols, as well as some things I like or think are potential drawbacks that are specific to a particular protocol and hard to add to a comparison section later.
Activity Pub
Activity Pub is the oldest decentralized microblogging protocol still widely used today, with its 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.
Oddball Cool Stuff
Activty Pub is THE protocol for communities. While it varies from implementation to implementation, you’re usually going to have something along the lines of a home timeline (stuff you follow), a local timeline (everything on your specific instance), and a federated timeline (everything on the known network). You can find a server based on just about anything and with a variety of rulesets and federation policies. This is great for anybody who wants to join or build a community related to anything from having a spot for your friends to hang out to finding a community of new potential internet friends who all share a particular hobby or interest.
Activity Pub, again being the oldest still widely used distributed social media protocol, is implemented into a larger number of projects and communities. It’s had a lot of work put into it and time to mature, and if an outside product is looking to implement a protocol of some sort Activity Pub will probably be the one they default to unless another protocol better fits their specific needs. Last, Activity Pub is probably what you would think of first when you would imagine a distributed social media protocol.
Oddball Potential Issues
The one issue I couldn’t place elsewhere, however, is that while community is Activity Pub’s greatest strength it also comes with some potential drawbacks. This largely comes into play with defederation. It is important to note that having the option to defederate with instances is an important tool. The first people to leave (often by being kicked off) a dominant platform are often the crazies, and with Activity Pub being the first that’s where most of them went, so there is a wide swath of reasons why an admin may wish to defederate with another instance. Further, it is 100% the right of a server admin to select what instances they wish to federate with.
The problem, however, is that often times there’s this tangled web of who is defederated with who. I’ll put two dropdowns below. The first one is ripped straight from my original post, and it’s going over the events where the instance infosec.exchange got defederated from over what I would consider a very invalid reason to do so. The second is a somewhat hyperbolic & fictional example of how somebody could go through a very unlucky combination of servers with federation issues. I originally considered putting the second one in my original post, but skipped and re-drafted for this post (although all of them are based on various real policies that exist on various servers). Both of them are long and wordy, you have been warned.
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 been 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”). As the landscape of what people would think of as the mainstream “fediverse” has shrunken, the people demanding stronger defederation have also gotten a 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 instance.
A worst case scenario example
I thought I would do a little illustration of how I think over-defederation could be making the fediverse a shattered place. Let’s say Bob is convinced by Alice to join the fediverse. Alice told Bob to just join mastodon.online, but the flagship instance has temporarily disabled signups after being overloaded, so Bob winds up on joinmastodon.org. Bob’s an artist so he joins Mastodon.art. Bob can’t seem to find Alice’s account, so he makes a note to ask her about it next time he sees her, but goes on to set up an account and follows people he finds interesting. However, unfortunately for Bob, his account is banned. You see when NFTs were all the rage Bob tried selling $10 NFT certificates of his art and still has them on his website. His profile picture was one of those images he was selling, and while he never mentioned NFTs or anything - only linking to his website in his profile which has them listed in the ‘purchase my works’ section. However, since the profile image could technically be purchased as an NFT it violated the server’s terms of service and he was banned.
Speaking to Alice in confusion, Alice would later explain that Mastodon.art is defederated from almost everybody and has extremely strict (and often nonsensical) rules. Alice recommends Bob go find another server that’s more run-of-the-mill and Bob goes to start from scratch again. Bob goes to join a generic instance, but is confused again as to why he can’t find Alice’s account. The next time Bob sees Alice she looks at the instance and realizes why they’re defederated: a few years ago CISA registered a placeholder account on Infosec.exchange, and that triggered a large number of instances to defederate from Infosec.exchange. Alice was on Infosec.exchange, and the run-of-the-mill instance Bob joined blocked it, so Alice went on to help Bob choose a new instance that did not block Infosec.exchange. Bob does lose his post history and profile setup while migrating, but at least keeps his followers and following list this time.
Ran out of names here since most examples use ‘Bob’ & ‘Alice’ so I’m gonna go with ‘John Doe’ next.
Soon after, however, Bob and Alice find out that a mutual friend John is on a fediverse adjacent platform. It could be Threads that supports Activity Pub, or it could be on another platform like Nostr or Bluesky that’s bridged into the fediverse. Regardless, however, Bob cannot follow John because even though he was specifically guided to an instance that didn’t block Infosec.exchange, the instance he was on blocked Threads and/or bridges. At this point Bob is fed up. “Fine,” he thinks, “I’ll just find a less moderated instance.” Bob picks an instance that is either only lightly moderated, or one that is unmoderated except for illegal content. In either case, as soon as he goes to migrate everything breaks. He loses most of his followers and his following list, since most instances block lightly and minimally moderated instances.
At this point Bob is really annoyed, so he goes back to Alice to find an instance. Alice helps him find one that’s federated with all the instances that he wants to communicate with, and for hopefully the last time Bob goes back to set up his account and re-follow those he was interested in. A couple of weeks later something changes that instance. Perhaps a controversial figure joins that same instance and most other instances defederate with it, the admin reacts to a new controversy (say, blocking bridges or a larger more corporate instance that Bob wants to communicate with), or the admin just has a change of mind and changes federation and/or moderation policies. Bob does his best to get out early, but again loses his post history and some of his followers.
Bob is now getting fed up. He goes back to Alice one last time, and Alice finds another instance that both meets federation needs AND appears to be stable. Two weeks later the server he chose had a corrupted database, or the domain was seized by the Taliban, or maybe the instance admin got bored. Regardless, Bob’s account was entirely wiped off the face of the earth with no opportunity to migrate. At this point Bob gives up.
In summary, yeah, it can sometimes be a complicated web of things. You’ll rarely be able to federate with the whole network (or even the whole network only including well-intentioned instances). If you go on a more strict server you will eventually run into a point where you can’t follow somebody you want to. If you go on a more broadly federated server you’ll probably find places where you also can’t follow somebody else because their instance defederated with yours, even if the only reason the other instance defederated with yours was because your instance had a looser federation policy. Throw in some toss-up issues like Meta or various bridges that have been controversial, and you may have to spend a lot of time finding an instance that is federated with exactly what you want and don’t want.
Nostr
Nostr’s development started the latest of the three, starting in 2019, and being in a fairly usable state by 2020. Unlike the server based accounts on Activity Pub, Nostr goes about identifying users with key pairs - which are used to sign posts before being uploaded to the relay(s) of the user’s choosing. Other users’ clients can then request a copy of those posts from that relay which are processed and organized by the client. Outside of potential moderation or rules on who can post to them, standard relays are nothing more than a simple collection of plain text posts. Anything outside of plain text (images, videos, etc) is embedded in posts by linking to a separate remote host for the client to retrieve from and display for the user.
Nostr is by far the simplest of the three protocols, often being described as the spiritual successor to RSS by me and others. At its core it’s just a means of delivering signed plain text messages of any length to clients which use the poster’s public key to verify that they posted it. It would, however, be a bit too bare bones to only see <hash> posted <text>, so it adds additional functionality in using NIPs (short for Nostr Implementation Possibility). Some NIPs are pretty universal across the ecosystem, such as NIP-05 which allows you to identify yourself with a domain (say [email protected]). There are also NIPs like NIP-23, which provides markdown-supported macroblogging separate from the standard plain text microblogging, and there are also more specialized NIPs such as NIP-15 which attempts to build an online marketplace on top of Nostr.
Oddball Cool Stuff
The one thing I would like to bring up here is Nostr’s redundancy. On Nostr you can upload your posts to any combination of relays that you want to, giving profiles a fair amount of redundancy. On the other two big ones, if your instance or PDS goes down respectively your profile is offline (and potentially gone forever), but on Nostr if your favorite relay goes down you likely won’t even notice.
Oddball Potential Issues
The first issue I see potentially plaguing the Nostr protocol is the issue of managing relays. At first, it sounds pretty simple: follow ten people and add three relays of which those ten people each use at least one of. The client then queries those relays for all the posts that have from those 10 people. But, say you scale up to following like 50 people. Then suddenly you’re querying a dozen or so relays. Then you follow a few people who are not on the big relays so you add a few self-hosted relays. Then you want to join a few relays for specific communities. Next thing you know, you just queried 16 to 20 relays asking each relay for all the posts of everybody you follow. Maybe you use a lot of social media so you’re following 100 or 200, now you just queried 25 relays asking each relay for all the posts they have from 200 accounts. You get the idea.
As it stands, there’s a handful of big relays and most people will be on at least a couple of them. This enables most of the network to communicate with each other. As long as you have a couple of those relays in your client you can follow just about everyone, then you can start branching out and using specific relays that you want to add for specific communities or other interests. But, depending on how your client is set up, as the network scales you could be forced to choose between adding a couple of large relays and winding up in a more centralized network, or avoid that adding a very large number of smaller relays and needing extra processing power for your client to keep up (comparatively at least, we’re still talking plain text).
Beyond relays, there’s also the issue that if you lose your keys you lose your account. It’s no different than software development, GPG, or SSL certificates - but as you may notice those three are more technical while a universal social media protocol is generally intended to be more friendly.
AT (Authenticated Transfer, Bluesky’s Protocol)
When I posted my previous comparison I spoke about AT more briefly and had a more negative outlook on it. At the time AT was pretty much exclusively on BlueSky (I am unaware of any usage outside of the BlueSky relay accessing BlueSky PDSs before its opening up). This, however, has since changed and is one of the driving factors in making an updated post.
Unlike Nostr or Activity Pub, AT has three different layers interacting:
The first layer is the user’s identity, a DID (set of public/private keypairs). Each user owns their key pairs, which they can use to sign messages and perform various other social media actions. All of their posts and other user content are added to a user’s repository, which resembles a git repo that contains all the user’s public content and profile information. You can also identify a DID using a domain, changing the human unreadable key hash to something more easily read.
The next is a PDS, where a user stores their repository on. A PDS acts very similar to a Nostr relay, storing user posts and processing requests from other devices, however, not performing any sort of federation.
Last is the Relay, which I had previously mistakenly referred to as a ‘Crawler.’ AT Relays operates very similarly to an Activity Pub server, collecting data from remote PDSs and providing them to the user who’s using the social media network. BlueSky itself is one of those relays, collecting data from PDSs (both hosted by the BlueSky foundation and private individuals) and then providing that data in the BlueSky site or app.
If you’re familiar with Nostr, an AT relay performs data collection and parsing from PDSs in a similar way a user’s Nostr client collects data from Nostr relays and parses it for the user. Similarly, if you’re familiar with RSS the AT model is like Feedly collecting content from RSS feeds and providing it to you in a web browser, where something like Nostr would be your local RSS reader querying the feeds directly.
Oddball Cool Stuff
I like how AT is set up, breaking things into multiple different parts makes it super easy to control your little portion of the network without needing to maintain the parts you don’t want to. Want to own your own identity? You own your keys and can optionally link them to a domain, so you’re all good to go without needing to host anything. Want to host your own server? Fire up a PDS which is lighter to host since it’s not doing any federating, and start posting your content to that. The real heavy stuff, i.e. hosting an AT relay, is the only thing that needs to do a whole bunch of stuff and needs a lot of overhead.
Additionally, the BlueSky relay7 is being built around being customizable. If you want to have specific moderation options or specific recommendation algorithms it’s up to the user to select their preferred one, making it almost as configurable as something like Nostr.
Finally, the BlueSky relay also functions as a layer of abstraction to make it easier for non-techies to use the platform. You can register with a phone number or email and become a part of the BlueSky network without needing to deal with asymmetric encryption or choosing/hosting a PDS.
Oddball Potential Issues
The greatest oddball issue I see with AT is that it’s currently in development. Things like account migration and direct messaging are not implemented at the time of writing. If your PDS goes down, or you set one up but no longer wish to host one, R.I.P. to your account. Similarly, if you started on BlueSky but want to grab your keys and go elsewhere you’re also stuck.
The second potential issue I see with AT is centralization. It’s compartmentalization is great for individuals to host their own PDS, but it also means that most people rely on the BlueSky relay to crawl their PDSs and deliver that content to others. At the time of drafting, I am unaware of any relays aside from BlueSky.
Last, like Nostr, if you lose your AT keys you lose your account. Similarly, if you outsource your key management to a platform and they lose your keys you’ll also lose your account.
Comparisons
Alright finally, now that all the rambling is done let’s compare the various protocols’ pros and cons on a handful of topics. I plan to take a look at each protocol’s: ease of use, ability to own your identifier, communities (local and protocol-wide), compatibility & malleability, server resource requirements, client-side customizability, migrations, and scalability.
Ease of Use
The ease of use in joining a network is an important factor to consider. Kinda hard to build out a network if people have a hard time joining it. Now, as I stated above, when/if the protocols blow up they’re probably going to largely be on third-party platforms that hide away the protocol layer stuff from the users - but ease of use is still important.
Activity Pub
In my original comparison I gave Activity Pub a rating of “moderate difficulty to join and a moderate difficulty to master.”
Joining does require a little research, especially when the flagship Mastodon.social pauses registrations - which did cause some people some trouble during some of the big migration waves. Still, it’s not too foreign of a concept to understand that it’s a bunch of independent servers that can communicate. Further concepts like defederation come pretty naturally, so after joining the process of understanding how everything works isn’t all that big of a leap. I would definitely consider Activity Pub to have the greatest ease of use overall.
Nostr
In my original comparison I gave Nostr a rating of “easy to join but difficult to master.”
Joining Nostr is likely the simplest of any protocol. Download a client, read a paragraph of how-to that can be summarized to “Your NPUB is your username, and your NSEC is your password. Don’t lose your NSEC!” and start posting to/reading from the client’s default relays.
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. Add the fact that getting a key lost or compromised destroys your account unless it was outsourced to a platform and it gets only more complicated.
Sure, there is a big community of users from Thailand because Nostr went viral on TikTok there, so if TikTokers can figure it out it’s obviously not that hard for people interested in learning it - but still definitely a step down in ease in use from Activity Pub.
AT
I never gave AT a rating in my original post since it wasn’t opened up yet, but AT would probably be something along the lines of “hard to join and hard to master.” To join the AT network you have to choose or host a PDS, meaning that you still need to know what asymmetric encryption is like on Nostr, but you likely have to know the basics of how the protocol works PRIOR to joining like Activity Pub. AT probably has the least ease of use of these three.
At the same time, however, BlueSky is a good example of how platforms come in as an abstraction layer. You can sign up to BlueSky like any other random social media platform (email+password) and be on it without even knowing what AT is.
User Owned Identifiers
One of the draws many people bring up is that with distributed social media you get some degree of control over your online identity. The (in my opinion) ideal way to achieve this is to separate the ownership of a user’s identity from the server itself. In this way, the server gets 100% control of what happens on the server while having no ownership of the users’ identity. In this case, if a server goes down, get’s hijacked, let’s its domain expire, bans a user, or their domain gets seized by the Taliban the users can still carry on - just not on that server. It also makes migration easy.
Dropdown: Further Elaboration + Personal Anidote
In an example not related to these protocols, think owning your domain for a website and/or email. This saved me a huge headache once when forever ago I was hosting my email with Tutanota and they went down for several days (this was probably the better part of a decade ago and as far as I’m aware is mostly a one-off, I don’t intend to throw any shade their way). Had I been using their domain I would have just lost any emails sent to me during the outage and been unable to access any existing emails that I hadn’t archived away from the service. In my case though, all I had to do was point the DNS at new servers and I was back up and running.
To make some clarifications though, first, this does not have to be mandatory. For example, nothing is stopping me from using a GitHub pages subdomain or an @tuta.io email address, but the option to identify myself separately with my domain can and has saved me a lot of trouble without inconveniencing people who do not use their own domain. Further, separating out identities does not affect moderation. Just like having my domain can’t force a company to host my content, having a user-owned identity does not prevent servers from moderating content, requiring users to register, or banning users from a particular service.
In the original version of this post I hadn’t experienced being banned or having a server go down, however, this time I have an experience with that. In May Nerdica.net went down thanks to a corrupted SQL database. The site was eventually brought back and handles were restored, but all posts, profile info, and follows (both people you followed and people who followed you) were wiped out. Given the server was over a decade old that was a lot of accounts and posts gone, and it was certainly disappointing to have my own account gone.
Activity Pub
In my original post for Activity Pub I said there was no way to separate your own identifier from an instance, and the only way to ‘own’ your own identity would have been to host your own instance under your own domain. There was, however, one project that I was unaware of and one further development that occurred about two months after I posted my original version of this comparison.
In March news broke that Hubzilla/Zot’s Nomadic Identities may be coming to Activity Pub at some point - something I had mentioned two months prior in my original post that could be a potential way to solve some perceived issues8. In regards to having an identity separate from the status of one’s instance, there are two relevant bits that may or may not be implemented if we do get Nomadic Identities in Activity Pub.
The first thing is using cryptographic keys underneath a channel. A channel is just Zot’s identity, say [email protected]. You could still find users with a domain-based username, but the underlying cryptographic keys make an account more easily exported and imported across different servers while verifying that you’re still you.
The second part of Nomadic identities is the ability to mirror your identity across multiple servers. This means that if you’re [email protected] you can create an account [email protected] and set the second account to mirror content from your first account. Then if example.com goes down your followers can default to following you at server.com and see your existing & new posts, using server.com as your new main profile until/if example.com comes back.
Outside of Nomadic Identities, I was also made aware of Tahake, an Activity Pub server in beta that supports multiple domains. This existed for the past two years, so it’s not a development in between my last post and now, but I was unaware of it at the time hence it being the second updated part of this section. Being able to support multiple domains it can let individual users use their own domain and through that control their own identity without needing to host their own server to use with their own domain.
However, as far as the protocol as it currently stands, the user doesn’t have ownership of their account. Nomadic Identities are a potential future inclusion in the protocol, and Tahake is a server with a unique modification but not part of the run-of-the-mill Activity Pub implementation. Of course, however, for the people who really want to seek it out, they can host their own server or join an existing Tahake server.
Nostr
Nostr accounts are identified by a public key, optionally using a domain-based username on top of it for a more human-readable way to find people. Nostr accounts are entirely controlled by the user.
AT
AT is theoretically the same as Nostr in this regard, the user holds their encryption keys and thus controls their account. There are two buts here, however. First, anybody registered on BlueSky doesn’t actually own their private keys. Further, even if you’re on a third-party PDS, since migration hasn’t actually been developed your account is still kinda tied to a PDS.
Communities
Communities, both individual ones and and the protocol’s community as a whole are the end goal of making protocol to communicate with. I do expect all three to get ‘Eternal Septembered’ as they grow, but it’s worth rambling on about their current state regardless.
Activity Pub
Activity Pub is THE protocol for individual communities. It’s built around individual servers that generally house a unique community with its specific theme and policies.
As for the Activity Pub wide community, based on my observations it’s the largest and has the most varied of all the protocols. Still, it’s got a techy slant as any new protocol would, and if I were to guess the median user it would probably be a 40-something tech blogger who dislikes big tech and wants a return to Web 1.0. It does, however, by nature of being the oldest protocol (still widely in use anyway) house most of the less desirable communities that broke away from the mainstream social media networks.
Nostr
Nostr generally doesn’t have local communities by default, having your client and keypair more or less equivalent to a local instance of one. Because of its customization there are ways to effectively create a local community, such as creating a feed of all posts on one or a set of relays to get a local community going. Some clients also support adding custom ‘Algorithms’ to give you a feed with a specific flavor, and there are projects like Ditto which fairly successfully emulate an Activity Pub style instance from within Nostr. Again, though, this is not the default.
The protocol-wide community is fairly techy with a decent portion of the community being cryptocurrency enthusiasts and cypherpunks9. Originally that was the community in its entirety, although as it’s grown a lot there is a pretty wide variety of people on there now - albeit still with a very techy culture (more so than the other two, which is saying something since they also are fairly techy).
AT
If other people start setting up relays there may be individual communities built on AT, but at the moment I do not believe there’s much in the way of individual communities on AT since everything is centralized around BlueSky. On BlueSky you can subscribe to custom ‘Algorithms’ and moderation feeds that could build something of a community, but to my knowledge, that’s the extent of things where it stands now.
As for the protocol-wide community, it’s important to note that I’ve spent the least amount of time on AT/BlueSky so I’m certainly not qualified to make any be-all end-all statements10. But based on my observations and what I’ve heard I’d say it most resembles older Twitter. Lots of celebrities and non-techy people joined there since it was simple to join instead of needing to learn a new protocol like Activity Pub/Nostr. I’ve also heard there’s a lot of furries.
Maliability & Compatibility
‘Mealiability’ is probably a poor descriptor, which I pointed out in my last post, but I still am kinda at a loss for words for a better descriptor. Anyway, the malleability portion of this post is where I talk about how well a particular protocol does being put to use in ways outside of its ‘standard’ implementation. Further, if done so, how compatible are different implementations that are on the same protocol?
Activity Pub
Like most things open, Activity Pub can be used in a variety of malleable ways. There’s your standard Mastodon server with fairly plain text posts under 500 characters, but there are also different pieces of software that take a different approach. Some servers like Friendica operate more like Facebook instead of Twitter, offering much larger posts with basic formatting. There are full on blogging platforms like Write Freely, link aggregators like Lemmy, and even video sharing services like Peertube.
Compatibility across those different services, however, is a little hit-and-miss sometimes. With Activity Pub servers being fairly monolithic, if a server doesn’t understand something then sometimes things either get a little wonky or need workarounds. Sometimes this comes at the cost of rich text being displayed weirdly or something like Peertube only providing a link to the video and not serving the video itself within the Activity Pub client.
When/if Nomadic Identities are implemented, however, compatibility issues are likely to decrease a lot. Nomadic Identities allow sort of an SSO, so even if you’re on a Mastodon server that has no idea what a Lemmy upvote is, authenticating yourself on a random Lemmy instance would let you upvote a post using your Mastodon profile from within the Lemmy instance’s interface. Of course, however, this is theoretical and not the current state of things.
Dropdown: Lemmy Example
A good example of cross compatibility with different servers is interacting with Lemmy on the normal microblogging Activity Pub instances. You can post to communities, reply to posts & replies, and even subscribe to communities. Your standard Mastodon instance is not going to know how to handle any of that, however, so we have to jump through a couple of minor hoops.
To post to a Lemmy instance you type up your post like a normal post, but the first line of your post will be the title of the post. Next, create a second line and @ the community (if it’s say the fediverse community on lemmy.ml then use @[email protected]). Afterwards, just type up your post and you’re all set. The Lemmy server will get pinged with the @, and though the microblogging instance has no idea what it’s doing the Lemmy server knows that it’s supposed to place that as a post to its community and will do so. There are a couple of minor drawbacks like the title and @ appearing in the post’s text, as well as no ability to do link or image submissions (to my knowledge), but otherwise works fine.
Replying to posts is fairly seamless. You can do your browsing on any standard Lemmy instance, then when you’re looking to reply right click on the fediverse option and copy the link. Paste it in the search bar of your instance and it should find the Lemmy post/reply, which you can then like or reply to. Replies and notifications of them seem to work well, although a handful of replies on the Lemmy side didn’t show up for me on Friendica.
Subscribing to Lemmy communitites is probably the most janky, but doable. If you search out the community (say @[email protected]) it should come up as a user. Subscribing to that “user” will get you posts from the users that posted to the community in repost form. Say [email protected] shared an article in [email protected], you will see @[email protected] reposted the post that [email protected] made in the community. You can then browse the post and see replies and such, though it might be a little disorganized as there’ll be a lack of Reddit-style nested replies.
Long story short, again, things generally work together. Just sometimes they’re slightly hacky since they need to work around a lot of different implementations where each server may not fully be able to process what the other server is putting out.
Nostr
Nostr is built around a simple base, but adds optional additional functionality through NIPs, which makes for a very malleable protocol. There’s the standard microblogging (plain text posts of any size + optional embedded remote media), but a lot can also be built on top of it separately. It can be used for rich text standard blogging, link aggregation communities, messengers, and even as the backend of chess apps.
Compatibility on Nostr is a little bit different than compatibility on Activity Pub. Because clients on Nostr handle all the complex stuff there’s no such thing as having an account that cannot do something on Nostr because a server isn’t compatible. You can also use any client with any account, and any number of clients simultaneously, so there are no cases where an account is unable to use a particular service on the protocol.
However, clients do need to be compatible with a particular function. For example, while any client is going to be capable of processing any regular social media style post from any other client, only a handful of clients are compatible with the new makeshift OpenBazar. And of course, if you’re looking to play chess on a Nostr account then you have to use that specific chess app since I’m unaware of any other client that would support that.
AT
Because, to my knowledge, the only AT relay that is in use is BlueSky, the malleability of the protocol is a little bit more theoretical. Nevertheless, AT does appear to be a very mealable protocol. While the BlueSky relay itself is specifically focused on microblogging, because PDSs and relays are separate things it should be possible to spin up a relay focused on something new and pull that content from the PDSs to be parsed in different ways. Relays that crawl PDSs and then place content from them in link aggregator format or as a video platform should be easily doable.
I am not fully sure how well compatibility would be among different theoretical platforms on AT, however. On Nostr, things are basically just signed text documents, so if I were to create a link aggregator post under NIP-72 it’s just a random nevent. Clients that don’t use it could easily ignore that, and if a relay didn’t want to carry that they could just reject events under that NIP. AT, on the other hand, has a more git repo style approach and just ignoring or separating things out might be a tad more difficult. If BlueSky saw a bunch of entries in a user’s account intended for a link aggregator I’m not sure how it would respond (or vice versa). The easiest thing would just be to ignore those parts, but it could always end up having some odd results (such as displaying deleted content, being displayed oddly, or spitting out errors). However, it’s important to note that again this post is just a comparison of things that exist from the perspective of an end user, and comparing technical theoreticals is much more iffy.
Server Load
This section is a lot shorter to summarize. Activity Pub servers store and distribute user data, fetch remote posts for the user’s timeline & federated timeline, and handle the processing of the data - which is delivered to clients via the web and/or an API. Nostr relays and AT PDSs require less overhead to run since relays & PDSs only store content and don’t interact with other servers.
Nostr offloads most of the processing to the client, while AT offloads most of the processing to AT relays. I have no clue how much a standard AT relay would require in terms of server overhead, but I can imagine the BlueSky relay requires a heck of a lot.
Client Side Configuration
The third part of the triangle that is user-controlled identities, ease of use, and last user/client configuration capabilities. Just like the features, security, and ease of use triangle you might have seen: you can have one or two but probably not three.
Activity Pub
If you have an account on Activity Pub you can generally do basic social media kinds of configurations in the web interface or your client. This includes things such as hiding users/instances/specific words or phrases from your timeline, showing or hiding media, and changing themes11. Beyond that, however, because Activity Pub servers handle just about everything there’s very little advanced configuration that you can do at the account level.
Nostr
Nostr is very highly configurable, allowing the client to set exactly what it displays and how it displays it. You can also choose exactly what relays (and users on those relays) your client communicates with, including more advanced configuration of how a relay is communicated with (such as toggling: uploading content, downloading posts from followers, downloading posts to the firehose all posts feed, accepting DMs sent from that relay, and whether to query the server when searching). You can also have certain clients that offer different more advanced features such as privately following people (without adding them to your public following list) or creating custom lists of specific users.
AT
AT in its current form (BlueSky) offers a very similar level of customization to Activity Pub. The relay collects and processes all data from PDSs and provides it to your client over the web or an API. The BlueSky relay does offer a few extra features, such as setting up custom moderation settings or a custom recommendation algorithm, but more advanced features are still limited because the relay is doing all the work behind the scenes.
However, while this is all theoretical, I will bet that if AT continues to grow we’ll see a Nostr-style client that works with AT. In that case, the client would connect to your personal PDS to upload content you post, but the client itself would fetch and parse content from other PDSs, giving you potentially a Nostr level of client control but still allowing you to communicate with relays such as BlueSky (since the BlueSky relay could still access your PDS). Again, though, this is just me guessing at theoretical software that does not exist and that I do not possess the skills to develop.
Migrations
How well can you jump from one server or service to the next?
Activity Pub
Activity Pub does have migrations, although they are (in my opinion), not quite as ideal as they could be. When you migrate to another server your old account still exists, but redirects new and existing followers to your new username. This does, however, require that your old server and new server are federated, and that your follower’s instances are federated with both your old and new server12. It also requires that your old server be online and your account be in good standing.
Also, posts often cannot be imported. Some platforms like Firefish do support importing past posts, and Mastodon can export past posts, but Mastodon and many other servers cannot import your old posts. It’s also generally not possible to change the domain of a server13.
Nostr
There’s no such thing as migration in Nostr since accounts aren’t tied to a specific relay or set of relays. If you want to remove your content from a relay you simply delete it from your relay list and optionally send a deletion request to the relay for your posts. Adding a new relay is as simple as pasting the relay URL to your relay list (plus registering if the relay requires registration and/or payment).
AT
PDS migrations on AT are still in development and are not currently possible.
Scaling
Every sort of decentralized protocol, and even just about anything in the FOSS space, will have potential issues with funding during scaling. As far as the various distributed microblogging platforms go there will probably always be the flagship instances and smaller community/hobbyist instances, but questions around funding those individual14 mid-sized servers (and having that list be stable as opposed to a bunch of servers often going offline) will be there for all three. Still, what sort of potential scaling issues do I see coming about specific to each protocol?
Activity Pub
The largest issue I could see affecting issues with the growth of Activity Pub would be a growing resource requirement to run a server. Activity Pub is already considerably heftier than a Nostr Relay or AT PDS given its more monolithic servers plus Activity Pub also duplicates a lot of content. All posts, profiles, and more importantly images from followed users on remote servers are duplicated on one’s home server. This could wind up stressing out a more lightweight server and increasing costs for anybody who’s hosting one.
The next potential issue, which I discussed above is defederation. Servers like Mastodon.Art are probably federated with something like one-tenth of one percent of the network15. Even in less extreme examples, if the network grows but many servers can’t communicate with large swaths of the network it may cause issues and confusion for its users.
Nostr
The main issue I see potentially plaguing Nostr at scale is heavily related to the relay management issue I talked about in its ‘oddball potential issues’ section. One way people may attempt to resolve managing a large number of relays is to make sure that they’re uploading to the big relays and querying each big relay for every account they follow. This means that everybody can see everybody’s posts, but that also means that there are probably ~6-12 big relays per language that are doing all the work; potentially leading towards centralization and increasing costs for those big relays.
AT
The one issue I see potentially causing issues in AT’s growth is centralization. BlueSky is pretty much all of AT right now, and even if people are now setting up custom PDSs the data on those are still accessed through BlueSky. If the BlueSky organization goes under or were to do something that was to cause problems for the community the protocol could pretty much vanish overnight.
Potential Improvements
Again, to be clear, this is just me rambling on. While what is and is not an issue with a protocol will differ depending on who you ask, hopefully, I’ve laid out what I see being potential issues clearly enough that you at least understand where I’m coming from. That said, this is just me speculating on what a potential solution could be, but with me lacking the expertise to implement anything I have a lot of potential blind spots in my speculation.
Activity Pub
Patchwork Federation
The first potential solution to this would be to add another limited federation option. On Mastodon, outside of either being federated or defederated, there’s an option to have a server with “Limited” federation. Under Limited people will be invisible from the home timeline, their replies will not show up, and if someone you follow reposts a post from somebody on a ‘Limited Federation’ instance you will not see it. If you search out somebody on a limited federation instance, however, you can follow them after clicking past a warning. Say we added another level of federation called “Muted,” where posts would just be kept out of the federated/public timeline and potentially search. In that case, you could still find and follow profiles without a scary warning, see when somebody on a muted server replies to your post, and see if somebody you follow reposts content from people on muted servers. Something like this could be a good way to allow admins to clean up the timeline while minimizing the friction of interacting with profiles on said server.
Further, there could always be something implemented that lets users override the default limited/defederation of instances that the admin(s) choose to enable the feature for. Obviously some things admins wouldn’t want users overriding their judgement call on, but for some things (say Threads), an admin might want to set a default but be okay with individual users choosing to override something like that.
The last option might just be to give it some time and see if things sort themselves out. At the end of the day, as much as very techy people have very specific opinions, if the ecosystem grows the average everyday Joe probably won’t care as much about all of that. Even if a handful of power users hate bridges and Meta while wanting stricter controls over what federation policies are, at the end of the day the average Joe probably won’t care as much. He might have one friend on an instance with x policies, another friend is on y instance with different policies, a couple on Nostr and BlueSky bridged in, and another on Threads. They’ll probably just want to follow their friends, and as much as it might be lamented as another ‘Eternal September’ by some, if Activity Pub does kick off the ecosystem will probably change around that.
Dropdown: My Workaround
Small servers seem to be a good way to get around some of the federation patchwork. Most of the time a smaller instance that has reasonable rules can stay out of the blocklists of places like Mastodon.Art on account they can’t go through every instance’s blocklist and block it if it doesn’t also have a mile long blocklist. You can find plenty of smaller servers that have fairly standard rules, and that filter out the worst remote servers, but keep the blocklist surgical instead of metaphorically carpet bombing the protocol’s federation.
Nerdica.net is a pretty good example of that in action and the place I wound up. It seems like a great community, but doesn’t block the various bridges and I’ve never found myself trying to find a user only to find out that their server is defederated with mine.
Server Overhead
Activity Pub servers are definitely a bit heavier than some of the other options here, but I would bet it would be possible to make a much lighter server as well. There are some more lightweight options when compared to Mastodon such as Pleroma or GoToSocial, but I would bet it would be possible to go even lighter. Imagine your run-of-the-mill Mastodon server being like webmail. Sleek, easy to access in a browser or a dedicated mail client, but has a fair bit of overhead. Then there’s GoToSocial like IMAP. No web interface to chew up resources, just a server you connect to with a client, but everything is still processed in the server.
But imagine a POP3 equivalent of Activity Pub. Take a server and strip it down to be pretty much a relay (not a Nostr/AT relay, just in the more generic term for a server that grabs data to pass along to another device and not much else). It can host a copy of your profile/posts for anything that requests it; and if another server wants to send something to your account it holds onto the message until your client comes online, passes it along, and then deletes it. It could also probably outsource as much to your client as possible, such as collecting posts from remote profiles (though if a remote server had Authorized Fetch then it would still need to request it on behalf of your client). It could also avoid having anything like a federated timeline to avoid needing to process a firehose of data, and could avoid downloading any images and instead direct your client to fetch the image from the remote server that posted it.
Obviously something like that would need a custom client since the clients now are built for a server that handles everything. Also, to be clear, even if I had a magic wand I would NOT see something like that become default. It would lose some features that people enjoy and add potential hassle to its users. Still, having something like that as an option could be very handy. Something you could stick on an existing VPS or Raspberry Pi for you and your friends, or something that could scale up at a hugely cheaper rate could be the difference between a whole bunch of new instances existing or not.
User Identities
There are two ideas that I think might be possible ways to allow a user to control their own identity on Activity Pub without breaking things or forcing features on people who don’t want to use them - if you discount the potential Nomadic Identities introduction. The first would be for more fediverse software to adopt the Tahake model where users can optionally use their own domain for their username. Just like my email and blog here, I don’t control the servers so my domain can’t force their hosts (Github and Proton Mail respectively) to serve my stuff and it can’t prevent them from going down. Nevertheless, at any point I can swap out DNS records and point my email or website to new servers. In this way the user could ‘own’ their username without needing to host a personal server.
Secondly, there could be the potential of adding some sort of cryptographic key to an account. This could be a Nostr/AT style identifier, a GPG key, or just a private key disguised as a recovery code. When a remote server has a user subscribe to the account the remote server could make note of the key, then at any point the user could move servers and sign a message on a different server using that key. That new server could then contact all the followers who followed the original server and tell them that the account moved, allowing somebody to migrate without being able to access the server that they were trying to migrate away from.
Both of these could be implemented in a completely optional way. Like various email providers, connecting your domain is an optional thing that you need to seek out intentionally. Similarly, generating/linking a key could be an optional thing hidden away in the advanced settings of an account. In this way, neither would disrupt anybody who didn’t want to seek those features out, but give a very useful tool for power users and those who highly value their accounts or like the idea of ‘owning’ their online handle.
Nostr
Relay Management
There are two easy fixes that I could see alleviating the issue where everybody relies on a small group of relays or is forced to send many requests to many different relays for each account they follow. First is more clients using the Gossip method. Gossip, if you’re unaware, is a client that has a somewhat unique way of getting posts from accounts you follow. Instead of the somewhat standard ‘query every relay you have for all the posts of the people you’re following,’ Gossip instead uses the best relays for each account. Exactly how many relays you query per account is set by the user, but it defaults to two, so if you were to follow say 100 people and have 20 relays in your client it would only query two relays for the posts of any specific account (200 requests instead of 2000). This is basically the RSS route: give me the posts from this user stored on this relay, but throw in a second or third as a mirror for redundancy. No need to waste resources querying all the relays I’m connected to when I know that this particular user is on, say, their own relay and one large relay.
Doing something like this completely negates the issue of having too many relays, placing an undue amount of load on the client. As much as I call generic Nostr RSS’s spiritual successor, if this style of following becomes default, it pretty much becomes RSS 2.0. A simple set of items on a server organized by date and pulled into a client that very much resembles an RSS reader. The only difference here is the optional interaction, cryptographic identification plus optional domain-based identification, and a couple of servers for redundancy.
The second big option in my mind would be to create an optional DHT layer as well which could be implemented into clients, though for most would probably be best implemented into relays. As long as you’re on that layer you could request the notes of somebody who is not on your list of relays, then either your client or DHT-enabled relay could check what other relays on the DHT portion of the network have posts from the account before providing them to you. It would likely be slower than querying regular relays, but make a good fallback to ensure you always have access to all of the network without needing a long relay list.
There are also other potential options, such as servers gossiping (unrelated to the Gossip client, in this case ‘gossiping’ is just federation of posts between relays). The protocol could also get more aggressive with re-broadcasts - posts are already shared to your list of relays when you repost, but perhaps even liking/reacting could re-broadcast to your list of relays. Finally, an account could always be tagged with a ‘preferred’ relay. Accounts already list the relays they’re publishing to, so it could likely be possible to set a ‘preferred’ relay where the client only queries the preferred relay for said account unless the preferred relay is down or not in the requester’s client.
AT
Account Migrations
The biggest thing I would like to see (and am seeing) is its continued development. Account migrations are a big one, if you want to make your social media home base on AT then you really need to be able to move from one PDS to the next. Otherwise your account only lasts as long as your host does.
Direct Messaging
DMs are another thing that’s in development and could be handy to see. It could just be simple DMs, preferably E2E encrypted, or instead an either temporary or permanent solution would just be to outsource DMs to another piece of software. It would probably be possible to create a tag in an account where you set a Matrix/XMPP/SimpleX/etc identifier, and if you want to DM somebody you can click that part of their profile and do it from within software focused on messaging.
Community Software
Outside of the things that could be implemented by the BlueSky team, some other community-based software could also be cool to see. Relays other than the BlueSky relay (especially if they have a different purpose/theme - e.g. macroblogging or video sharing), or clients that grab content directly from PDSs and skip relays altogether are two things that come to mind. Not only would it be cool to see AT used more, but it would also give us a better understanding as to how well AT plays nice when interacting across other pieces of software. Finally, of course, this would help solve the centralization that AT currently has with the centralized BlueSky Relay being the center of consuming content on AT.
Honorable Mentions
Beyond the three big protocols there are a million different protocols out there. Okay maybe not a million, but there’s at least like a dozen or so. They’re all interesting, and if you enjoyed reading this you may enjoy reading about them as well. However, while I expect the three ones here to have a significant shot of blowing up and gaining a lot of growth, the honorable mentions are either not quite social media protocols or have a lot less protocol users.
Activity Pub is likely above 240 million accounts16, the nostr.band relay reports 33+ million accounts connected to that relay at some point, and even the new kid on the block BlueSky is reporting 6+ million accounts. Something like Zot, while very cool, has ~4 thousand user accounts and ~1k montly active users.
RSS/Atom is probably worth bringing up. You’re probably aware of it, a simple XML file to allows a reader to check for posts and other content. It holds blogging together, and you can follow just about everything on it. Still not quite a social media protocol though.
Webfinger is also probably worth bringing up. It’s a fairly simple way of having blogs and other websites find content and ‘ping’ each other to provide a comment or reply. It’s also used as a component in protocols like Activity Pub.
OStatus is effectively Activity Pub’s precursor. It took things like RSS, webfinger, plus other bits and pieces and turned them into what we would now think of as a microblogging protocol. Most servers that supported OStatus either switched entirly to Activity Pub, or do support OStatus but for compatibility rather than use it as their main protocol.
Diaspora is a protocol built for the social media server of the same name. I really like Diaspora, it gives its users a lot more complex control over their post visibility than any of the big three while providing a lot of nice touches. For example: supporting formatted text or setting different permissions for different followers by having followers in specific groups (e.g. public/regular followers, friends, family, coworkers, etc) instead of just having blanket ‘followers.’ Despite the additional options, however, it remains very user friendly and intuative.
Friendica, which I use, is based on the Diaspora protocol natively which allows it to have the same options for its users as Diaspora does. Friendica also supports Activity Pub, which it more or less internally bridges so that people can follow you on Activity Pub and vice versa. Diaspora servers themselves, however, do not support Activity Pub and can only communicate with other Diaspora servers, HubZilla, and Friendica servers. There is an active community on Diaspora, but it’s relatively small and not connected to the fediverse via compatibility or bridges.
Secure Scuttlebutt Is unique in that it’s entirely peer-to-peer, requiring no servers whatsoever and instead operating like a mesh network. As with anything P2P it uses cryptography to identify its users, and is actually what Nostr is based on. Unfortunately, needing to host your own content on your own device can get a little inconvenient for the average user, which is where Nostr came in to address that.
Zot, Hubzilla’s native protocol, is a pretty complex protocol with a lot of options for users and thought put into it by its developers. Creating an account on a Hubzilla server lets you create ‘channels,’ which are the things that you’d follow (user@domain). The channels, however, have cryptography hidden underneath allowing users to mirror them elsewhere, sign in on other servers, and migrate with ease. Similar to Diaspora, you can do a lot of per-user permission configuration, choosing who can see what; and Hubzilla offers a whole suite of tools like wikis and webpages in addition to general social media-like stuff. It’s complexity, however, does become a bit much to navigate until you get the hang of things.
Like Friendica, Hubzilla can support Activity Pub, so if you like Zot but want to participate in the fediverse and larger overarching distributed social media landscape you can do so from within Hubzilla. However, any Zot-specific features (like Nomadic Identity’s mirroring content) won’t carry over to any Activity Pub servers. Of course that may change soon if Zot’s Nomadic identities make their way into Activity Pub.
Wrap Up
So, what do I use?
If you’ve been following me for a while you’ll probably know that Nostr is my choice of distributed social media. The largest draw for me has been the amount of control over my account and client. Want a home timeline that resembles an Activity Pub local or federated timeline? Set exactly what relays you want displayed and optionally set up some filters. Want to interact with a server others deem undesirable - or alternatively - want to avoid interacting with a particular server? You can set your client to interact with the relays of your choosing and fine tune exactly what functions it does or does not use them for. A relay went down? No worries, you control your keys so you’re good to go update your relays and continue on17.
Secondly, its simpler nature is also a draw. Being a longtime RSS user I can appreciate that it’s very flexible in how I interact with it. It’s also very lightweight server side, and while I don’t currently host anything on it I can still appreciate its minimal overhead. While mirroring and offloading processes to clients is a little more heavy on that side of things it’s only ‘heavy’ in terms of transmitting and parsing text. If you can stream video your device will probably handle a client just fine.
But of course that’s just my personal preference. Tinkering with Nostr requires a mild degree of technical knowledge and an interest in taking the initial time to fiddle with it to get your preferred setup. Just like me following YouTube creators through RSS on a self-hosted reader: while I am very much in the minority of the methods of following, with a touch of technical knowledge and the interest in tinkering with it I’ve arrived at a siduation that I prefer over native YouTube18.
But it’s not like I don’t use the other protocols. I follow a bunch of Activity Pub accounts and an AT account or two from within Nostr, and also have an Activity Pub + Diaspora account on Friendica. And of course, with different goals, I would likely be using a different protocol as the base of what I’m trying to accomplish.
If I were trying to create an instance for friends/family or any other specific group/interest that wasn’t all techy people I would probably go with an Activity Pub server. It’s built around individual communities and doesn’t have much of a learning curve if you give somebody a link to your instance and tell them to sign up like any other social media service.
Similarly, if I was building the next big platform19 I would probably go with AT. Having your own relay gives you a lot more centralized control over the platform’s direction and provides an on ramp that requires the least technical know how of the three protocols. On the same token, however, people on self-hosted PDSs give users a way to host their own part of the network with very minimal overhead while retaining control over their accounts. PDSs can also be crawled by multiple relays, so you wouldn’t likely be starting with an empty network. Further, unlike Activity Pub’s Threads, users wouldn’t need to make that platform their home base to use it20.
Conclusion
So, in conclusion, you just read 15,402 words about distributed microblogging protocols. Nerd.
Footnotes
-
To clarify real quick, I assume most of those visitors are RSS readers checking for updates. ↩︎
-
It’s always cool to see people from non-English speaking countries reading stuff I write. I’ve always gotten a lot of German and Polish traffic, and more recently a lot of Italian and French too. I know that, unlike me and my fellow Americans, most people can speak more than one language fluently - but it’s cool to see people who seemingly find my content interesting enough to read even with the inconvenience of it not being in their native language. Lol, you thought I was going to use this footnote to make a French joke, didn’t you? ↩︎
-
Darn you Nooti dev(s), you beat me to the punch by like two days. I was so close to getting to say I developed the first multi-protocol client that works on all three big ones 😆 ↩︎
-
When threads joined the Fediverse there was a lot of controversy and a lot of servers defederated. I personally think that was a wrong move, though obviously if admins own their server they get to make their own rules. Eugen Rochko’s blog post might be a good introduction to the topic. ↩︎
-
I’ve also been asked “What’s your Gmail?” ↩︎
-
Whether or not a switch back to Web 1.0 technologies is part of Web 3.0 would be debatable, but all the different terms have different definitions depending on who you ask. I guess it comes down to whether your definition of Web 3.0 includes shifting away from the big platforms in all forms, or just refers to shifting away from the big platforms to newer protocols and systems. ↩︎
-
Most of this post is on protocols, not platforms built on those protocols. Nevertheless, the BlueSky relay handles about all of the relay-level AT stuff, so I guess it’s worth bringing up. ↩︎
-
Yes, bask in my geniousness. Lol, but seriously to be clear I’m not claiming to have inspired the potential change. Just glad to see my spitballing had some feasibility. ↩︎
-
A cypherpunk is someone who believes that asymmetric encryption is the key to advancing computers while granting us more privacy and control over our machines. I do agree with that idea, although the time when people were calling themselves cypherpunks was well before my time. Then again though, I’m guessing the reason why people stopped calling themselves cypherpunks but still hold the ideas is because the cypherpunks won. Everything from the most base level operations in the CPU on your device to the HTTP GET request your browser made to get this blog post relies on asymmetric encryption. The final step in worldwide cypherpunk domination is to replace the big platforms (e.g. Twitter/X) with ones that hand control over to the users who identify themselves with key pairs. ↩︎
-
Well, again to specify, I’m probably not even qualified to write this blog post to begin with. I would like to reiterate: this is a ‘here’s cool stuff I would like to ramble about’ not me being some sort of subject matter expert. ↩︎
-
AKA quick, change it to the dark theme. To each their own, but if you don’t switch to the dark theme enjoy your burnt-out retinas you masochist. ↩︎
-
For example, when Infosec.exchange got defederated people migrating away from the instance lost some of their subscribers since their subscribers’ instances defederated with infosec.exchange and ignored the notice from infosec.exchange that accounts were migrating. ↩︎
-
This can become an unavoidable problem if you’re on an edge case like the taliban seizing a domain or .ml domains being deleted. It can also be an issue if a domain was forgotten to be renewed and was taken by somebody else, or in any other siduation when migrating the domain of a server is wanted/needed. ↩︎
-
Various for-profit platforms built on top of the protocols (Threads, Minds, etc) will likely aliviate some of this stress. A profit driven host can serve a ton of people without digging into the more limited donation-powered servers as well as provide an easy on ramp. ↩︎
-
Remember, Threads is ~240x larger than all of Mastodon and TruthSocial is ~25x larger then all of Mastodon. While the 0.1% is just spitballing, keep in mind Mastodon.Art blocks both of those and a whole bunch more ‘run-of-the-mill’ Mastodon/Fediverse instances as well. ↩︎
-
Just a guess using Threads, Truthsocial, and the Join Mastodon user count. Getting an accurate count of all users on a decentralized protocol is nearly impossible. ↩︎
-
When I joined Nostr the latter two things were only theoretical in my experience, but have since - as I mentioned above - come to my aid where my Activity Pub account has not. As far as federation goes, you only need to look at the threads or bridging drama to find instances where you wish to either access or block specific servers when your home server made the opposite choice. Even if your home server looked good when you joined, if admins changed their mind or a controversy hits after you joined you may end up in a bind. Further, as for servers going down or your account being deleted - as I also mentioned above - I lost my posts/following/followers when the Nerdica SQL database died. ↩︎
-
If you use the YouTube app consider checking out GrayJay or Newpipe on Android, Freetube on desktop, and Invidious or Piped in any browser. ↩︎
-
Forever ago I heard that Threads wanted to be built on AT instead of Activity Pub, but the BlueSky team said no. When writing this now, however, I was unable to find any information actually corroborating that story so take it with a very large grain of salt. ↩︎
-
Assuming it is possible to sign in using an account on a remote PDS. ↩︎