What my chess app taught me about the future of multi-user software

I'm not gonna lie, it took me a while to figure out what the point of the AT Protocol (Authenticated Transfer Protocol) AKA The ATmosphere was or how it would be helpful. Until recently, Bluesky was the only mainstream app using it that I knew of. I understood that you could take your data with you, but where would you bring it? I guess if Bluesky went full x.com, someone could build a new app to move to, but that felt like a futile exercise that was nice in theory, but unrealistic in practice.

If you're active on Bluesky you'll learn that there's also Blacksky , Eurosky , Northsky . To the uninitiated they just look like filtered versions of Bluesky. There's a handful of other social apps like Grain Social , Skylight , or Streamplace which are attempting to replace multimedia-based social ecosystems currently dominated by our "favourite" tech companies. In my experience over the past two decades, even the most enjoyable apps quickly become enshittified when money gets involved. Open source (OSS) doesn't fix this: forks of major projects rarely find a foothold no matter how questionable those projects’ founders’ decisions get (WordPress is a recent example, but I've seen the same pattern unfold in many other OSS products).

My initial thinking was that Bluesky and ATProto were the same thing. Once a user is in a platform’s ecosystem, the momentum required for them to move away from it is often substantial. Even if you can take your data and your account, as is the case with OSS, there are often tools, products, and workflows you'll lose when you leave.

The good news is that I was wrong. The problem ATProto solves isn't that it makes migration easier for the masses, it simply makes individual migrations possible in a way that wasn't realistic before. I can move to a different app and still interact with all my contacts, without them needing to know or care. That same underlying technology also allows for fundamentally different approaches to software development. As a way to familiarize myself with the technology, I built a multiplayer chess app , entirely client side and entirely "on protocol". For someone unfamiliar with the concept behind ATmosphere apps, the way I explain it is this:

I built this chess app as a hobby. There's a decent chance I'll get bored of it and stop maintaining it. Alternatively, maybe I'll add a bunch of ads to the site making it virtually unplayable. You may have invested time, made connections with other players, and have a significant history in the app, so traditionally, you'd be stuck there. If you wanted to leave to another chess app that's maintained or just has better usability, you lose all of your history and all the connections you made. This isn't the case for ATmosphere based apps. Someone can build a better app and you can just start playing. In this case, if you started playing on the new app you would not only keep your stats, you could keep playing with the same friends even if they never left the old app.

This is known as a " credible exit " and is the number one selling point of the ATmosphere. But for developers, the technology is even more interesting. In a traditional online chess app the flow of information goes something like this:

Alice makes a move in her web browser, the server records that change to a record in the database and pushes the update to Bob's web browser who can now see Alice's move and respond. There's a single source of truth for the game state, and that's in the server's database, the record would include who is playing which colour, and what the current state of the board is.

On a fully client side app, like my chess app, checkmate.blue , there's no longer a server or database in the traditional sense. Bob and Alice both have their own Personal Data Server (PDS) , basically a small, personal, slice of cloud infrastructure that holds database records that only they can make modifications to. The records are defined by a public lexicon which is conceptually the same as table schema for the database record. This is where the chess game lives, one record in Bob's PDS and another, nearly identical copy in Alice's PDS. Anyone can read these records and view the current state of the game. Neither player can modify the other's record. Only Bob can write to his record and only Alice can write to hers.

The flow of a multiuser ATProto app is more like the following:

Bob's chess client is listening to the ATProto firehose (a live stream of every record for every app currently getting written or updated), keeping an eye out for chess records that match the ID of Alice's game.

Alice makes a move in her browser. This updates the position of the pieces on the board in her own record.

Bob's client sees an update on the firehose to Alice's game record. His client ensures that the move was valid, and updates Bob's chess board.

There are some logistical issues here, because instead of a single point of truth, there's now a point of truth for each player, and that's their own ATProto game record. First, client-side validation can't be trusted on its own so Bob's client needs to verify that Alice's move is legal and reject it if it isn't. Second, both records are never actually in sync, as soon as Alice moves, Bob's record is one move behind.

What ATProto is making possible here is a new category of multi-user web applications that don't need to be their own platform. The protocol handles identity, data storage, presence, sync, and real-time delivery -- in essence, the full underlying stack that modern web apps require. The fact that you can no longer enshittify or sunset apps, as long as there are still users who want the service, is just the icing on the cake.

What email did for communication in the 90's, ATmosphere can do for multi-user applications now. You're only as tied to it as your identity. If I'm using a domain I control for email (rather than an @gmail.com address), I can easily move to any email service I want. Apps like Gmail, Outlook, Apple Mail, aren't competing email products, they're competing clients on the same protocols with the same data. This is why no one has to ask you what email app you use before sending you a message. This is different from say, Facebook vs X where they're the client, protocol, and data, i.e. the full platform.

ATProto fits into the same group as email. And in that same sense, an ATmosphere app can't hold you hostage like Facebook and X do. What we'll now see is application categories collapse. I built a chess app here. There's no shortage of chess apps on the internet, chess.com and lichess are two examples of well known apps in the same category. In each, you'd have a set of contacts and game history. Under the new model, you just play on whichever app you like the most -- i.e. there's no longer a "chess category" of applications, they're all just different views into the same data and users. Bluesky, Blacksky, Eurosky, Northsky, etc. are all microblogging apps with the same underlying dataset, but they're all different views into that data, which is what we, as users, primarily care about at the end of the day.

Where this all comes together, and where I think the space will be most interesting is the long tail of applications. Applications that don't exist today because the overhead and cost to produce and maintain them may not align with the size of the user base. Think board games like D&D - a campaign has a DM, players, and a shared world and each role would have a different view into the same data. Or niche hobby apps, such as a bird sighting or mushroom ID app. These are hard to monetize from the business side and from the user side who wants to commit to a single app for what might be a decades long hobby. While building on ATProto doesn't necessarily make monetization easier, it does solve one major concern from an initial user base: commitment.

As the ATmosphere matures, apps will move beyond siloed data and accounts, they now become windows into a house filled with data that you own the deed on. For users, this means the work and effort you put into building relationships and the history you've accumulated never need to be lost. For developers it means we can start building weird, niche, and specialized apps that as SaaS model would never allow for. While checkmate.blue might get abandoned (don’t worry, it’s not getting abandoned yet!!), ATchess never will.