Live data from Hacker News

We need a federation of forges

blog.tangled.org

41–50 of 424 posts

Re: We need a federation of forges

#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 feed is empty, and you have to convince other sites to federate with you / not block you for the crime of being a 1 person server / etc.

Am I alone in this feeling or am I just doing federation wrong? (But also this may just be a problem / quirk of Mastodon)

Re: We need a federation of forges

#42

"There are 4 standards that try to solve this problem, its too many, we need one that finally unifies it all and solves the problem once and for all" "There are 5 standards that..." Jokes aside, I think we need stronger arguments as to why something like activity pub is not good enough to solve the problem instead of trying to come up a new way of solving the "decentralized comms" problem.

I dunno man. Why was Tangled able to ship on top of ATProto even prior to getting funded, and ForgeFed has been hanging out for years?

That's become my answer to all "why not ActivityPub?" questions.

AP isn't completely stagnant but there's a reason AT is still holding on to and accelerating that early developer excitement AP had. Maybe it's marketing, maybe it's money, maybe it's some technical thing. Maybe it's the community. Whatever it is, people seem to enjoy developing in the Atmosphere in a way I never saw on AP.

Re: We need a federation of forges

#43

This looks cool but the issue github is dealing with is exponential usage. They're trying to 30x their capacity right now - let that sink in! Microsoft here or there, any company would be struggling under this load. And I frankly don't think that any ideology driven alternative will ever be able to provide better uptime under the same load - or any alternative period, for that matter. We're just living in times where…

I agree that any company would struggle in such case. The thing is that everyone see that GH is pushing for more agents, their Copilot thingy, and AI everywhere, while basic functionality that people relies on is constantly failing.

If you push a lot of new features but your baseline is constantly failing, then something is wrong.

Re: We need a federation of forges

#44

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.

Re: We need a federation of forges

#45

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…

I think the appeal here is you can either self-host or even migrate between larger providers.

The server costs for the frontend should be very low allowing them to operate basically forever and they are fed in by a series of other hosts

Re: We need a federation of forges

#46

Earlier quoted context omitted.

its linked in the original post as well, but here is an explanation of why activitypub is not a good fit for this problem, by the authors of ForgeFed themselves: https://forgefed.org/blog/actor-programming/

Reading that - I'm really not sure that AT Protocol has a much better story there either. (as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.

Yeah the problems they seemed to have were over collaborative data structures with permissions. You’re right about how atproto solves that, which means you’re using CRDTs if you need to collaborate. If that’s a fit mismatch, I’d tell people to just appoint api servers which wrap a repo and provide the needed semantics.

Re: We need a federation of forges

#47

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 infra and accelerate development. We're also incredibly aligned with our investors on our goals (we took 6+ months to find the perfect partner for this).

Re: We need a federation of forges

#48
post #44

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.

Ah ok! Thanks for digging up info that I didn't go looking for myself. That's fantastic news.

Re: We need a federation of forges

#49

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…

This is more a mastodon thing. atproto doesn't really work the same way where every server is it's own semi-isolating zone. This gets into it well: https://atproto.com/articles/atproto-for-distsys-engineers

Re: We need a federation of forges

#50

Earlier quoted context omitted.

its linked in the original post as well, but here is an explanation of why activitypub is not a good fit for this problem, by the authors of ForgeFed themselves: https://forgefed.org/blog/actor-programming/

Reading that - I'm really not sure that AT Protocol has a much better story there either. (as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.

> But federated authorization is one of the things ActivityPub doesn't define, and leaves it to us to figure out.

this is the key bit, atproto has this. sidecar services like knot can use service authentication[0] for authenticated requests.

[0]: https://atproto.com/guides/auth

Post reply on HN