🪢 Finally, tied the Knot

I have talked about my affection for AT Protocol (ATProto) in the past. So, I was planning to commit properly to the most interesting project built on top of ATProto other than BlueSky – Tangled, a better decentralised alternative to GitHub.

Tangled is cool - it supports JJ, has a CI runner built atop Nix, and, most importantly, enables self-hosting of repositories.

So, I have self-hosted a Tangled Knot server at git.kaushikc.org for my public Git repositories. The server is running the Docker image built with the configuration available in the knot-docker repository.

Here’s a thematic overview of how Tangled and Knot servers work from Tangled’s go-live post.

Repositories with identity

Tangled creates ATProto records and assigns a unique DID (decentralised identifier) to every Git repository. Here’s the record for hmm that I migrated from GitHub (a view in PDSLS, a public ATProto browser to browse ATProto records).

And the DID is then used when storing physically in the knot server.

This way, repositories get their own identities, so they behave like other accounts within the ATProto universe. As a result, it’s simple to move them from one Knot server to another and to get updates on all interactions happening about them via the same ATProto firehose that contains all our BlueSky interactions.

Now imagine all the innovation opportunities with your repositories !

Everything is decentralised

As I said earlier, Tangled is the best decentralised alternative to GitHub. Reason being that not only the files but also all metadata related to your repository is decentralised – comments, issues, labels, etc. There is no centralised authority controlling all that metadata, as everything is relayed via the same ATProto. And, once you host your own PDS, then all that data will be with you.

What’s missing

There is only one catch at the moment with Tangled, i.e. lack of private repositories. Tangled could provide the private repo feature as an AppView provider like BlueSky does for direct messages, but I think it’s waiting for ATProto to evolve to support private communication at the protocol level. And that is not far off, as the private data is already in ATProto’s roadmap, there is already a working group, and there are already some prototypes that leverage an upcoming IETF standard on MLSfor end-to-end encrypted DMs.

For the time being, I will set up a separate Gitea or Forgejo instance on the same Knot server for private repositories.

What’s next

I will migrate everything from GitHub and Codeberg slowly and set up mirroring on those platforms so that incoming links to those locations don’t break.

The Unison code will still be in Unison Share, but I have some ideas for an automated plain-text sync of the Unison code to a git repo. More on that later.

Till then, keep vibing 👋