Comment by spankalee
8 hours ago
It's a huge miss for this article to not talk about atproto, Tangled, and how protocols can solve the fragmentation issues - both between different services and by allowing projects to run their own host while being connected to the network.
With the atproto approach you don't have to worry about reserving usernames specifically for one forge or another - usernames are atproto handles, your Bluesky handle, custom domain, etc.
I'm not sure if Tangled itself is the right incarnation of these ideas, but a protocol for PRs, issues, forks, and activity is the right direction for the industry.
It doesn't even seem to mention federation over/with git and/or ForgeFed (https://forgefed.org/), both efforts predate both atproto and Tangled, and seems like a bigger miss considering the article is literally about git forges.
I think it's great people are working on it, but why reinvent the wheel? Radicle and Forgejo/Forgefed were already under way before starting Tangled. What would be a selling point that would justify breaking compat with existing solutions ? (to be fair, forgefed is largely unimplemented so far)
atproto apparently has some real advantages over ActivityPub in terms of data portability. Similar to Bluesky vs Mastodon, with Mastodon you're fairly strongly coupled to your server, you' can't just move your data and retain all your connections. atproto makes that possible, and that could be really important if you want to say move from a shared forge to a self-hosted one or vice versa.
atproto apps also tend to separate the PDS form the app view, so you can easily use the same data with different front ends.
And, atproto's identity model is much better. Rather than being tied to a server like the data, it's DID-based and you can use it with multiple PDSes.