almost the goal is always to find the optimal (least connections) relays for a given pubkey list. The request are then split based on what we know.
meaning if you do a request with ndk we might split the request and send partial filters to different relays.
The difference in lists vs jit is in the lifecycle.
yes I see, this is something that I considered too. still seems imperfect and non-deterministic. You could still end up in case 1 or 2 of my initial post, though it is an optimisation I agree, the cost of the implementation on the client is still unknown.
To limit bandwidth and ressource usage, I think the best should be to spin up one large request with a set of predetermined relay (that the end user could eventually change on the fly), and have a service on the background, that will run an EOSE request for 10 user at once, and roll it over the entire followlist. It would feed your cache, and forward all missing event to your frontend.
That service could either run on the client, or be hosted as a DVM, or just an API endpoint.
interesting, the parallelisation could be adjusted to tune dublicated data. But I am a bit sceptic of latency, could take quite a while to fetch data for ~200 npubs, right?
