ATProto is Just RSS With Extra Steps

Recently I setup a PDS server (yes, I know) so that I could host my own content on BlueSky. It was very easy to install, configure, create an account, and have it pass through the main BlueSky web application. I then immediately deleted it and went back to having my content hosted by BlueSky directly.

What’s the value in hosting your own social media feed?

Well, the marketing is true: you get to control “the algorithm”, or explicitly how your content feed is ordered, and you also control the source of truth for your feed data and user metadata.

So far so good. There really is a lot of value in companies and other large organizations hosting their own social media content on a federated server. The incremental cost is negligable (and I’m sure PDS hosting providers will be prevalent soon). But most importantly it can create a clearer division of ownership and assignment of copyright to social platforms and other consumers. This exact issue has come up recently in a lawsuit between Twitter and The Onion.

So, why delete your PDS server?

For one, I don’t really need the benefits (and I certainly don’t want the overhead) of federating my social media feed as I barely have a social media presence at all. Secondly, my issues with PDS are mostly academic and I think we could have done better with existing technology.

It’s clear that a lot of effort went into ATProtocol, and I’m glad that it exists. But it’s pretty complex, which becomes clear if you read the “quickstart” guide to building applications. I also question the portability of a decentralized data source when there is only one centralized interface for writing data (BlueSky). Perhaps in the future there will be other frontends that push data into your PDS, but I’m a bit skeptical. This feels like it has the potential to become mired in the exact same problems that caused it to be created in the first place.

I miss the old days of RSS

As a community we should have embraced RSS and extended it to support new features for the social media age. Explicit ordering of feed content is trivial, as is having multiple feeds with different priorities. Discoverability is simple and all content can be served via HATEOAS. Ownership of content and its consumption by platforms can be explicitly defined. Privileged and dynamic content can be supported by leveraging other existing technologies to treat feed consumers as trusted agents representing a known person. And finally RSS is human-readable, in an age where the web is becoming an obfuscated mess of near-binary payloads.

With ownership, discoverability, search, and content broadcast being solved problems that mostly just leaves commenting and other feedback mechanisms. That is a real engineering challenge to build on top of RSS but it’s certainly achievable, and I wish we would have tried.

This blog has an RSS feed. It was very easy to create, and sadly I don’t expect anyone will ever use it.