We might need to rewrite a lot of NIPs to actually communicate the idea.
Discussion
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?
Where on the NIPs is the idea that clients are supposed to use static relay lists? To me NIPs 2, 10, 19, 65 all hint to the fact that clients need to be smarter than just using static relay lists.
I would work to get rid of read/write classifiers for relays because they override the thinking that a view or the spec of a given feature (say public chats or private messages) override nip02 and NIP65 classifiers.
No relay is read or write without additional context of where is being used.
The kind 3 relay lists were a mistake from me made in name of getting things working, but that was never specified in any NIP.
The meaning of "read" and "write" in NIP-65 is different though (where is that diagram, #[0]?), although I agree it is confusing. It would have been better to call it "inbox" and "outbox" or something like that as #[1] suggested.
While waiting for #[3] to publish the final version, here's the not-final one:
Here: #[0]
(Not the final version anyway)
I also found the terminology a bit confusing at first too. Maybe "inbox/outbox" can work better, but I don't see a big difference in the end, each term is a bridge to "read/write" which is the actual actions.
Yeah I think inbox and outbox are much more understandable. I wish I had thought of them sooner.
Why not update the NIP? Its still marked as draft, so can be changed where necessary.
I have no problem with a PR to update the NIP. But if we change the contents of kind-10002 to say 'inbox' and 'outbox', how many existing implementations will that break? Normally we don't break anything. We could suggest backwards compatibility in that 'read' means 'inbox' and 'write' means 'outbox', but in that case clients that don't do that will not understand these new fields will fail to get the data they used to get. I think it is more important to not break existing stuff. NIP-65 already explains what 'read' and 'write' mean, and I updated those explanations to be even more clear, so at this point the way forward is to just spread the message.
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.