Question regarding NIP-12

[wozuo]

First off: I'm really enjoying exploring the Nostr protocol, amazing work so far! One thing is not entirely clear to me though: What's the rationale behind only allowing tag queries in which there is at least one tag value in common with the filter and event in NIP-12? This prevents filtering for events with a specific tag name in cases where the client doesn't care about the tag value. I can image clients filtering e.g. for all kind 1 events with a reference (tag r) or geohash tag set (tag g). Wouldn't it be useful if clients could filter for events which match the tag name only?

[Giszmo]

I thought this might already be possible by virtue of prefix filtering. Some relays allow as per nip-1 I think to send pubkey prefixes in author queries, so it would make sense to extend that to "#p" tags, making a filter for "#p":[""] work as per your request but I get inconsistent results.

One relay (wss://nostr-pub.wellorder.net) returns no results while another relay (wss://relay.damus.io) gives me:

["NOTICE","ERROR: bad msg: bad message"]
["NOTICE","ERROR: bad req: filter item too small"]

[wozuo]

@Giszmo thanks for your quick response, can confirm! Plus looking at the code of e.g. relayer https://github.com/fiatjaf/relayer/blob/d7750ad15f213687e4bc01da235604e7a8606c6a/storage/postgresql/query.go#L91 the intended behaviour is to ignore queries without tag values

[barkyq]

not so easy, afaict, to implement prefix matching in SQL when there is an unknown length array of strings to consider for each event, unlike pubkey/id which have just a single string for each event. I could be wrong though, not an SQL expert.

[barkyq]

Wouldn't it be useful if clients could filter for events which match the tag name only?

If the intention of the note-writer is to make their event index-able via a specific "topic name", they can just put a ["t", "topic-name"] and then you can filter on that.

If you want to see which events have a specific tag (like e or r), you are out of luck.

[Giszmo]

The tag filters only match the second string and not the others.

The filter "#a":["b"] would match the event with tag ["a", "b", "c"].

[oren-z0]

@Giszmo Where can I find more information about the prefix filtering? Is this standardized?
I was thinking about the geohash tags, and prefix filter is critical for searching in a bounding box with a list of prefixes.

[Giszmo]

https://github.com/nostr-protocol/nips/blob/c74f11b7a921276849f4d0eebc3a90a6a3edf2c1/01.md

[oren-z0]

@Giszmo Ok, it talks only about ids and authors. We also need to extend this for #g tags, for similar reasons:

A prefix match is when the filter string is an exact string prefix of the event value. The use of prefixes allows for more compact filters where a large number of values are queried, and can provide some privacy for clients that may not want to disclose the exact authors or events they are searching for.

Do we need another NIP for that?

[Giszmo]

Yeah, probably. I'm not sure how many of the relays or clients support prefix queries.

[oren-z0]

@Giszmo Geohashes are encoded in base32, so a character like "*" could be used for prefix queries. For example, I could either search exactly "dqcjqcpew" or search a prefix "dqcjqcp*".

This "*"-format could be used as well for other tags that contain base32/base64/hex data, but I think each one should have its own NIP to explain why it is important (indexing irrelevant data for prefix-search might cost the relay operators significantly).

Tags that contain random texts might contain the "*" character, so this requires escaping the character and might not be backward compatible - but this is out of scope for now.