I'm a huge supporter of federation, but I've never understood the use-case for a "federation of forges". What data are the forges exchanging? Why should the forge for Blender have any connection to the forge for Ubuntu?
Most of the value I get from Github is having a single login that I can take from project to project. Independent forges can get the same value simply by supporting social login, without needing the complexity of a "forge federation" system.
If people want to find software, they search GitHub. If you self-host a forge, no one will ever find your software unless you’re a preestablished big name (like Blender). To avoid throwing your code into the void, you’re pretty much forced to mirror with GitHub, at least.
To avoid this and make smaller forges as a block a viable competitor, there needs to be a singular network that solves discoverability and lets you find software from any host – like ForgeFed would.
There’s also the concern with the friction created by requiring newbies to log-into a dedicated forge for contributions (which ForgeFed solves), but I reckon that’s a secondary and related concern.
This is an indexing problem, not a federation problem. Personally, if I want to find software, I use Google, Rubygems, or NPM. Github is a distant third option. But this project is about data interchange between forges. It doesn't solve the indexing / discoverability problem.
Having a better code search crawler that can grab data from independent git repos would be really cool. But being able to submit a PR from server 1 to server 2 is pretty unrelated to that.
> If people want to find software, they search GitHub.
people really do that?
The only time I ever search GitHub is when I'm trying to debug or understand some esoteric API (usually Apple-specific) and I'm looking for anybody else who has actually used the god damned thing.
If I'm looking for software/libs/etc, GitHub search is the absolute last thing I would even think to look for.
Git is decentralized by design. It can support federation, it just happens that GitHub solved the UI, issues, PR so that even new comer can come in and do git stuff and track issues on the screen. But centralized it.
Federation would be closer to git, but not so decentralized that when one node goes offline you may not have any upstream to pull from, or not be able to find them.
Git doesn't solve availability. Federation may solve it, by staying closer to the decentralized philosophy. That's my read.
Not sure I understand, you're talking about mirroring git repo data between multiple different nodes? That seems unrelated to what's proposed in the OP--maybe you're seeing something I'm not?
if I fork a repository to my forge, I expect my forge to have an independent copy of the repo
How does that fix "when one node goes offline you may not have any upstream to pull from"? You'd still have your own local copy—just like git—but you wouldn't be able to access any sense of "upstream"
By hosting a knot.
You may ask, well, that's like hosting forgejo or any other git server, where is the federation?
Tangled uses a protocol. So knots would adhere to that protocol allowing to pull from any upstream.
That's my understanding of federation. not saying tangled will go as far as figuring out discovery across their cloud hosted knots and self hosted infra. But that can be done, and claiming to be able to pulling from any repo with a single identy would imply just that.
The biggest problem IMO is discoverability. I need an easy way to find open source projects that are on scattered servers. GitHub project search is limited to GitHub.
The OP says that tangled only supports event federation. How does it help with discoverability?
Events in atproto speak are changes to metadata/records, i.e. repo/MST events on a PDS.
So for tangled that means federation of issues, PRs, comments, follows, stars, and anything defined in an atproto lexicon. i.e. everything except the actual git repo itself. Those repos are singularly hosted on a given knot for the time being.
Now it's not a huge leap to imagine extending functionality to support cross-knot mirrors but that's not a supported feature yet. And of course you can always just fork a repo instead.
Interoperable identity providers would indeed be useful.
Beyond that, maybe resilience when a project's host disappears, changes its policies, or gets blocked by a government?
How does tangled solve that? Repository contents are still hosted by the forges themselves.
I was addressing the question of a use-case for a "federation of forges". Not any specific design or implementation.
That sounds more like you want better decentralization, like IPFS or BitTorrent, not necessarily federation between different forge instances. I'm not familiar with any existing federated system that would be resilient to government censorship. Certainly Mastodon and Bluesky aren't.
> I'm not familiar with any existing federated system that would be resilient to government censorship.
Usenet and Matrix are notable examples.
Usenet is, Matrix isn't. Usenet achieves this with a broadcast design - every node on the network receives every message. As a result of this and being flooded with half a petabyte of new messages per day, there are approximately 3 (three) nodes (all other providers are reselling access to one of these).
The text side of Usenet is healthier, with a few gigabytes per day, and not trying to retain every message forever. Would it work if it was also the world's git forge though?
Github is already in practice federated, within the confines of github. If you fork a project you now have your own federated git forge with that project.
The difference is that these same flows should work without needing to be github to github.
In this case the benefit would be:
- your data lives in one place, your Personal Data Server (PDS). You can self-host this if you like - The AppView (in this case, tangled.org) aggregates the data from many PDS's into one view. - If tangled.org enshittifies, you can do all the same things from any other AppView -- tangled.org itself is not privileged in any way.
Social logins on independent forges help, but personally I'd rather have a single account to manage -- and the AT protocol means that any individual forge can go down, but the data remains accessible from other AppViews.
In this case the PDS is only storing social data though, right? The forge would still store the repository data itself.
Aha, I was mistaken -- I was under the impression that repos were also stored on the PDS.
Looks like that's where knots come in -- you could replace "PDS" with "PDS and knot" in my earlier comment and it holds true, I believe.