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.
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.
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.
We've already explained to you twice that this is incorrect, you don't need to do this. And that if you do want to do this for some ridiculous reason, just because, a $5 VPS can do it.
But you do acknowledge latter you are only talking about tangled records.
Currently very few people are worried about this problem, because all of the tangled traffic just isn't that big, and you can drop most of it very quickly with little impact. Relays do allow various kinds of filters though. You could use a service like Microcosm Constellation https://constellation.microcosm.blue/ that lets you find only records for your repos etc. That would work fine for finding the records pertinent to you!
No one does this right now, because the premise is faulty. There just really isn't any difficulty or cost of any note to having all the tangled records piped at you. Hopefully some day this gets worse, and that this becomes a good problem to have! One we already have tools (like constellation) to tackle.
In short: constellation is a (also easy to self host cheap light weight) service for reverse indexing, for finding records pertinent to you. Lots and lots of atproto apps use this for this kind of "find people making records about my stuff".
A ridiculous reason, such as being able to interact with the federated world from my own server directly, and not through a third-party service. Why is the simple concept of going to your own server to interact with the entire network, getting content directly from your friends' servers, and receiving interactions (e.g. PRs) directly from someone else's server such an afterthought in ATProto?
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.
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: