the drawbacks of federating

Essentially the past couple of weeks I have been looking at the three main Twitter/X alternatives, BlueSky and ATProto, Mastodon and ActivityPub, and NOSTR, and specifically trying to understand how they work and which I should use via self hosting.

the dilemma #

I dont really use social media since the government-mandated COVID quarantines of 2020-2022, but I have been trying to find a place for myself, media wise, in the past months (circa Feb 2024). To do this there was a necessity to go with the main stream, which in the case of my professional interests, having to do with AI and privacy, meant Twitter/X and LinkedIn.

I had known Twitter/X for a long time but never used it since it was always an “American” thing that we never used or cared about, but reluctantly I made an account around September 2024. Previously I had heard about Mastodon, and the ActivityPub protocol, which promised a more private, better experience, without algorithms, monetizations, etc.

After the Brazilian government banned it’s citizens from accessing Twitter/X, I heard about another alternative, BlueSky. This one also promised to be a better experience, but rather that talking about privacy, it focused on openness.

Recently I wrote a blog post on BlueSky where I went into detail about the things that I consider as a no-use for myself, and for anybody that respects their privacy online. After that, I talked with some friends who are also a bit privacy inclined and they told me to take a look at Nostr as that might be what I wanted.¹

Essentially the past couple of weeks I have been looking at the three main Twitter/X alternatives, BlueSky and ATProto, Mastodon and ActivityPub, and NOSTR, and specifically trying to understand how they work and why which I should use via self hosting.

What I found out is that in order to use a decentralised or federated social media platform you need to make data public, or you need to find a clean way to transfer data between different servers. In a proprietary, centralised system, such as Twitter/X, you can do this in an obfuscated way, since you control the entire stack, so the frontend and the backend are tightly knit so that no API endpoints come out and God forbid people use them to interact with each other.

Since federation/decentralisation mean that servers (in the case of federation) or devices (in the case of decentralisation) needs the different backends to interact and keep in sync over the public internet, things become a lot harder. Interestingly, all three options (BlueSky, Mastodon, Nostr) have tackled the same issue in different ways, each with their own drawback. Since I have already talked about BlueSky on a different blog post, I will briefely mention the drawbacks and sacrifices it had to make before I move on to the other protocols

atproto #

BlueSky works by making use of PDSes (Personal Data Servers), which store the entirety of a person’s interaction history across the entire network. This means that if there was an Instagram clone, you wouldn’t need to sign up to use it, you would already have an account, since when you signed to bsky.social, you didn’t sign up to bsky.app but rather you signed up for a PDS stored under the bsky.social, hence the @-handle is @username.bsky.social².

In this sense, BlueSky has done the bare minimum to be considered a federated network; if they block every other PDS from federating with them, they would be Twitter³.

Because they opened the atproto though, they had to figure out how to transmit and store data such as followers and likes to other PDSes on the federated network. For example, when I self hosted my own PDS, when I liked a post on bsky.app, that information had to be stored on my PDS, but if someone from the bsky.social PDS opened the post, then there should be a way for them to see that I liked the post in the past.

That way is unencrypted plain text.

Obviously this is very bad. Not only are malicious people and groups able to spy/stalk without anybody’s permission or knwoledge, but because the entire interaction history is public, people are not able to assert ownership over their data. Also, since the data is publically available, it is true that BlueSky or any other entity can’t sell your data, because the data is free for everyone. For people that are aware of these issues, it can be manageable; the old rule of pre-social media internet rings true.

Don’t share anything on the internet that is personally identifiable. You don’t know who the person reading this is.

The rule of thumb of using BlueSky or any atproto app then should be to treat every post as if it is going to be read by a stalker, a foreign government, or by the person or group of people you want to hide from the most.

I guess you can call this the Jack Dorsey Special™

nostr #

Nostr is a protocol that has the advantage over atproto of not having a centralised server. Rather, it uses relays with some of them able to store data and others simply moving traffic. This means that as long as you choose to connect and write to multiple relays, you have multiple, synced backups of your data, and then you effectively are uncensorable, which is what the protocol is all about.

The problem again is that nostr also transmits the data in plaintext JSON, exactly as atproto does. This comes with the added advantage/disadvantage, that since the relays are spread across the network, any data transmitted cannot be deleted and is public.

Jack Dorsey you madman, you’ve done it again!

