upvote
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.

reply
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.

reply
> If people want to find software, they search GitHub.

people really do that?

reply
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.

reply
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.

reply
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?
reply
if I fork a repository to my forge, I expect my forge to have an independent copy of the repo
reply
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"
reply
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.

reply
deleted
reply
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.
reply
The OP says that tangled only supports event federation. How does it help with discoverability?
reply
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.

reply
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?

reply
How does tangled solve that? Repository contents are still hosted by the forges themselves.
reply
I was addressing the question of a use-case for a "federation of forges". Not any specific design or implementation.
reply
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.
reply
> I'm not familiar with any existing federated system that would be resilient to government censorship.

Usenet and Matrix are notable examples.

reply
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?

reply
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.

reply
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.

reply
In this case the PDS is only storing social data though, right? The forge would still store the repository data itself.
reply
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.

reply