This is part of a series of posts about the current state of Social Media. I talked about Mozilla’s failed strategy to get people out of the corporate-controlled networks and into the open alternatives and made a quick demonstration of how ActivityPub is used to power the “Social Web”. I wanted to talk about these things before I get to the main point of my thesis: the “Fediverse” as a concept of “servers who can interact with one another” is antithetical to the open, social web. We need to go back to the drawing board and re-design our software in a way that creates bottom-up connections, instead of the current top-down approach.
Federation is not the natural unit of social organization
I’ve already talked about this before, but to reiterate: aside from cases where people are self-selecting or acting as a representative of a larger group - i.e, they are part of that network because of their affiliation - the federation model has little to do with how people identify themselves and their relationships with others. It’s no wonder so many people have difficulty “choosing an instance”: they are implicitly being asked to pledge alliance to a group they never met before, and are told (literally!) that this will be a crucial part of their identity in this social space.
Other protocols like Bluesky have solved this issue, and there has been work on ActivityPub servers that decouple their domain from the user’s Actor ID, but the majority of servers still operate on the idea that users that want to use their service must “belong” to them.
Servers are expensive to operate
Centralized services benefit from a client-server architecture because of economies of scale. The marginal cost per extra user is neglibile compared to the initial cost of setting up a server, so when your service is being used by thousands of people, it is more than reasonable to focus on having a system that can grow by “throwing more machines at it”.
This is not necessarily true for distributed services. The obvious example is the “single-user” instance: any service provider will have to provision a whole Mastodon server, with its own database and its own processing queues, which can not be shared with other people.
We should not and need not emulate the fragmentation of closed social networks
While it’s undeniable that the developers of the leading projects have largely delivered on the promise of “getting rid of walled gardens”, it’s also true that our user experience is still determined by the type of server that we are using. This happens because projects have started by emulating one of the closed social platforms and “porting” it to ActivityPub.
- Mastodon (Pleroma, Misskey): like Twitter, but can federate!
- PixelFed: Federated Instagram!
- Lemmy: Reddit, but federated!
While there are some projects that try to unify some of these aspects (kbin, for example, provides both microblogging and group discussion), people still need to keep multiple accounts in different servers if they want to do different things. You can not follow someone’s Pixelfed stories from your Mastodon account, even though a less “server-centric” ActivityPub application would make this perfectly possible.
The server is the wrong place for application logic
Some issues from Mastodon:
- When you first sign up to a account, you might be greeted with a list of recommended users to follow. This list can be configured by the server admin, but in any case it will only be able to show you accounts that are from the same server as yours or from a server that already “federates” with it.
- If you visit a profile from an account from a different server, you can only see their posts that have directly interacted with your server. If you are on a small server, chances are that you will see only the profile information, but none of their previous posts, and you will have to browse to the “remote” instance to see their actual timeline.
- When you run a search query, you are running the query through the server, and again the results are only a reflection of the data that has been “seen” by the server.
- The “trending hashtags” feature only works for tags that have been explicitly approved by the instance admin.
Lemmy:
- The server provides different sorting methods for posts and comments, such as “Hot”, “Active”, “Newest”, etc. There is no way for the user to define their own sorting method.
- There is no reasonable way to define policies to handle votes, aside from instance admin being able to enable/disable “downvotes”.
All these issues could’ve been avoided if the decision-making process was delegated to the client. It’s nice that the server can make search queries, but it would be even better if the client could choose a separate, “global” search engine. It’s nice that the server can make recommendations for accounts to follow, but it would be even better if I had a menu pointing me to external services that are dedicated to this task. By forcing the user to do everything through the server, we become needlessly dependent on it.
Networks are smarter at the edges.
The “server-centric” approach to the application development is at odds with the nature of distributed systems. We need to stop treating the client as a dumb terminal and give it as much power (and responsibility) as possible.
The curious thing is that ActivityPub has already quite a bit a work of done to allow applications to do exactly that. The W3C specification has a “Client-to-Server” (C2S) API to standardize how clients can interact with their inbox and outbox, if we flip the architecture of the applications and make the clients responsible for the “smart” parts of the system (content discovery, timeline management, filtering rules for moderation and protection, etc) and let the server squarely with the single responsibility of message routing, not only we would make of the application development faster, we would quite possibly solve the scalibility and TCO issues of the server. If we consider that XMPP servers can handle millions of concurrent users on a single node, it’s easy to realize that this architecture would make large scale deployments of Social apps cheaper.
There is also another benefit for server operators: by turning the server into a “simple” message relay, there would be no data stored in the server and these messages could even be end-to-end encrypted, which would mean that operators would have less liability risk.
Lastly, we can not ignore one potential improvement in regards to privacy. Less data on the servers means there is less data available for the likes of Google, Facebook and OpenAI.
The proposal: a Social Web browser, built into the browser.
If we have the client as the center piece of our social web, why not build it already in the foundation of the web client that is already used by virtually everyone?
Going back to our very first post in this series: what did I expect to see from an organization known for developing a web browser, if not an initiative to have these features in the browser? Instead of experimenting with their own instance, Mozilla could have “executed with greater agility” if they worked on a browser extension that started a simple “Actor ID” follower. That alone would already be as useful as a “RSS reader for the social web”. After they got this in place, they could start refining it. Add login capabilities, notify user of received messages, post messages to public timeline, etc.
And for bonus points: after we got these building blocks in place, there would be nothing stopping us to extend the functionality to other networks. What better way to prevent data tracking from the likes of Reddit/Facebook/Twitter than by simply having an alternate client inside the browser?
There are extensions like libredirect that take links to “problematic” sites and point to alternative frontends. If users could have such a service built into the browser, we would be effectively denying the companies any chance of tracking users extensively.