The distinction to this is that because the network does not use centralised data servers, the data are harder to aggregate and collect. One would need to set a relay and try and convince people to use that relay, and even then people could choose to move away from said relay and the data would stay static and stale, which seems to be better that what atproto provides. This however does not guarantee privacy in any capacity, since just by picking packets in transit you can probably fingerprint users, like how users are fingerprinted anyways online.

The other issue with nostr is that of user experience.

Nostr tends to be favoured by the cryptocurrency community because they are used to the ritualistic behaviours associated with managing and juggling private keys. When you join the network of the nostr you are provided with a private/public key pair. The private key is your identity on the network, with which you sign all interactions to prove that they are indeed made by you. The relays and the clients then can use the public key to verify that the message was indeed sent by the person that it claims to be from. Like a signature.

I mentioned cryptocurrencies because in order to have a wallet that you own and operate, you need to keep the seed phrase secure, since it is the only way to verify that it is indeed your wallet. Likewise if the private key in nostr leaks, anybody can impersonate you and take over your social media, as this is the only method by which you can be verified and identified, and after your keys are leaked, you need to generate a new set, admit that the other account has been lost, and start from scratch, without followers.

This raises another issue. Logging in to a client application requires that there must be an identifying mechanism. The private key would be too dangerous, since it would require an extra step of trust, for which are browser extentions or applications for smartphones to handle that.

This probably means that nostr will never get a big userbase like atproto, since the average user doesn’t want to (and shouldn’t) have to worry about writting down private keys in pieces of paper for privacy, and then running specific browser extentions or applications in order to verify their identity (Password managers can already be used for these things and they aren’t by the vast majority, which proves the above speculation.).

activitypub #

ActivityPub is porbably the more private of the three when it comes to server/backend access and data storage, since it does not use public databases to transmit data, and rather uses a unified API system accross different platforms to facilitate interoperation. The issue of data safety still exists, since anyone can set up their own instance, federate with the broader network and collect data, but that is closer to traditional web scraping that finding an open JSON collection, since platforms and servers can choose to encrypt the backend. Also, since most instances tend to be small and community focused, I would assume it would be easier to notice a malicious entity trying to scrape other servers based on the generated requests, and then either the owner of the compromised server could ban the user, or they could defederate from the server the user is spamming requests at, or the other server’s maintainer could defederate from the compromised server.

Also, specifically for Mastodon and other currently used ActivityPub platforms, there is no algorithms or discoverability, although there is an explore feature to see posts from the entire fediverse, or another one to see recent posts from the specific instance that you use as your “home server”.

In terms of interoperability between platforms, since every platform uses the same API, there isn’t a “prefered app” when it comes to posting media. You can use your mastodon account to log in to a PixelFed (Instagram clone) application and use it as you would use it if you had made the account originally on a PixelFed instance, but the data are stored in the original home server, like BlueSky, but in contrast to BlueSky, these data are not public outside of people using the actual service.

The main gripe I have with ActivityPub is that it duplicates data, so that when two users interact from different servers, each server keeps a record of the interaction, which effectively means that nothing is every deleted. You can request a deletion of data, like a post on Mastodon, or a video on PeerTube, but the other servers can choose to not respect your request. Essentially they appropriate the data and now it is part of their server as much as it is of yours.

A good way to think about this is to think of users interacting by sending emails. Both users store their emails on their inbox, and if one deletes the email, the other one might or might not delete it also.

The other problem is that Mastodon (and by extention ActivityPub since Mastodon is the biggest service running on the protocol) is very political and therefore tend to self censor. Each server can choose to implement their own social contract and terms of use, giving the owners of the server or instance control over both who the users intaract with, via deciding which servers to federate with, and also control what the users say, and like BlueSky and unlike Nostr, the data is server specific. This gives rise to the possibility of echo chambers, which is an issue that can also happen on BlueSky, but not on Nostr, since Nostr relies on the user choosing relays to read and write from, rather than the server owner choosing which content to deliver. To some extent this is unavoidable; there is an inherent tradeoff between privacy and moderation, and for most people moderation and freedom from speech is more important that privacy and freedom of speech.

Obviously the option to host one’s own server is still there, but the issue then becomes playing by the same rules that the main servers play by, which are politically biased, otherwise you might get “Fediblocked” where the server gets put on a blacklist that is shared across the network.