Posted by icy 15 hours ago
The attacks span from forged DMCA takedowns, to national blocking orders, to suspicion that a contributor is from a sanctioned country (whether they still live there or not), to rogue project admins, and some other more creative attacks.
Project infrastructure should be distributed, with copies of data in as many computers as possible, across as many jurisdictions as possible.
For example, the social features of GitHub, which I like (like stars, browsing repositories by tags etc..)
But also For PRs, the way to make a pull request to a repo hosted at A, from your own node hosted at B.
And like other commenters said, you can do this workflow with git over email like a lot of projects to, but the main goal of the federation here to me is the user experience, the UI being able to link all of theses separate repositories, issues, PRs, etc, like everything was hosted at the same place.
A good system to download and migrate issues and pull requests is important, but that doesn't require federation.
I would love to see a smaller scoped federation of:
- Forks across instances, including for the purpose of PRs (Git)
- Activity feeds and notifications (Activity or ATproto)
- Authentication and some user settings (OAuth)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.
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.
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.
people really do that?
If I'm looking for software/libs/etc, GitHub search is the absolute last thing I would even think to look for.
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.
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.
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.
Beyond that, maybe resilience when a project's host disappears, changes its policies, or gets blocked by a government?
- 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.
We already have the web. The web already has OAuth. OAuth is already widely supported. IndieAuth already offers a very simple and standard approach to personal OAuth servers, if people really want to run their own identity server.
"Feeds" are perfectly doable using the web. It's already pull-based. We don't need another protocol to listen for changes at a URL. The web already has support for different content types and document schemas, we don't need to reimplement content types and schemas as ATProto "lexicons".
Also OAuth only handles auth and permissions and doesn't do anything for provided federated views of disparate data sources.
Also this isn't about identity either, you're really misunderstanding what this is about.
It is very much about identity. To use tangled you need to use ATProto and authenticate using ATProto – rather than using the existing open standard for authentication used by pretty much everyone at this point (missed opportunity to login to Tangled using GitHub). What's crazy is people still use the web to interact with tangled anyway.
It's like records are born to replicate for better or worse. They get downloaded immediately and you have no control over where they go after that. Anybody can tap into one of the firehoses spewing them all over the place. But they're all linked together and if links break it's because nobody kept a copy of that record.
Other file formats don't work quite the same way. A git repo is easy to clone and pull from, but things like call graphs are language-specific.
It seems hard to say what apps this sort of replication is right for.
You can host your git repo on their servers, or your own. You can host issues/pull requests/runners/etc on their servers, or your own. Regardless of where a repo is hosted, you can interact with it from a single account, and with that same account interact with others' repos connected to tangled. Plus it has native jujutsu support, though you can use plain ol' git if you want to, too.
Do I think a forge with those features necessarily needs to use atproto to exist, or that atproto is the ideal version of itself? No, not really. But the site is there, and it has some pretty neat features I want; I don't need to love the stack to use it, any more than I do Github's.
Personally as just a random person in the community I've been building an appview for tangled that lets you interact with it as if you were just using git format-patch + git send-email + some MUA.
You can conceptually treat the tangled lexicon as a schema for encoding a git patchset based mailing list into IPLD/atproto records and vice versa. Doing this is slightly lossy but only barely. Otherwise it's pretty seamless.
Git IS the federation layer in this case.
If I want to create 100 repos of vibe coded projects every month someone will have to pay for it.
At this point, just give me an honest version of GitHub that tells me what things actually cost. 5$ a repo, and another 1 per gb stored in LFS, cool.
Tangle: the appview server of the tangled network.
Knot: the git server that holds an arbitrary quantity of git repos.
Spindle: CI servers/runners/nodes.
Each one is the name of a component and the name for those components is pretty arbitrary.
I find Tangled's language a bit annoying because I'm pretty sure if this caught on it's even more single word concept rather needlessly. If the protocol is called Knot, then call a server a Knot instance or Knot server. If the runner protocol is called Spindle, each server which responds to that could be a Spindle runner. That'll serve two functions: It'll let people contextually hook the terms up against existing terms and still retain the option of evolving into singular word concepts if they prove successful enough for that to happen.
From my point of view as a non-native speaker, the frequent overloading of commonplace words add to the confusion of learning English. I don't like that. It's far from a big hurdle, but just big enough to earn a soft little sigh from me.
Your comment was the only thing that made me even care to comment: Isn't it rather unlikely that the person you're commenting on takes issue with a kink rather than any other reason why "knot" and "spindle" might be poor choices? Who knows, they might even have a good reason, but you started out with assuming bad faith and at least I tend to just leave conversations at that point.
Fixed low cost but different UI: sourcehut.org
Getting my friends to feel comfortable moving ( so they can view the UX ) too will be a challenge.
Spam/moderation is going to be the biggest hurdle to overcome with any distributed forge effort. It'll likely come down to some kind of web-of-trust/vouching system, but it's delicate balancing ease of access with not making it a slog to constantly manage spam.
Discord is not federated.