nips
nips copied to clipboard
nostr-protocol
add nip 23: relays list.
For sharing relays lists between clients in a reasonable and extensible manner.
https://github.com/nostr-protocol/nips/blob/26-relays-list/26.md
So is this meant to help with sharding later on? This relay for kinds x to y, this relay for nwiki, ... ? But any pubkey could advertise any such list of relays and their limitations? What should clients do with those? They will not be consistent between different pubkeys and who would share them based on what? Based on relays self-reported filters?
I see this nip as benign but don't see the benefit yet.
I see this nip as benign but don't see the benefit yet.
@Giszmo There's currently no NIP specifying how a client should store a list of relays. Branle stores the list of relays in the content field of kind 3 events but that's not covered in NIP-02. This NIP fixes that.
I find the rules quite complex and doubt many clients will implement all of it. I agree with @Cameri to not use #. (I don't agree with dropping ! and adding ^.)
In general it's an ACK from me. Clients that are confused will figure out what to do with the list of relays either way.
^ is already part of the runes-like spec and means starts with or begins with. It can be skipped for now since adding support for it won't break existing rules. I think it is fine to implement a subset, just what we need. But our usage of # and ! are not part of the original runes-like spec and would make it non-compliant for whatever it's worth, breaking compatibility with existing libraries. Anyone wanting to implement this NIP will have no choice but to implement the custom spec, not a hard problem true, but they could have just leveraged the existing python library for example. Either way this not a deal breaker for me but I don't find it ideal. ------- Original Message ------- On Sunday, August 14th, 2022 at 12:07 AM, Leo Wandersleb @.***> wrote:
I find the rules quite complex and doubt many clients will implement all of it. I agree with @.***(https://github.com/Cameri) to not use #. (I don't agree with dropping ! and adding ^.)
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Hello everyone. This spec is interesting(but complex, at least to me). Though I have partially understood, thanks to the examples used, and the event structure, I fail to understand the use of evaluation criteria in the examples(where conditions such as pubkey=(a value), etc are determined). How are they used? Let us imagine a scenario between 2 Nostr users. One person shares the list. Does the other person get the list with the values defined, or with the evaluation criteria? Thanks.
The first use case is meant to make it so users can open their client -- or different clients -- in different devices and have their list of relays automatically fetched from a default relay and start using their relays list without having to set everything up again.
isn't this is what the contents of kind3 is for?
The first use case is meant to make it so users can open their client -- or different clients -- in different devices and have their list of relays automatically fetched from a default relay and start using their relays list without having to set everything up again.
isn't this is what the contents of kind3 is for?
well, that was a rogue undocumented implementation in Branle, we kinda discussed this in the chat group that a new NIP dedicated for relays would be better.
Branle is now implementing a draft of this proposal that only recognizes empty strings as true.
On Sat, Aug 13, 2022 at 08:20:18PM -0700, Ricardo Arturo Cabral Mejía wrote:
I see this nip as benign but don't see the benefit yet.
@.*** There's currently no NIP specifying how a client should store a list of relays. Branle stores the list of relays in the content field of kind 3 events but that's not covered in NIP-02. This NIP fixes that.
I see the benefit of a spec as a standardization of nip-3 content but I'm not exactly sure what I would do with the rules as a client.
On Sat, Aug 13, 2022 at 08:20:18PM -0700, Ricardo Arturo Cabral Mejía wrote:
I see this nip as benign but don't see the benefit yet.
@.*** There's currently no NIP specifying how a client should store a list of relays. Branle stores the list of relays in the
contentfield of kind 3 events but that's not covered in NIP-02. This NIP fixes that.I see the benefit of a spec as a standardization of nip-3 content but I'm not exactly sure what I would do with the rules as a client.
Instead of clients blasting events to all relays the write rule lets users choose which relays to send to per event basis. Instead of subscribing to all relays with the same filters, the read rule lets users choose which relays can be subscribed to (the filter must match the read rule).