Comment by nightpool
19 hours ago
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
2 replies →
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.
3 replies →
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.