PABLOF7z on Nostr: I haven’t read it yet; just skimmed thought it because it’s pretty long. Initial ...
I haven’t read it yet; just skimmed thought it because it’s pretty long. Initial piece of feedback:
I would seriously remove EVERYTHING that is not strictly needed to define the scheme, like the section about “clients should be multilingual”, “clients should have a nice UX”, the problem rationale at the beginning (everybody that’s been in nostr knows all this);
reading the proposal without all the extra padding makes for a MUCH better reading experience and leads to fewer misunderstandings (this applies to all writing really)
That said, I saw some mentions of “relays must X…” - any changes to relays must be extremely scrutinized; relays normally don’t need to inspect events beyond the signature, so having them have to keep some sort of state with guarantees is a very bad thing and should be avoided as much as possible.
Ok, I’ll actually read the thing later and give some more concrete feedback 🤙
I would seriously remove EVERYTHING that is not strictly needed to define the scheme, like the section about “clients should be multilingual”, “clients should have a nice UX”, the problem rationale at the beginning (everybody that’s been in nostr knows all this);
reading the proposal without all the extra padding makes for a MUCH better reading experience and leads to fewer misunderstandings (this applies to all writing really)
That said, I saw some mentions of “relays must X…” - any changes to relays must be extremely scrutinized; relays normally don’t need to inspect events beyond the signature, so having them have to keep some sort of state with guarantees is a very bad thing and should be avoided as much as possible.
Ok, I’ll actually read the thing later and give some more concrete feedback 🤙