Centralized social media networks are not ideal, but also hard to avoid. Twitter is an obvious example of a wholly centralized network. Whoever owns the company owns the namespace, network, protocol, platform, and ruleset. This has been painfully obvious in the last few days, with Elon Musk able to make sweeping changes to the network on a whim despite widespread user backlash.
Understandably, a lot of users who have come to rely on Twitter as a communication channel are now looking for an escape, and finding very few alternatives. Accounts and social graphs that they may have built up over the years are now inextricably linked to Twitter, and now Elon Musk. Twitter is a walled garden where user accounts are not portable beyond the scope of the platform. The best you can do is download an archive of your data and re-host it elsewhere, or create a new account on another social media network and try your best to redirect your Twitter followers to that new account.
protocols, not platforms
In an ideal world, we should really be striving to build and adopt more open source protocols rather than locking ourselves into centralized services. This is something we've done with the web in general, and one reason that new browsers (like Arc) and even whole new internet protocols (like Gemini) continue to pop up all these years later. Elon Musk can't just buy TCP/IP and change the rules on a whim, because there is nobody to purchase it from. The protocols that make up the modern web experience are open source and public standards that many clients have come to consensus on, like HTTPS, CSS, HTML, DNS, SMTP, and plenty of others.
To be clear, open protocols are not immune to centralization. Email and web browsing in general tends to be pretty heavily centralized toward Google (Gmail and Chrome). Nevertheless, users do still have the option to move between competing clients and software atop these shared standards, which is more than we can say about Twitter.
Fediverse
One set of protocols that is beginning to find interest is Mastodon and the "fediverse"—a collection of tools and platforms mostly using the open source ActivityPub protocol. In this model, instead of a single server like twitter.com, there are many servers that communicate with each other, often run by individuals. Savvy users can choose to run their own solo servers, perhaps for maximum control over their account and data, or to build a small network with their friends and families. This federated model has some improvements over the wholly centralized "town square" model of Twitter, but also some drawbacks.
Since it's technically challenging and costly to run your own solo instance, most users end up creating accounts on larger instances, like mastodon.social, mas.to, mastodon.art, and so on. This creates clear points of centralization: if mastodon.social goes offline or the property is purchased by a bad actor (as many feel is now happening with Twitter), then a significant portion of users across the fediverse will be affected.
To counteract this, Mastodon allows users to migrate their account to a new server without losing their followers, which is not possible in Twitter's centralized model. The downside to migration is that the user loses their original account, including the username, and any services that may have come to rely on it. Your posts, likes, boosts, bookmarks, comments, and all your other data will be stuck on the old instance, which might eventually be turned off and lost for good. You can download an archive of your posts, but you'll be forced to re-upload all of your content on the new server, without all of the discussions and context that make these timelines interesting to preserve.
This all sounds a bit like the way email works, and we could imagine a similar end-game to the fediverse. As the fediverse scales and attracts larger investors, eventually most of us will be on google.social or meta.social or whatever large tech company provides the best UX, network uptime, and content filtering. Just as users on Gmail can migrate to another email provider, there is a lot keeping us locked into a few centralized service providers. It seems entirely possible that Mastodon, like email, will end up highly centralized if it continues to scale.
Beyond this lack of account portability and likely re-centralization, there are two other concerns I have with the fediverse as it currently stands: siloing, and lack of strong privacy.
communication silos
Mastodon's federated model unfortunately tends to create silos of communication. Admins have the power and motivation to shape communication across the entire network by cutting off other instances from interacting with their users. An admin of mastodon.social might reasonably decide to block the nazi.social server, ensuring users on that server cannot interact and engage with anybody on the admin's server.
However, this model can also prove problematic, creating schisms between online communities based on the whim of a single administrator. Sometimes these schisms can be petty—one administrator getting into an argument with another—or sometimes it can be about something more divisive, like the perceived political leanings of an instance or the blocking of a sex worker-friendly instance.
Even art is not immune to these administrative ills; silos are beginning to form in the fediverse around AI art (such as prompt-to-text images created by Stable Diffusion) and NFT art (such as generative art on fxhash.xyz). The most popular instance related to art, mastodon.art, is run by an admin who is against both NFT and AI art, and has stated they will suspend accounts that do not follow their strict guidelines on these topics. Although having your supposedly decentralized Mastodon account permanently removed for posting this kind of art is alarming, the greater concern is that the mastodon.art admin may decide to de-federate other instances that have too much content related to NFT and AI art. Another server, genart.social, which aims to be the home for a wide range of generative and computer artists, has had to set up rules warning users not to post too much NFT content, as it may result in larger instances de-federating the whole genart.social instance, leaving everybody on it cut off from the wider Mastodon art community.
private data
Another concern in Mastodon is the way that direct messages (DMs) and private data is handled. These messages are not end-to-end encrypted, and so instance admins can read all direct messages between users. If you are communicating across instances, such as a genart.social user DMing a mastodon.art user, you have to trust both instance admins with your private data. This means trusting their operational security (what they are doing to prevent data breaches), trusting their motives (they will never sell the data or use it against you), and trusting all future administrators of the instance (the instance owner will never transfer ownership of the data to another admin with perhaps less noble intentions).
This is not just a mastodon problem: Twitter, TikTok, Instagram, and many other networks do not have E2EE direct messaging. By moving from Twitter DMs to Mastodon DMs, you are moving from trusting a multibillion dollar American company with your data, to trusting a handful of hobbyists around the world with your data.
self-hosting
The solution to some of these problems is to self-host your Mastodon account, so that nobody will censor you on a whim based on what your peers are saying, and so that you aren't locking your posts into an instance that may one day become defunct. In practice, hardly anybody does this, because the barrier to entry for running your own instance is quite high. Not only is it fairly technical, but also costly.
Perhaps easier than setting up your own server is use a managed Mastodon hosting provider, like masto.host. This service recently had to stop new registrations due to high influx of traffic that was causing their systems to go offline. Once again, this is an area that we might eventually expect to see Google, Amazon, or another major tech company re-centralizing the network by providing better UX, lower costs, and more reliable uptime. Imagine escaping Twitter's servers for the promise of a decentralized social network, only to end up with an account and your data managed by Google services.
In Mastodon, and almost all social networks, centralization rests on the answer to "Who owns the namespace?"
other protocols
There's a number of other open protocols being built that tackle things a little differently than Twitter and Mastodon.
BlueSky's AT Protocol has been slowly building behind the scenes, and seems promising. It takes some inspiration from Mastodon and ActivityPub, but aims to solve account portability and use a different mechanism for user identity. There is no software yet for the public to test, and the spec is still incomplete.
nostr is a very small hobby network that presents some interesting ideas and aims to solve some of Twitter and Mastodon's problems, but it also has its own drawbacks. Users are identified with public keys (long hashes of digits and characters) rather than user-friendly aliases like @mattdesl. Instead of aiming to solve the "Who owns the namespace?" problem, nostr approaches this differently: "There is no namespace." So far, it seems like a niche network for hackers and cypherpunks wishing to communicate in adversarial environments, but it does have potential to eventually grow to more mainstream audiences.
Others like diaspora*, secure scuttlebutt, and Solid are worth mentioning. I find it hard to envision these replacing Twitter for an average user but would be happy to be proven wrong, and will be keeping my eye on these protocols as they develop.
a shared "town square"
So far, I've mostly pointed to federeated social networks, where the accounts and communication is split across many servers. Something that I like about Twitter is that it acts like a busy town square with a mixing pot of opinions, rather than many separate silos of interests. This is an easier mental model—everybody posts to a single timeline—and also means that we moderate our feeds based on content (spam, toxicity) and users (trolls, bigots) rather than moderating based on domains (that might contain a mix of good and bad content/people).
I also like that I just have one username: it's just @mattdesl on Twitter. This makes verification pretty easy. Any account that doesn't match this string is most likely an imposter. Whereas on Mastodon, there may be several accounts named @mattdesl across popular domains and instances, and no clear way to distinguish them (aside from, perhaps, using my Twitter profile as a source of truth, where I might point to the correct alias).
Is it possible to build an alternative to Twitter that isn't centralized, and still retains this feeling of a "town square" and flat namespace?
Farcaster
One promising open protocol I haven't mentioned yet is Farcaster. This is still in very early development, and the clients are behind an "invite-only" beta, so it is by no means a real challenger yet. But the protocol design does present some interesting ideas, and I imagine Farcaster or something like it could demonstrate a new model of sufficient decentralization for social networks.
Farcaster opts for a single flat namespace, so that there is just one @mattdesl. However, this namespace will not be owned by a single company (Twitter Inc), or a federated network (Mastodon), or a small permissioned consortium (what BlueSky proposes). To achieve this, Farcaster plans to use a smart contract in a public and distributed ledger to store a mapping from user identifiers (e.g. 51305123) to user aliases (e.g. @mattdesl).
the blonkchain
It's worth noting, the only part of the protocol that uses a blockchain is this user registry. All the rest of the data—messages, media, posts, likes, follows—is not posted on the blockchain, and so the majority of the network and communication is closer to the way that Mastodon, BlueSky, and other typical web protocols share and host data. Farcaster is not "Twitter on the blockchain," which would be a terrible idea. The blockchain is a poor storage mechanism for user data—it is immutable (you can never delete a post) and extremely bandwidth-limited (the cost to upload just a single media tweet would be hundreds of dollars).
But, short username aliases like @mattdesl might be something that could be managed on a blockchain (eg: Ethereum) or blockchain-like ecosystem (eg: zero-knowledge rollups posting occasionally to Ethereum). In the 10 years that I've been using Twitter, I've only ever registered a few usernames; and I would be OK with spending a couple dollars and waiting upwards of an hour or two for this action to be confirmed, if the added benefit is decentralization and self-sovereign identity.
why blockchain?
Some readers might wonder, why use a blockchain for the name registry instead of something like a MySQL database? The simple answer is that a blockchain-based database can be distributed across thousands of machines, and become effectively ownerless: meaning that no single actor can modify, own, or control the smart contract and the records in its namespace. In theory, a single attacker could spend billions of dollars per day to control all of Ethereum, but there are ways for users to defend against this attack, draining the attacker’s capital and reverting the changes they attempted to push through the network.
Another unique property of blockchains is that they are permissionless and public: anybody can access their state and build software on top of them. A developer does not need to be issued an API key to run a node, and they can be relatively certain that their access to this database will not be suddenly removed from them some years later.
Blockchains and smart contracts do have their own set of downsides and complexities, like transaction fees, slow finality times, private key management, protocol governance, and more, but this idea does present some interesting new opportunities.
account ownership
As there is no single custodian managing Farcaster's namespace, users can choose to hold and own their accounts non-custodially.
Accounts are maintained using asymmetric cryptography—comprised of a private key (eg: 12 to 24 words) and corresponding public key—and these could be secured with a pen and paper, stored on a user's computer, saved by a cloud provider, or even split across the three like some sort of cypherpunk Horcrux. Giving users the option for non-custodial ownership solves some aspects of account portability and the high barriers to self-hosting your own username in Mastodon and the proposed BlueSky protocol.
Rather than requiring deep technical knowledge and a continually high cost to setup, maintain, and secure your self-hosted web server, you only need to secure the 12 to 24 words of your account's private key. This, still, is no small challenge, but keeping a single passkey safe is arguably easier and cheaper than learning to run and manage your own web server, and secure that server's passkey!
avoiding re-centralization
Even if you don't trust yourself with security, and decide to use Twitter or Google cloud services to store and maintain your private key, you may not be ceding all control to them like you would with a federated protocol, so long as they allow you to exit. Imagine, for example, you've chosen to host your private key on a Google service, to avoid having to secure it yourself. As long as Google still allows you to transfer your username to a newly created private key, you can exit their system, and go back to non-custodial ownership and/or choose another custodian. There is no concept of "old account" and "new account" here, so there is no need to painfully migrate or re-build your social presence. Instead, this is all one single account identified by a single alias, say @mattdesl, and the blockchain-based ownership of this property has changed from one private key (previously held by Google) to another (now held by me).
account interoperability & permissionless innovation
If you accept this form of account ownership, you can also imagine building services on top of it that span the web. Imagine my Farcaster username @mattdesl could be verified and be used across a variety of unrelated protocols and applications—podcasting, books, games, blogging, recipes, whatever. This is what it means to really own your data & online identity, not just the files that can be copied and re-posted, but the social capital and network effects that cannot be duplicated byte-for-byte like a file.
We already have something like this on the web with OAuth and "Sign in with Google" but, alas, this centralizes more parts of the web under Google's banner (or Meta). We could perhaps imagine "Sign in with Mastodon" to escape this, but, as accounts are not portable in Mastodon, you'll be in a pickle if your instance ever censors you or decides to shut down (and, if we do imagine Mastodon ever scaling to billions of users, the top instances might actually be hosted by Google anyways).
Beyond account interoperability, Farcaster also aims to encourage “permissionless innovation” by publishing the protocol as a sort of immutable public API, not unlike the original vision of Twitter. So far, this seems to be working, with dozens of bots, tools, and even web clients beginning to be built by the Farcaster community during its closed beta.
censorship-resistance & moderation
One distinguishing factor in the Farcaster account model is that you cannot be "banned" or wholly ejected from the protocol. This is a growing concern on Twitter in recent weeks, with some users banned for parodying Elon Musk's accounts, while others are being permanently suspended for what seems to be a case of autonomous moderation systems gone rogue. These suspensions are perhaps even more frequent in Mastodon’s federated system. If you rely on these digital account for work and social connections, a suspension can negatively impact your life, destroy your digital past, and cut you off from certain opportunities, especially as our lives move to increasingly digital and online forms of communication.
Many might wonder: does this mean hate speech will run rampant in Farcaster? Probably not: hate speech, spam, and malicious content can still be moderated away, by adding filters and restrictions at the hub and client level that target these bad actors. If you are frequently posting hate messages on a certain username, hubs and clients will likely put you on the blocklist. If you feel you've been wrongfully blocked, you'll have to petition to these developers and administrators to have the suspensions lifted.
It remains to be seen how well this kind of moderation can work at scale, so this is something that Farcaster may struggle with. One measure that gives Farcaster a leg-up over Mastodon and Twitter is that accounts are not free to register, which could mitigate a large swath of spam and troll accounts that most protocols currently struggle with.
user experience
Although Farcaster uses a blockchain under the hood, most users do not need to engage or interact with this system, and many will not even realize they are using a blockchain and crypto wallet. Say a $5 annual fee is required to secure the username (to mitigate spam, avoid mass name squatting, and to cover blockchain fees), this cost could be absorbed by the client developer (just as mastodon.social is free for users, but not free for the admins who must pay hosting fees). Alternatively, payments could be made by users through a standard Stripe fiat payment interface, with transactions sent through OpenGSN to avoid users needing to hold or interact with crypto currencies.
There will likely be a range of clients and software solutions on top of this protocol, and savvy users could always register accounts in the namespace directly by interacting with the user registry smart contract, which might give them the benefit of lower fees, faster settlement time, permissionless registration, and stronger privacy controls.
media hosting
An important consideration in social networks, aside from who controls the namespace, is the question of who hosts and controls the data. In Mastodon, almost all of your data is hosted and owned by your instance administrator, but some of this data (like follows) can be downloaded and later re-uploaded to different instances (this is how Mastodon's follower migration works, but fairly autonomously). Protocols like nostr, Farcaster and secure scuttlebutt instead distribute and replicate some of this data across the network, so that it does not lie in control of a single actor—which is arguably a more desirable outcome for a decentralized network.
The real challenge lies with large media: GIFs, images, videos, and anything that is not trivial to store and replicate across hundreds or thousands of nodes. If you upload a GIF to a social network, the message typically contains a URL to the media file, like mastodon.social/images/cat.gif. This creates a vendor lock-in, where the persistence of the content in your messages is reliant on whatever hosting provider the instance administrator has chosen, and the only way to migrate across services would be to re-post the content with a new host.
One solution that BlueSky, nostr and Farcaster will probably all be faced to consider is content-addressable storage systems like IPFS and Arweave. This allows user data and accounts to remain portable across hosts and services, without needing to re-upload and re-broadcast the new URLs to the network, because the links are based on a hash of the content rather than anything related to the host. These storage solutions have their own problems, though, like how is the storage moderated and who is paying for the hosting costs.
not yet ready
All of this might sound interesting, but protocols like Farcaster are still nascent: beyond the invite-only beta, there are still no open source client implementations, the spec is in constant flux, and some hard problems have yet to be clearly solved. However, it does propose a sketch of an idea, giving us a new model for account ownership and interoperability on the web without sacrificing user experience or decentralization. Farcaster's model of "sufficient decentralization" might inspire other social network protocols, and I am sure we will see a few competing platforms tackling this problem in a similar way.
In the meantime, I think it's worth continuing to develop and keep an open mind toward a wide variety of competing protocols, to understand each of their strengths and weaknesses. For now, you can find me on @mattdesl@genart.social on Mastodon and @mattdesl on Twitter and Farcaster.