hodlbod

I think this is too strict, requiring some fields based on other ones can't be enforced, and only indicates that in fact new kinds are warranted. But I don't think...

> > requiring some fields based on other ones can't be enforced > > Why not? Clients always have to deal with malformed data, so the fewer constraints the spec...

> Are you referring to the hypothesis of merge the two kinds? Yes, but also if there's a significant difference in what's required for online vs onsite events, that's better...

I think it's a mistake to try to specify an affordance for every use case, because that's how you end up with giant unusable specs. Human-language clarifications can go a...

> In the end I didn't understand, what is your proposal? :) - Remove `type`. - Remove "recommended if type = x" stuff - Rename place to location for backwards...

> Why let the client speculate on a such critical subject, when we can flag it? Clients shouldn't speculate. Instead of guessing, they should say "I don't know". > Then...

What about something like `["anon", nip04.encrypt(ephemeral_sk, recipient_pk, sender_pk)]`? That would be possible with basic nip 04 support, and would only reveal the sender to the recipient.

I like this. It could solve the `ninvite` problem in #1062, and it seems like it could be applied very broadly to limit the spread of events that shouldn't stand...

Do you have something built? I would strongly suggest starting with what nostr nests has and build incrementally from there, rather than creating an entirely separate standard.

> Shouldn't we at least include the namespace in the third position of the tag? eg ["l", "en-US", "ISO-3166-2"] I think it's probably best to just make the mark optional...