Haven Blog

Bluesky is a project/company that came from somewhere inside of Twitter or Jack Dorsey. They’re moving forward with the idea that Twitter (or its replacement) should operate with an open protocol so that users can move between different hosting providers. Under this vision, Twitter would just be one provider but the protocol would be compatible with people who want to run their own servers and still tweet at each other.

I’m a big fan of open protocols, that’s a commitment I’ve made in building Haven on top of RSS. Bluesky decided to design their own protocol called AT, and shared an initial preview yesterday. I decided to write down some of my initial thoughts.

This is going to be a little bit of a technical post, so if that isn’t as interesting to you I’ll lead off with my general conclusion. Open protocols are great! If Twitter was built on something like this, then Haven could let you follow people on Twitter. That said, building a new protocol from scratch instead of working with an existing protocol community (like ActivityPub) means we fracture the ways that systems can talk to each other.

Account mobility is hard. In this case it means having an identifier that your friends can use to find you no matter where you live. Imagine having an email address that you could move from Gmail to Yahoo Mail to Outlook, and all the emails would keep reaching you. That’s the goal here. And it’s a good goal! Account migration is one of the big missing pieces in Haven, but even when it’s ready, you’ll have problems if you can’t bring your domain with you. Bluesky defines a Distributed Identifier (DID) as an abstraction layer that lets you point to wherever you live right now. Neat idea, but we’ll see if it works out.

If your account is mobile, then you need a way to prove that you actually wrote things that seem to come from you. This is where cryptography comes in. Instead of just trusting whichever server your DID points to, each message is cryptographically signed with a secret key. As soon as we have cryptographic keys involved, any software gets much more complicated. In general I lead towards signing as few things as possible. In AT, I think they expect users to provide their signing keys to the hosting provider directly, which misses a lot of the value you get from having a user sign their own messages. But key management is hard and I don’t expect most users to do it right (I haven’t even figured out how I would do it right!) Haven uses domain as ID, and SSL as the only cryptography. SSL certificates can be reissued as needed, so there is no need for long-term key management. If we get to a place where everyone has and controls their own domain, then we don’t need an abstraction layer or extra cryptography–your domain is the authoritative source for what you did or did not say.

AT defines a new remote-procedure-call format, which they call XRPC. It seems like this is mostly HTTPS/REST with built-in schema migrations. Schema migrations are important for a versioned API that can evolve, but this is already a solved problem with things like gRPC or Avro before it. Maybe they thought that an HTTPS and JSON API would be easier to build against but it seems like an unnecessary extra layer to reinvent.

On the whole there is a lot of good stuff, but I worry about the ability for it to stay an open standard. Today Google has dominant browser market share with Chrome, so they get to dictate new web standards just by building them into Chrome. If Bluesky is the behemoth using the AT Protocol and there are a few smaller groups also offering hosting, they might always be struggling to keep up with protocol changes that get forced into the ecosystem. But even that would be better than locked down APIs that prevent you today from reading Twitter unless you’re on the Twitter website or App.