arthurfranca

> I am not sure how that is true. Whatever goes on the #A filter will not be known to the client. You are right that it won't be known...

> 3) [...] I actually think the auth delegation token would be a much cleaner solution for this use case rather than putting the buyers in the event tags @monlovesmango...

Ok, people have spoken. Down with the new serialization scheme! I guess these event authors should publish these events just to relays that implement the (to-be-updated) NIP-42?

> [...] a possible solution is for this NIP not to be recorded in the database, but on disk, the file name being the event id [...] I think I...

> I am not sure why you would do all that. I was trying to figure out what @frbitten suggested when he also said "the file name being the event...

> we'd have to create duplicate kinds for anything we wanted this behavior for @staab @fiatjaf Have you checked how #1033 tries to solve this in some cases? It uses...

@Semisol Yeah the AUTH on connection could be easier but lost its battle to `CLOSED:auth-required` message that does has its merits such as putting an end to the doubt regarding...

The private kind range aligns perfectly well with the `CLOSED` flow. But if we ditch the range, in practice allowing any kind to be private, and, for example, a relay...

I mean, when `CLOSED` message was considered a good solution, there was really just [`kind:4` as private events](https://github.com/nostr-protocol/nips/pull/902#issuecomment-1832282308). Relay could easily figure out if a filter would include private events...

@vitorpamplona Agree, it has its uses. It is just that in all your examples the relay is able to decide to use `CLOSED` or not before running a DB query.