I’m pessimistic about federated architectures for new end-user products, like Mastodon. But, I could be wrong. In fact, I’d love to be wrong on this one. So since Blaine fairly called me out for implying that the fediverse can’t be better than Twitter, I’m gonna try to help, at least at first by pushing on all the UX aspects of Mastodon/ActivityPub that I think should be addressed.
Some will say that waxing poetic about software architecture is not as helpful as getting into the code and helping. There’s truth to that. That said, my strong sense is that we’re currently papering over major UX problems that are linked to core architectural properties. We’re papering over these issues out of excitement over growing adoption. I think that could limit the fediverse to a small community. So, some architectural and product analysis might be helpful.
Conway’s Law
Conway’s Law is sometimes referred to as “shipping your org chart”. If you’ve been in professional software development for a while, you’ve likely come to respect its power and inevitability. How your team is structured is always visible in the product you produce, and that can often be a bad thing for users. It’s the weird cracks of inconsistency and disconnectedness within a user application that makes you wonder if two parts of the app were made by two different companies.
Conway’s Law doesn’t only apply to software, but it seems to be particularly relevant in the software realm, probably because software is always changing, thereby revealing the organizational fault lines more regularly. Martin Fowler has a great analysis of Conway’s Law applied to software. The bottom line is that team organization affects software architecture deeply.
Conway’s Corollary
If Conway’s Law tells us that team org deeply affects a product and its architecture, let’s define Conway’s Corollary: software architecture deeply affects the product. Large product changes at scale often require large architectural changes. This might sound obvious, but we seem to be ignoring it in the fediverse.
What happens when key aspects of software architecture are immovable, or at least shockingly expensive to change? Like, say, in the fediverse, where users are signed up to different servers and the protocol between those servers is going to evolve very slowly at best?
UX to Fix
Usernames and Server Choice
An example of federation with good UX is cell phone networks. No one has to know that I’m on Google Fi or T-Mobile. I can change networks and you still don’t need to know. SMS messages are delivered and phone calls are connected without a hitch.
It wasn’t always this way. Cell phone networks used to not have number portability. You had to change numbers if you changed networks. If you never experienced this sad state of affairs, say if you only got a cell phone in 2004 or later, you might find this laughably outrageous. It was.
The state of Mastodon account management is in just as outrageous a stage as cell phones before number portability, and we’re making excuses for this. The cell phone networks made excuses, too. It’s hard, technically. Yes. And then they fixed it.
Users should be able to pick a username and then stick with it even if they change Mastodon provider. Other users shouldn’t need to know their Mastodon provider. No username should need to change.
I know, the specs don’t support this. They need to. Maybe that means getting rid of email-address-like usernames and having one global namespace. Maybe that’s an indirection overlay on top of existing identifiers, and those identifiers are not directly surfaced, like DNS over IP addresses. Lots of ways to think about this. But we have to start with the acknowledgement that tying provider choice to username is bad and cannot last.
Heck, this situation is bad even from a strongly pro-federation perspective. One key goal of federation is to let servers compete. Usernames tied to server choice is artificial lock-in. Lock-in means servers can be more poorly behaved, since users won’t want to migrate if it’s painful to do so. Let’s make it easy for users to migrate. Stable usernames, independent of server choice.
Full, consistent conversations
Did you know that if you read a Mastodon thread not on your server, you won’t see the same content as someone on a different server? You’ll only see answers known to your own server. I didn’t know this until Simon Willison pointed it out.
We can’t have real, quality conversations like this. And there’s no good product reason for this, it’s a Conway’s Corollary situation: the federation architecture makes it non-trivial / inefficient to make conversations consistent, so they’re not.
We have to fix this. Maybe it’s a spec thing, maybe it’s an implementation thing. Ultimately, two different users should, barring some server malfunction, see the same conversation thread, regardless of which server they’re on, or which server the thread contributors are on. We can’t let federation make conversations suck.
Following users on other servers
The most nails-on-chalkboard experience on Mastodon is this:
- Browse the web, land on someone’s Mastodon profile.
- Click “follow”
- Get some awful modal telling you to copy something, go to your own server, and paste it there, and 5 steps later, you can follow them.
Yes, I know, a number of native apps fix this. Great. That’s not enough. If the fediverse can’t leverage the power of the web, aka the hyperlink, what are we doing? This is another example of Conway’s Corollary in full effect, with federation making it suck.
It has to be possible to follow someone from their Mastodon page in one click, maybe two.
Good Enough Federation
We must remember that federation is a means to an end, not the end itself. Most users don’t care and will never care about federation.
There are, of course, some attractive features that federation gives us:
- Resilience to single company shenanigans
- User choice in provider, with different moderation policies and such across providers.
- Interop between different app types, e.g. Mastodon for mostly text and Pixel feed for mostly images.
Then there’s areas where federation hurts. I’ve outlined 3 of them above. I don’t think any of these are goals of the fediverse. They’re unfortunate side effects of the federation architecture.
Maybe we can fix these issues by only insisting on federation where it really matters, and loosening the architecture a bit where the pain is worse than the benefit. Because we don’t want to let federation make the experience suck.
I see two examples of where we can loosen federation a bit without losing the core values and benefits:
- Imagine a coordination domain, say mastodon-coordination.org, that would be used for local storage of a user’s Mastodon home instance URL. This would enable a follow button that works across the Web. Maybe one day this turns into a real browser API.
- Imagine a username layer, something that maps @benadida to @ben@mastodon.gmail.com, and later if I change to @ben@mastodon.yahoo.com, no one ever needs to know. We need a spec here. Maybe even a consensus algorithm. Maybe a small set of trusted servers a-la DNS. Maybe we need to make a new username format like @@benadida for smooth upgrades. Lots to think about for stable URLs.
The bottom line
Federation is both an architectural decision and a set of evolving values for how software can be built. If it’s going to work at scale, we need to consider how the architecture might make the UX suck. And we need to fix those pain points while rejecting perfectionist ideology.
Federation can’t be the bland vegetable of our Internet diet, where we’re telling everyone “yes, we know it tastes bad, but it’s good for you, really.” That’s not going to work. In fact that’s how we got centralized systems, because they gave users what they wanted without compromising the experience. It’s probably how we’ll get centralized systems again, even after Twitter dies.
If we want the advantages of a federated future, we can’t let federation make the experience suck.
Benlog 