31–40 of 57 posts
I'm way more hopeful in a fully decentralized protocol like Forgefed* than some AT still-centralized thing. * https://forgefed.org/
Cool. It's been years since ForgeFed came out but it isn't anywhere nearly as federated as Tangled is. What gives?
It will likely require some grant money to become usable.
Anyone remember that? It used to be such an important website and went down the tubes.
I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
To me being VC funded is the opposite to "structurally resistant to the lock-in". I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
> I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
Then you should avoid and steer very clear of Tangled since it is VC funded and crypto VCs are invested in this forge.
The direction here can change at any time, and is more likely to enshittify than the others.
It seems ironic, that in the social media space, AT protocol based instances are basically centralised (Bluesky) and ActivityPub based instances (Fediverse, Mastodon) have a much healthier grade of federation. Whereas in the "forges" space, it seems Tangled drives federation forward much faster than the ActivityPub-based federation features of Forgejo/Gitea (which are progressing really slow).
That might just be your observation bias. I have not seen any Tangled instances in the wild.
Everybody is moving either to codeberg or more likely forgejo instance.
I personally just self-host. The project that I'm working on right now uses Gitea internally with an action runner. I use Digital Ocean and run a Nomad cluster on top of that. Gitea and its action runner builds container images and then pushes nomad job definitions to the cluster. I have zero downtime deployment and rolling deploys. Dagger.io is in there somewhere to make local CI mirror what happens in the action ru…
A project’s issues and pull requests are only useful for that project.
The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
In fact, the tiny barrier of entry for contributing in a new forge might be a desirable quality, to filter out low-effort contributions.
Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).
That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.
I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges? A project’s issues and pull requests are only useful for that project. The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, as…
I don't think that's always true. A bug in library A might be referenced in project B with a fix in fork C.
Yes, a hyperlink works to show you where to find info. But it doesn't alert you when a PR on C is merged by A meaning that B is now unblocked.