this is for the case of propagating that "opinion"
nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq8kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sksrfanak is talking about a proprietary, internal thing that he is charging access to
just pointing this out, the tags i mentioned were FILTER tag fields, both filters and events have them, remember?
Yeah this conversation has gotten to be way too complicated. We are all talking about different things.
I fixed the nostr.wine issue try now. Apparently I broke one mirror during a restart earlier today :(
i was never unclear that i meant FILTER tags, you just didn't catch it
that's something you can easily add to a random new NIP that augments NIP-1
the internal tagging system is internal, it's irrelevant, except that it relates to the clients requesting it, so it's FILTER tags not EVENT tags
My understanding of NIP-01 is that filter tags are meant to relate directly to event tags - that’s why there is confusion.
ok, that makes sense but ultimately filters are just a query API and nothing says they cannot extend beyond simple matching if the database can do that
this will simplify your code a lot if it's just a small extension of tags instead of the whole REQ, simpler to adopt or reject, or ignore... it won't match, obviously, for relays that don't understand it, i'm not sure what that behaviour is though
that is an issue that needs to be figured out then i guess
the naive, intuitive sense of it is that filters are queries and thus they need to be more flexible than the data they relate to
