A few weeks ago a friend suggested setting up a personal web-page, for sharing blog-posts and a professional profile. I put this off for a while before I began researching the Fediverse.
The Fediverse
The Fediverse is basically a bunch of decentralized social networks and messaging apps, which can connect with each-other over a set of standard protocols. At the moment, the most popular of these are Mastodon, Bluesky, and Matrix.
Mastodon is built on-top of the ActivityPub protocol. This essentially allows anyone to create their own version of Mastodon, and potentially access different social networks using the same profile. There are some drawbacks however, as not all of these social networks are directly compatible with eachother.
Matrix is itself a protocol for decentralized, end-to-end-encrypted messaging. This can potentially be used to host other services, and has been implemented by some governments in digital infrastructure including healthcare systems and internal message platforms. However it is not exactly ideal for building a website or blog ontop of.
Bluesky
Lastly there is Bluesky. Bluesky was created by former employees of Twitter. It is designed to work like Twitter, with the difference being users have full control over where their data is stored, how their content can be accessed, and even what algorithms are used to generate feeds for social media posts. The AT Protocol was created for this. The interesting thing is, this protocol is actually very flexible in what can be done with it.
How the AT Protocol Works
The AT Protocol is documented here . The core of the protocol is based on a Decentralized-Identification-System. When an account is created on any service using the AT Protocol (at the moment primarily Bluesky), it is assigned a did-number. This number can be looked up in a public ledger, such as the one hosted and managed by the Bluesky team here. The DID is used to digitally sign any action done by an account on the AT Protocol.
The data for all these actions is stored in a Profile-Data-Store (PDS). Technically, anyone can host their own PDS. Users also have the ability to move data to a new PDS if they wish to. When they do this, the public ledger is updated to reflect the PDS the DID is now associated with. All an app has to do to retrieve information on a blog post someone made, or what users they are following (for example) is query the public ledger. It will tell the application where the PDS for that DID is, and the application will then retrieve the data from the PDS. In this way, users have full control over their data and what happens to it.
The data stored in a PDS is formatted according to a series of Lexicons. There is a Lexicon for following a user, liking a post, reposting, creating a new post, etc. etc. These lexicons tell front-end applications how data is formatted when it is sent to or retrieved from a PDS. The interesting thing is there really is no limitation in place for what Lexicons an application can use. Any developer can write their own, if they so wish. All that matters is that there is an app that knows how to interpret it. This makes the AT Protocol very flexible, and also better enabled different applications using it to be interoperable.
How This Blog Works
This blog is built using Lexicons created for Whitewind, a blogging platform that runs on the AT Protocol. You can actually go and view the blog on the site. In addition, you can see the Bluesky profile associated with the blog here. In both cases, data is being loaded from the same source, just rendered differently due to different Lexicons. Because of this, WhiteWind will not render posts made on Bluesky, and Bluesky will not render posts made on WhiteWind.
I borrowed a front-end from a project on Github called Whitebreeze. This basically generates a website that loads data using the AT Protocol. It uses the same Lexicons as WhiteWind, but it renders that data a bit differently to better suit the format of a personal web-page. Even the about-me section of this website is based on a blogpost made on WhiteWind.
Every aspect of this website is self-hosted. This includes the front-end application and the PDS where all my data is actually held. To avoid any issues with the relay network, the front-end makes requests directly to the PDS. There are probably simpler ways to run a website, but I thought this would be a fun excerise to get to understand the AT Protocol better.
Right now there are some limitations with it. Much of the actual infrastructure for verifying DIDs or relaying requests is managed by Bluesky. There are also not that many other applications running on the AT Protocol besides Bluesky yet. ActivityPub has much wider adoption, but this protocol has some advantages that I hope more people take advantage of.
