Thats the opposite of what I said. You can use the same data with multiple services at the same time, in fact this is already possible. The whole thing would be kinda pointless otherwise.

Yes, and I’ve been yelling at them about the problem of scaling down for a while, since the same “relay” service needs to be both a firehose and a full mirror. This requirement (and thus scalability) of running a relay is becoming a big problem even for the main devs. According to them however you can mitigate this to a reasonable amount for a home lab (~8 cores, 16gb ram, ~2Tb ssdl) if you simply don’t store any backlog and just retransmit posts https://bsky.app/profile/why.bsky.team/post/3lbjdux6ubc2f

This is what they’re doing internally to manage the load and are also working on implementing relay sharding/scoping to let you just index a small slice of the network, which should eliminate the problem. https://github.com/bluesky-social/atproto/discussions/3036 and here’s someone implementing a proof of concept third party version https://bsky.app/profile/pet.bun.how/post/3lbwnx2rxxs2o

It’s true that the main devs’ priorities are building the large scale parts first and then worrying about downscaling, the whole point was always to replace twitter and work at a similar scale, which requires hard tradeoffs. I do worry that they’ll run out of money before they can do the work to let the ecosystem become sustainable by itself.

But I have faith (for now) because they have people I know from when they worked on secure-ssb and dat protcols, which are truly decentralized but never took off for other reasons.

You don’t need to access information via the relay. You can have a client get information directly from PDSes or Appviews that don’t get their information from the relay.