Sandwich

> First, shouldn't tag names should be globally unique across all event kinds I'm not aware of any such limitation, that would mean only 52 one-letter tags for all of...

> Seems like this can be generated client side. E.g., a client which somehow gathers the "top" relays (perhaps by fetching relay list events from NIP-65), and then opens websockets...

I added two new tags to the NIP. - `users` - Total number of users on the relay - `events` - Total number of events on the relay These values...

Assigned `NIP-66`, which as far as I can tell, is not taken. Will update the filename/squash if/when this NIP gets any traction.

@barkyq > Although it would be aesthetically-pleasing if the interpretations were consistent across events kinds At some point in the near future this will be impossible, therefor using unintuitive single...

> as a rule of thumb, when designing protocols, places that people can tack on arbitrary junk data will always have people tacking on arbitrary junk data. this tends to...

> If I try to connect to one of the relays in a d tag, and it is offline, I just drop it and continue to the next kind 30303....

@majestrate > `event.content` fields are not validated by relays, so **should** cannot be **must**. After sleeping on this, the most I could do is "`event.content` fields **should** be empty". The...

> I agree, do we have a way to nudge people towards standardizing extensions? perhaps having a suggested maximum number of non standard extensions advertised at a time, or some...

@barkyq I'm going to be updating the NIP based on what we have discussed. @majestrate I've gotten input and there's nothing blocking a NIP from validating `event.content` is empty, just...