Live data from Hacker News

We need a federation of forges

blog.tangled.org

171–180 of 424 posts

Re: We need a federation of forges

#171

I'm confused on what exactly we need to add to decentralized git to get where we want to be - if it's identities, why aren't we using what git itself supports (gpg keys; if someone has your private key, they are you no matter where )? Or in other words, what specifically does GitHub "do" that can't be done by using git as a backing store?

> gpg keys; if someone has your private key, they are you no matter where how would you rotate such a key and still convince everybody that you are still you? > Or in other words, what specifically does GitHub "do" that can't be done by using git as a backing store? how would you build a social graph of follows/stars and what not using user-owned git repos as a backing store?

GPG key rotation is a known issue with solutions (hint: it involves multiple keys) - https://danielpecos.com/2019/03/30/how-to-rotate-your-openpg...

> how would you build a social graph of follows/stars and what not using user-owned git repos as a backing store?

I'm just spitballing and depending on how you want to display it, you may need more - but if I want to "follow" you I submit a signed commit to your "follow" repository, similar if I'm staring a repo; and then your system issues a signed commit back to my "followed" repo.

Re: We need a federation of forges

#172
post #166
post #108

Earlier quoted context omitted.

The cool thing is you can just host your own knot then. Host repos of whatever size you want.

Man I really want to like this thing but this jargon is so stupid.

The jargon is just naming the free-standing components after rope/string related things. i.e. tangle, knot, spindle, etc.

Re: We need a federation of forges

#173

If only git was a distributed system!

People tend to focus a bit to much on the Git part of Github. Git is already relatively fine. It's nice to have a web view into the repo, users can just clone the repo, but many seems hesitant to do so as if it's some major operation (it can be for large repos, but normally it's not).

The tricky part is the bugtracker and pull-requests. I don't really know how I feel about the Github issue tracker. In theory it's a good way for a community to report and manage bugs, but it's also what's driving maintainers crazy. Previously, in the olden days, you'd send an email to a mailing list and maybe get a reply, maybe got told to show up with a patch or bugger off.

To some extend Github removed to much friction, and while quick drive by patches can be great, they don't build much community.

Re: We need a federation of forges

#174
GitSocial allows cross-forge collaboration without any 3rd party dependencies as it keeps everything in git: https://github.com/gitsocial-org/gitsocial/blob/main/documen...>

Git IS the federation layer in this case.

Re: We need a federation of forges

#175

Forge federation seems like a bad idea to me. If you want to go the route of decentralized project management (note that git as a VCS tool is already decentralized for this purpose), you're probably much better off modernizing the git-over-email workflow instead. Decentralizing the code isn't an issue; cloning repo's between servers is so standard that any forge can import a code repo from any other forge. The diffic…

GitSocial solves this: https://gitsocial.org/

Re: We need a federation of forges

#176
post #174

GitSocial allows cross-forge collaboration without any 3rd party dependencies as it keeps everything in git: https://github.com/gitsocial-org/gitsocial/blob/main/documen... > Git IS the federation layer in this case.

How do you authenticate the identity when people are submitting patches between two repositories running on two different servers?

Re: We need a federation of forges

#177

Forge federation seems like a bad idea to me. If you want to go the route of decentralized project management (note that git as a VCS tool is already decentralized for this purpose), you're probably much better off modernizing the git-over-email workflow instead. Decentralizing the code isn't an issue; cloning repo's between servers is so standard that any forge can import a code repo from any other forge. The diffic…

I had never done the PR-over-email thing until I got an account on SourceHut; it was a bit of a chore to set up, but not that hard, and it did make me feel like it's very clearly the "correct" way of doing things.

Re: We need a federation of forges

#178
post #38

Tangled is VC funded just like initially how GitHub was: https://blog.tangled.org/seed/ It always ends the same way. enshittification. Also: > Bain Capital Crypto is an investor. A crypto VC is invested in this. This is not the solution.

You completely missed the point. The point isn't that you should find a company that you trust and think is ethical. The point is to shift the power dynamics so you don't have to trust anyone. That's what building on ATproto does. Tangled is also fully open source and anyone can host their own knot and AppView.

I don't have a vote on whether ATProto is a good foundation to build such a thing, it seems to me rather that git has quite a bit of relevant machinery inside already, and maybe it might be extended a little, if only by convention.

but your overall point is extremely valid. lurching from garden to garden is just stupid for something so critical and core to the way software is developed. there should be a meaningful core standard for the data (the commits, PRs, workflows, etc). If people want to innovate and change on top of that great.

that's how GitHub started, but they flattered and turned the screws and convinced everyone that using them was the only viable workflow. for that matter can't we revisit the notion of a 'forge', that's really some product marketers version of how things should work and be bundled and charged for, not anything fundamental.

Re: We need a federation of forges

#179

Why? I really don't see the purpose of a federation of git repos. Git is already totally decentralized. 99% of projects only have a small list of committers. Tangled just doesn't solve an actual problem. Github was used because it was an easy to set up, free, place to store code and share it, and it had source viewing which was a step up from sourceforge. With multiple solutions available that makes this easy, its ju…

There’s a lot more to GitHub than just the git part. Issues, PRs, etc.

One approach is to keep it all in git itself, the way GitSocial does: https://gitsocial.org/

Re: We need a federation of forges

#180
post #174

GitSocial allows cross-forge collaboration without any 3rd party dependencies as it keeps everything in git: https://github.com/gitsocial-org/gitsocial/blob/main/documen... > Git IS the federation layer in this case.

How do you authenticate the identity when people are submitting patches between two repositories running on two different servers?

There's a federated identity spec and implementation: https://github.com/gitsocial-org/gitsocial/blob/main/documen.... For GH/GL, just an api call to verify signature, for custom domains, it's .well-known/gitmsg-id.json
Post reply on HN