Fediverse for dummy

Published October 29, 2024

I am a dummy!

When Twitter exploded I moved to Mastodon, I hosted for some time my own instance but at some point I lost interest for it and I moved to hachyderm I may get back to self-hosting, but that’s not the point, it is a spoiler!

Not sure if you noticed, but Kelsey Hightower deleted his Twitter account to move to bsky followed by every other real person still on X that works in tech, myself included.

bsky looks like Twitter 10 years ago if you look at its UI a bit more modern, clean, no advertise, no verified account everywhere, a platform made of people and not bot. I know it is already a lot, but it does not look like much more than that.

So what’s the point about this federation, atproto, ActivePub? I want to know otherwise I feel like I am missing something important.

First the mantra is that you own your data, but what it actually means? Well imagine developing a frontend application that relays on somebody else backend to work. Traditionally the same company own frontend, backend and with the backend the data produced by its user because they store it in their database. Facebook owns what we produce, Eventbride owns the landing page of our events, Meetup.com own the community people built there. Pretty sad because Facebook turned to shit, Meetup.com exploded and Facebook is Facebook.

We can’t trust them! And this is what the Fediverse is trying to solve. Let’s get back to our frontend backed by something else backend. This backend is not actually owned by a specific company, but it is owned by an association of companies implementing the same protocol that exchange data until none of them really owns them. Every publisher (ourselves) is authenticated, and the produced content associated to it. You can even spin up your own data server (PDS in atproto) acting as source of truth for the data you produce, or you can sign to another one like the bsky one for atproto or the Mastodon instance of your choice for ActivePub.

In this way you own your data like your posts in bsky but if you do not like bsky or they run out of business you still have your data, and the protocol so you can build an alternative frontend.

Let’s take my little fight against Meetup.com just describe. Instead of spending a few hours removing all the subscribers to my community to be able to delete it without risking that other people may get their hands to it, I could have used something like SmokeSgnal Event that is based on atproto to have the data under control. Their UI is not that polished or at least I do not really like their style, no problem! I can use the “admin panel” useful to register new events, manage RSVP and so on, but I can build on my own frontend because they speak atproto.

People leaving Twitter can download their archive, figure out a protocol and then expose their threads and tweets on their own website. If the same happens to bluesky we have the option to build something on top of atproto that exposes our posts as we like them. With access to all the interactions actually pointed to accounts that spans over a single product.

You can imagine this part like an OpenAPI with steroids. Instead of being a specification that you have to implement a client and a server for. The server already exists, authentication is already done, you just need a frontend for it. Such specification in atproto is called Lexicon. I didn’t try yet but probably if I register to SmokeSignal with my bsky handler and I configure at atproto client to publish an event to events.smokesignal.calendar.event “channel” it will show up there, but I will keep owning the event data since it will live in my PDS. The same applies for bsky posts.

atproto-browser is a project that helps you do visualize what the system knows about a specific user. Tom developed this website and as you can see is in active on blusky, linkat and smokesignal as well.

At the beginning my brain got stuck with the idea: “Ok, but we already have RSS feeds!”. Yes! This is sort of like that, with a much more complicated protocol supporting authentication, data ownership and so on. Those may look related only because a lot of the differentiations are under the hood, and I am slowly figuring them out. We will see if they stick. I am also not sure how close we are for not technical people to really care about this and I love to be an average person with a bit more time to waste surfing the internet.

I see the power of this idea, you can jump on board on half of the website and reinvent the other half because you have a protocol that locks how such data can be used (and then their ownership), people tend to have opinions, a pen can have a million shape and who knows if what today is an Event for SmokeSignal will fit another event provider or if we will end up where we are today building bridges between almost random APIs.

Something to experiment with for sure!

Are you having trouble figuring out your way to building automation, release and troubleshoot your software? Let's get actionables lessons learned straight to you via email.