[brw]

I totally agree! This is actually a very good summary of the value prop for atproto honestly. Definitely saving this. ("credible edit" -> "credible exit" I'm assuming.)

It certainly took a while for me to grasp how all the different components in the atproto stack function and work together, but the decoupling actually makes so much sense and I've also become a huge fan of it for all of the reasons you mention. It really feels like a natural extension of Web 2.0 to me.

Re: Tangled

Tangled does actually host a default knot server at https://knot1.tangled.sh. You should be able to select it when you create a repo?

But yes Tangled's component infrastructure is kind of unique. Only the social data (issues, PRs, comments, stars, follows, etc.) is stored in your data repository on your PDS. The git server requires a separate "knot" server.

It's described a bit more in-depth here[1]. As far as I understand it's basically just the git repo hosting part of Tangled's AppView, split off into its own thing to make it possible to self-host it. This means you stay in control of your repo data but also get the benefits of having an actual server with a remote git repo as the authoritative source for the purpose of collaboration, which is what people are generally used to when collaborating using git.

You're probably correct in that the "normal" way would be to have the Tangled AppView act as the git server, but have it store the remote git repo on your PDS. But as records in your PDS data repository are either JSON documents or unstructured blobs I guess it's kind of hard to use that for a git repo, which is largely filesystem dependent. I imagine it would require some kind of translation layer. Or something like git-bundle[2] maybe?

[1] https://wilb.me/3lzyhogtv2s2r

[2] https://git-scm.com/docs/git-bundle