arthurfranca

Considering #1130 was closed, can we agree with the above usage of `e` and `q`? @staab @vitorpamplona I can open a PR if that's the case

It would be great for privacy if every member of the group would always post with an alias pubkey (although the member list would include the real one). An alias...

> [...] there are challenges in relays actually implementing it [...] @alexgleason Relays already have to deal with indexing array of values like array of `e` tag values. An array...

**If** this NIP-100 gets merged but implementing it isn't a requirement, in practice it may be like if it never existed because no client would be able to rely on...

> Also, as @alexgleason said in the other issue, it's very costly for relays to implement this Disagree or else I wouldn't be supporting this but don't know what DB...

> what is not efficient? To store events that you want locally? You think it's more efficient to load them from relays over and over multiple times every day? "Feed"...

> it just pushes that filter operation to the relay to save on network bandwidth Interesting take. A caveat is it may mess with "limit" filter, like if a client...

Previous discussion regarding contact list at #349 tldr: see "kind X follow (by @vitorpamplona)" section [here](https://github.com/nostr-protocol/nips/pull/349#issuecomment-1472395508)

Most "Relationship Status" lists will have few items so NIP-51 would be enough. Hopefully I expect my unbounded list PR #784 to be at a good enough state to suggest...

So, with my unbounded list proposal (basically the `n` tag and the 33118 kind for "people") it could be like this: ```js { "kind": 33118, "tags": [ ["d", "random6467362966154779"] ["n",...