Blue Sky Potential

Bluesky (bsky.social) is interesting.

It's a social network. A clone of what Twitter used to be. And currently it is host to a large number of left leaning refugees from X. But that isn't what makes it interesting.

What makes Bluesky interesting is the AT Protocol - which is arguably a new way of thinking about writing applications. They will tell you it is 'an open, decentralised network for building social applications'. They will tell you AT stands for 'Authenticated Transfer Protocol'. But none of this really explains what makes AT Proto different - and why Bluesky is important (but not just because it is an alternative to X)

The first thing people will tell you about AT Proto is that it lets you keep control of your own data: You are not tied to one social network platform. And that's true. But it's both more complicated than that, and more powerful.

The first thing that AT Proto gives you is control over your identity. If you go to Bluesky, you'll see lots of posts come from '@someone.bsky.social' - but you'll also see posts from people like me coming from handles like '@ben.cha.lmers.co.uk'. I own the internet domain ben.cha.lmers.co.uk, and I can choose what it points to. At the time of writing it points to data which is hosted by Bluesky - but I can change that. I can point it to somewhere else that I have control over (but only if I can prove I have control over the place I point it to). What this means: if you see something that has been posted by @ben.cha.lmers.co.uk, you can check that I posted it... and even if Bluesky decide to shadowban me or moderate my posts away, it's possible to go to the place @ben.cha.lmers.co.uk points to and see what I'm publishing. This is powerful - it gives me an identity which I can prove I own - and which I can use with a number of different applications (more on that later). It also gives you a source of truth to see what I'm saying.

I spoke about different applications... and this is something that isn't quite as clear to people first encountering AT Proto. You're probably used to web apps like Twitter or Facebook. These apps tend to consist of a front end (which runs in the browser on your computer) and a back end (which runs on a server somewhere in a data center potentially halfway across the world). The front end talks to the back end.

The back end tends to consist of a database (which is where all your information - including your posts, friends, comments, likes and follows are stored), and code which decides exactly what you are allowed to see and which aggregates other information so that you can get a list of posts made by people you follow.

The front end tends to decide what the application looks like - and how the information the back end provides is displayed. It also provides the ability to control the site (which it does by, for example, taking key presses in a comment box and sending them to the back end and telling it to store them in the database)

AT Proto apps can be like this... but they don't have to be.

Bluesky is a good example of an app which, at first glance, looks like what I've described above. It has a back end, and it has a front end. But, well, there is more to it than that.

With Bluesky the back end is what AT Proto calls an 'app view'. An app view is much like a traditional web app back end. It has a database. It collects data (and potentially transforms it and aggregates it) and provides that data to a frontend. But with traditional web apps, that data always initially comes from the front end. In Bluesky, the data comes from your own server: the one your handle (e.g. @ben.cha.lmers.co.uk ) points at. And when you write a post in the client? That is ultimately stored on your own server. The database in the app view might store the information to make it quicker to send out, and to build relationships between posts and people who follow those posts... but the 'source of truth' about that information is on your server.

Now in the old world of web apps, you usually get one front end for each back end. But with Bluesky you can do something a little different. Bluesky's front end provides a client for the app view... but if you don't like how Bluesky displays the data, you can choose to build your own client. You don't need to build your own database - you can use the same interfaces that the Bluesky client uses.

(Like a web app, the front end can be a web page, but just as mobile apps often share back ends with web apps, the AT Proto client can also be a mobile app. For the sake of this article I'm mainly thinking about web apps... but don't let that limit you - there could be command line apps, things running on watches, things accessed by ChatGPT - the world is your oyster)

Technically, the app view doesn't need to make its interface public. But if it doesn't, there is no reason why someone else can't build an app view from scratch which does have a public interface. And, because all the data for that interface is stored on servers controlled by the users of the app, this new app view would be able to read messages posted to Bluesky and, when it posted new messages, Bluesky would read them.

What this means to you is that, if Bluesky started doing things you didn't like, it's possible to build a competitor (or find a competitor someone else has built) and start using it without losing everything you posted to Bluesky. Moreover, you can keep chatting with people who have not left Bluesky.

(Incidentally, there is somewhat more to how this all works - I'm over-simplifying it all - but this is core to understanding the power of AT Proto. One particularly interesting thing I've missed out is that you don't actually have to use an app view - you can use a client which talks directly to each user's individual server... it all depends on exactly what you want your client to do)

But that isn't all. Right now you are reading a blog article which I wrote using a website called leaflet.pub . I don't know if leaflet.pub will be around next year, or in five years. And frankly I don't care, because the moment I hit send, this post will be stored on the server pointed to by @ben.cha.lmers.co.uk . Now, you might be reading it through awesome.leaflet.pub but you could potentially be reading it through another website. Because leaflet.pub is also using AT Proto.

Just like Bluesky, leaflet.pub provides an app view and a client. And you can choose to just use the client (as I am at the time of writing), or you could build your own app view which accesses the data from my server and uses its own client.

And if you liked this article and began to think you couldn't get enough of me, you could potentially write a client which fetches both my posts from bsky.social and my articles here and shows all of them in one place. If you were a social media power user, you might also write a client which let you write leaflet.pub articles and bsky.social posts and combined them in clever ways, such as posting to bsky.social every time you wrote a new leaflet.pub post.

I hope you are beginning to get an inkling of how this ability to combine applications and data and to move from one client to another makes you so much more powerful - and frees you from your platform changing from a social utopia to a fascist state - because you're now free to move easily.

But what are the problems?

My biggest frustration with AT proto is the lack of private data sharing. Right now, everything I write is public. If I want to send you a private message, either that message will be stored on my server (and visible to anyone who looks for it) or will be hidden away in the database of an app view (and so can't be moved to another app view). There are people working on this - but it isn't a trivial problem.

At proto also can't be used to send (or store) large files. There are good reasons for this - and there are workarounds that can be used - but if we wanted to build the next Youtube we would need additional infrastructure.

While it is quite possible to host your own server, separate from bsky.social - it isn't easy. And it isn't straightforward to transfer your data from one server to the next.

And what possibilities does the future hold?

We are used to the the idea of paying for web apps. In the future, might we instead pay for access to app views? Allowing other people to build specialist tools which take advantage of the features you offer. I believe everything necessary to do this is already present in AT Proto - but a cultural shift will be needed.

I suspect there will be a role for personal server hosting. I foresee, again, paying a small fee to have complete control over your data (while it is managed by a third party). Such hosting could also help overcome some of the the issues relating to storage and distribution of large files

AT Proto makes life easier for solo developers, because it allows you to easily embrace and extend existing tools, rather than having to rewrite everything. It also allows you to exploit the network effect of AT Proto, rather than fight the network effect of incumbent players.

Will there eventually be some sort of uber-client. AT Proto feels a bit like the web did in the early days. Perhaps there is space for a tool which feels more like a web browser and less like a web page.

My concerns

A trend I've noticed in the software world is that tools start off open and decentralised, but ultimately one player becomes the heart of the network, and and order of magnitude larger than other players. That large player then exploits their position to move away from the open network and into a world where they have a monopoly.

Hopefully some of the design of AT Proto will prevent that - but this will only happen if we get a large ecosystem of different (and unrelated) applications using AT Proto so that it remains a disadvantage if any major app decides to try to capture the network it has established.

Philosophising

A lot is said about ecosystems when talking about SaaS platforms such as SAP, Salesforce or Jira. But these are not really ecosystems, because they rely on a single substrate (the platform) for all the other tools to survive.

AT Proto is, hopefully, building a true ecosystem where each element relies on many others - and where the sum is greater than each part.