Another slightly more involved heuristic. Assuming that, for a given npub, all outbox relays contain all user notes (a strong and likely incorrect assumption, but useful for optimization), you can write a reasonable "greedy" relay selection algo as follows:
Create a Map
> and prioritize (working) relays that are common to most "uncovered" users (this can get more complex if you want to compute a minimum set, but a greedy heuristic is good enough). This works well for general things like the following timeline as it minimizes the number of relays you need to connect to. For less general tasks, such as when someone clicks to view a specific profile, you can open a separate pool containing only the user's outbox relays to catch any notes that might not have made it to the "general" pool. "Borrow" existing open connections from the general pool so that you don’t keep reconnecting to the same relays. At least with go-nostr this is working quite well. I'm not sure if things are much different with Kotlin libraries and mobile devices/ Android resource limitations.
@ Anthony Accioly
2025-06-05 23:50:27Another slightly more involved heuristic. Assuming that, for a given npub, all outbox relays contain all user notes (a strong and likely incorrect assumption, but useful for optimization), you can write a reasonable "greedy" relay selection algo as follows: Create a Map