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?
You can host your own data very cheaply. If you don't have to serve every single other server, and keep them all up to date, and can just pump some records out at aggregating relays, it makes it much easier for people to be online. You can run a massive PDS on a tiny ancient rpi.
Which is what activitypub doesn't do. It's protocols are very heavy and hard and stateful. Running mastadon or other servers requires peering with every other related server. And it's on you to deliver messages, to push, to track state and progress. All the network work is on you to get your message out. So your server with your data has a ton of work to do. This doesn't scale well. See again Paul's scaling with open social.
If you do want to run your own atproto services, yes, you need to pull from the network to see what is relevant, you need a relay server, you need a pull. And you can! Running those relays is very cheap! The protocols scale really well & is super well optimized to be efficient to do! You can just do it!
The one particular thing you keep trying to demand is what makes AP so hard, so difficult, and scale so very badly. It's the worst part of activitypub, it makes it super hard and super expensive. Switching from AP push model to the relay doing pull model is the secret sauce that makes everything super lightweight and scalable, and that makes sync so much easier.