Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need a federation of forges

blog.tangled.org

Post reply on HN
Print view View original

131–140 of 424 posts

Re: We need a federation of forges

#131

Post by 332451b »

ecshafer wrote: post #90
varun_ch wrote: post #86

Earlier quoted context omitted.

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

Why does issues and prs need to be federated? I can't think of any part of Github that benefits from federation. Just set up your own instance.

I think initiatives for forge federation are trying to do too much. When running a forge for a project, I'd don't want to be dealing with spam or large amounts of data from other instances. And people should be able to report bugs and upload attachments, without having to give permission to share those with other instances.

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)

Re: We need a federation of forges

#133

Post by embedding-shape »

willio58 wrote: post #64

Lots of negativity in the comments and while I'm as distrusting of VC funding as the next guy I think competition in this space is something we should encourage, and bootstrapping that is hard if not impossible at this point. Obviously this post was timed well with the 2-3 GitHub-hating posts that made it to the top of HN yesterday, but I commend the attempt here. I hope it takes off in a meaningful way.

> and bootstrapping that is hard if not impossible at this point.

What points towards bootstraping being impossible? Sure, it's difficult, that's almost in the name so makes sense, but impossible? Especially if you're aiming for the federation-angle, then you should be able to build cheaper infrastructure, not the same/more expensive.

Re: We need a federation of forges

#134

Post by class4behavior »

knotbin wrote: post #44
madamelic wrote: post #41

The problem I feel with federated solutions is basically the 'cold start' problem. When you are wanting to join a federated network, you have two choices: join a pre-existing server thereby creating the exact same problem you are escaping, ie: a giant server that holds you to its whims, BUT you do get a big network to begin with. Or you start your own server but your network is zero, discoverability is zero, your fee…

Yeah that's why Tangled didn't go with ActivityPub (Mastodon protocol) and went with ATproto instead, which is specifically built to solve that problem, so individual servers are all aggregated by centralized AppViews (that anyone can host) that give a singular unified "view" of the network that is just as cohesive as a centralized network feels.

ATProto simply ignores the need for decentralizing incentives on a human/community level. What we get is a sort of a "top-down" federation rather than a grass-roots one. Whoever invests in the infra ends up running a domain.

I mean, practically no one is aware of any other ATPROTO provider other than Bluesky whereas the issue with AP is merely the lack of better implementations, so mastodon.social got the most attention and the hype died off with niche success.

Re: We need a federation of forges

#135

Post by embedding-shape »

tired_star_nrg wrote: post #132
Croaky wrote: post #129

I'm hesitant to build anything load-bearing on AT Protocol given its PQ exposure: https://words.filippo.io/crqc-timeline/

How does this impact AT Protocol? I’m just hearing about AT now, so I’m not familiar

Today, not so much. But once the day is here where we have CRQC, if ATProto hasn't yet started using post-quantum cryptography for identities, users are either vulnerable or a bunch of stuff will break once they push a hotfix to make users not vulnerable.

Alternatively, they fix these things now, so once CRQC arrives, it's already not a problem, and no gets compromised nor have to urgently update their software.

Re: We need a federation of forges

#136

Post by embedding-shape »

short_sells_poo wrote: post #15

Slight tangent: the post says that github is crumbling. Can someone get me up to date on what's going on please? Admittedly I'm not following tech drama particularly closely, but I thought I'd have heard if a major thing like github was going down the chute.

> but I thought I'd have heard if a major thing like github was going down the chute.

Wow, it was a really long time ago it started going down the lane of the chute, can't believe someone missed it, made big news at the time back in 2018! This was the turning point: https://news.ycombinator.com/item?id=17221527

Re: We need a federation of forges

#137

Post by nonbinary-cpu »

horsawlarway wrote: post #95
whereistejas wrote: post #2

tangled is a really cool project; the most important feature it provides is that it is jujutsu first.

I don't really see it. I used JJ for a bit, but I personally really, really dislike the anonymous branch approach it forces you into. Branches are just useful conceptually, at least to me. For the same reason I like my documents grouped into folders. Frankly - I think JJ just ended up taking up far more mental bandwidth than git. Simple operations need generated ids, commands require complicated input (ex - the entir…

i mean i can throw a million cryptic git commands at you, too (jj revsets can be arcane, but they're also fairly well-documented and the names are fairly descriptive). git's gotten a lot of usability features over the years, but there's still a ton of stuff that's just confusing. jj ends up being a lot more intuitive in practice IMO, though the anon branch thing does take some getting used to. there's a lot more i'm comfortable doing in jj, without that 'defusing a bomb' feeling complex git operations often had for me.

Re: We need a federation of forges

#138

Post by ori_b »

icy wrote: post #47
code-blooded wrote: post #36

Tangled is VC sponsored. It doesn't scream stability to me, but rather "we need to grow at all cost". I don't see the appeal. Even though it's federated, when development stops, who will be there to fix bugs and maintain it?

Tangled is built entirely in the open: https://tangled.org/tangled.org/core , and our primary goal is to be "permanent software"—i.e. be fully reproducible and entirely self-hostable at minimal cost. VC money is a means to an end. We're both Indian founders in Europe, and grants are nigh on impossible to find (4–12+ months for anything to materialize). VC is quite simply the quickest way for us to build a team, setup…

What does your investor expect as far as returns, and how are they going to get it?

Re: We need a federation of forges

#139

Post by phreeza »

icy wrote: post #47
code-blooded wrote: post #36

Tangled is VC sponsored. It doesn't scream stability to me, but rather "we need to grow at all cost". I don't see the appeal. Even though it's federated, when development stops, who will be there to fix bugs and maintain it?

Tangled is built entirely in the open: https://tangled.org/tangled.org/core , and our primary goal is to be "permanent software"—i.e. be fully reproducible and entirely self-hostable at minimal cost. VC money is a means to an end. We're both Indian founders in Europe, and grants are nigh on impossible to find (4–12+ months for anything to materialize). VC is quite simply the quickest way for us to build a team, setup…

Would you be open to sharing a version of your pitch deck? The main question in my mind is what kind of exit the VCs have in mind when they give you this money.

Re: We need a federation of forges

#140

Post by 0xbadcafebee »

I'm sorry but I will never use this. I don't want a federated protocol and I absolutely do not want "social". The Git protocol is enough to distribute my source code to any Git server, so that part is complete. What I need, in addition and separate from Git, is a standard API schema for all the other SDLC bits: CI/CD, PRs, Issues, Packages, Containers, Branch Protection, etc. The API should not be a specific transport implementation, like HTTP, or AT. It should merely describe the schema, and then you implement that schema on anything else.

"createIssue(title=string, body=string, labels=[string])" would be the same in Git's source code as it would be on a REST API server. The point of this is to standardize the software development lifecycle everyone uses around Git. That way you can do all the work we all need, with any VCS, without tight coupling. That's been the missing piece that nobody has made yet.

Want just the CI/CD component? Use that part of the schema. Want just the Issues? Use that part of the schema. Now you can write any tool you want, and just implement the features you want, and say "this follows the SDLC v1 CICD standard", or "the follows the SDLC v1 Issues standard". Much simpler to add extensions or support different use cases, without implementing everything you don't need. Yet everything's compatible.

We need that implementation-agnostic standard, so we can make transport-agnostic protocols, so different providers, clients, and servers can all talk to each other, without a hundred different bespoke "things". Rather than write your plugin-downloading app only against GitHub or against Federated-Whatever, you write it to use "httpSLDCs://some-server/v1". Don't want to use https? Use "grpcSDLC://some-server/v1", or "atSLDC://some-server/v1". You layer the application-specific protocol on top of the transport protocol, and express that in a URL. That's how we did 'federation' in the 80's/90's/2000's.

(also: did nobody come up with a better name? Tangled? Knot? you want your solution to be a tangled knot?!)

Post reply on HN