For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.

▲

LelouBil 4 hours ago | parent | next [-]

ATProto is the right protocol for the social elements imo

	▲	verdverm 3 hours ago \| parent [-]
		Having worked on it for a while, I now disagree. The permission primitives should be baked in from the start rather than the bolted on after spaces because people continued to ask for these things and eventually Bluesky came around. There are many use cases for permissioned data and experiences that have to be built outside of the protocol, leading to fragmentation and loss of interoperability.

▲

jauntywundrkind 3 hours ago | parent | prev [-]

> For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.

Huh that's surprising to hear? What makes you think that? It feels like the whole point of this release is to make it easier to allow people to self host or federate whatever parts they want? That's what I got from their intro/opener!:

> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.

> Tangled aims to give you the best of both: the longevity of an open protocol, with the convenience and polish of a proper forge.

> It’s the first truly federated code forge — you can host code on your own servers and still collaborate seamlessly with others. Our approach is pragmatic: self-host just the parts you want, like Git hosting or CI runners, or all of it, including the API server and UI. Whatever you choose, you can still talk to everyone else.

The comment here from @icy emphasizes similar ability to let whomever host whatever parts of this they please:

> Hi! Tangled co-founder here. We're super stoked with this launch -- we've stabilized our AT Protocol lexicons, completely overhauled our architecture and UI, and made self-hosting the entire stack (or parts of it!) https://news.ycombinator.com/item?id=50306205

I don't see any mention of "their struggles around scaling centralized infrastructure". Is that just typical run of the mill low grade slander attack we see against atproto, more reflexive negativity? Or is there some actual interesting point here, that is perhaps even relevant to this tangled release?

▲

max-privatevoid 2 hours ago | parent [-]

They had the mostly-centralized offering up immediately, and now they're spending a lot of time making the parts easier to self-host one by one. What does that say about the protocol? And I assume Tangled also suffers from the general ATProto AppView problem, where your AppView has to consume all the content in the entire network even though 99% of it is likely uninteresting to you.

Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.

▲

icy 2 hours ago | parent | next [-]

I think you fundamentally misunderstand how the protocol works.

First, Tangled has been entirely self-hostable since the beginning! We've just made it much easier to run for everyone.

Second, the "appview" is simply an indexer. It consumes records from the firehose and only those that it cares about. In our case, those are org.tangled.*. There's no reason we'd consume all of the firehose.

ActivityPub categorically does not make sense here because of how coupled identities are to instances.

	▲	max-privatevoid an hour ago \| parent [-]
		> Tangled has been entirely self-hostable since the beginning! As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case. > In our case, those are org.tangled.*. I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct? > ActivityPub categorically does not make sense here because of how coupled identities are to instances. I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.

▲

jauntywundrkind 2 hours ago | parent | prev [-]

You already could host either the web app, the knot (the repo), or the spindle (the runner) yourself, they were just harder to run yourself. I think it says a lot of good things that you can one by one pick which pieces of the system you want to host where!

It is a social network so I'm not sure what the issue about yes needing to read the network is. There are really good relays designed to help aggregate and filter the network. They can run on $5 VPS, processing the entire network, which is awesomely cheap, not just Tangled, which is awesome, what I would call a huge win. Paul has a talk on designing for scalability, about how it's possible to have such small boxes doing the network aggregation with so little resources, that appviews can then consume their interests from. solving for scale in open social networks, https://youtu.be/BoJnj2yPf14

The servers are definitely not keeping the whole network. The post talks to this some, but the new Knot2 retains a local copy of repo-relevant material (comments prs etc) in its own git tree, that collects what the network has done together, and makes it easy to ship/replicate, while also using that as a sync source to replicate back into atproto too, to make network visible.

Agreed that I really wish ForgeFed were showing much more clear progress. It seems like such a good idea, but it's been a number of years now and it's super murky what the progress is and where we are. Having >1 viable player in the decentralization of forges would be great. I haven't checked in a bit but I do read Forgejo release notes and my impression is it's been a very slow trickle.

	▲	max-privatevoid 39 minutes ago \| parent \| next [-]
		When you say "they can run on a $5 VPS", do you mean that the entire server will be dedicated exclusively to processing ATProto data? I run an ActivityPub server on my $5 VPS that allows me to interact with everyone else on ActivityPub, and that VPS is hosting a lot more services than just that.
	▲	rapnie 2 hours ago \| parent \| prev [-]
		> Having >1 viable player in the decentralization of forges would be great. There are other projects other than Forgejo implementing ForgeFed. Forgejo itself has some federation support but AFAIK not based on ForgeFed. But they have a community contrib project that does. - https://codeberg.org/forgejo-contrib/federation - https://codeberg.org/activitypub-rs/activityforge - https://frogue.vit.am/~ololduck/Frogue Gitlab has a community epic to add ActivityPub support, but that needs contributors: - https://gitlab.com/groups/gitlab-org/-/work_items/11247