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.
