On that note there's also https://tangled.org built on atproto which (kind of?) solves that. You have one identity (the same one for all atproto apps) which you use to interact with any tangled repository (including those on self-hosted servers).
With its support for self-hosted CI runners it could also be a good alternative for people looking to move now that GitHub has decided to charge for those.
Having one account/sovereign Personal Data Store that can hold many different kinds of data. Then having many different clients and services that are decoupled from the data, offering all kinds of experiences is just night and day better than everything else. For everyone.
You account works everywhere & that's awesome. You also have credible edit & can take your account to a different server without disruption, baked in: amazing win for sovereign computing & digital rights far better than (basically) anything.
People can make cool connected online services, without having to figure out how to host all the data! That's so powerful, so cool (and ActivityPub maybe can decouple someday, but we don't see it yet. The data store and the app go hand in hand, & you end up with an account for each service). It makes it wildly easy to build incredible connected services with fantastically little effort and costs.
That said, I did try to get some of my git repos on https://Tangled.org just today, and alas found that the actual git data needs a "knit" server to do that. And afaik there are are no knot servers I can just use. I'd never seen that complexity for a atproto app before! Usually with something like the book reading social app https://bookhive.buzz or the annotation service https://seams.so , just having your regular account is all the data & service you need. Tangled was a surprising contrast, but I hope to be online there sometime soon-ish!
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?
Blacksky's AppView did get a mention in his 2025 predictions review[1], but perhaps it's not exactly considered "self-sustainable" yet? I haven't kept up with it in a while either so I'm also not sure on whether it is or isn't.
Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow.
I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration.
Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over.
Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.
These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev or https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses.
Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well.
Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here.
I've used sendme a few times after coming across Iroh on Bluesky. It's honestly great. Just Works™, very fast, supports files and folders, resumable transfers, one sender to many receivers, and has fast relays as a fallback when a direct connection truly isn't possible, and it will actually tell you whether you have a direct connection or are using a relay (unlike others like Magic Wormhole or Croc from my experience).
With its support for self-hosted CI runners it could also be a good alternative for people looking to move now that GitHub has decided to charge for those.
reply