#[0] has been trying to communicate this for some time now 🙂
Client apps need smarter “which relay” algos for inbound and outbound.
#[1]
Discussion
We might need to rewrite a lot of NIPs to actually communicate the idea.
Maybe we can start with Nostr Client App anti-patterns.
Nostr client app Anti-patterns
* Updating a subscription too often (triggers new SQL queries)
* Connecting to a relay multiple times (use a single websocket)
* How can we best manage this with multiple open web app tabs?
* Opening a websocket and not creating at least one subscription
* If you disconnect from a relay, don't instantly reconnect (add random wait)
* Gracefully disconnect (helps servers free descriptors faster for new connections)
* Overlapping subscription queries (you'll get dupe data - from each relay)
* Using Until and updating the subscription's until every x seconds/minutes (if you didn't use until and just used client logic to show events, you wouldn't trigger a server query and just stream the data instead)
* Using the same relay list for home feeds, global, general queries, DMs, notifications, etc
Great list!
Suggestion:
- use randomized _increasing_ intervals after each failed connect
Question:
- "using Until and updating the subscription's until every x seconds/minutes" - you mean don't scan the relay using older and older 'until' filter, making many requests one after another?
Damus already is kinda doing this with per-view filters, so yeah I mostly agree, but I don't think it needs to be codified anywhere. I think the flexibility to try different relay models is fine. I have no issue with fixed or not, it really depends on the application.