Nostr Web Client

So … the question is :

Can “multi letter key tags” be included in REQ filters and relay search results?

The NIP01 “convention” states that “all single-letter key tags are expected to be indexed by relays” and that “Only the first value in any given tag is indexed.”. I expect that relays MAY move beyond the first convention IF there is a REALLY good reason AND a clear path to do so.

If the answer is yes (which you seem to think it is?) … then i think this 👇 is the better solution that allows both “indexable” AND “arbitrary” tag keys … with an additional string as the last tag value to help communicate the result schema info.

[“wot:”, “”, “”]

Vitor Pamplona 3w ago 💬 1

What is the "wot:" doing? Couldn't it just be context?

But yes, the single letter is just indexed. In theory, all tag names should be searchable. I havent checked support for it though.

I was thinking on doing indexes for the presence of things in a similar way NIP-32 does with namespaces.

We would just do ["rank", "90"] and then a ["w", "rank"] if the goal is to search of all records that have rank.

We could also do multiple precisios, like geohashes, ["rank", "9x"] to download all 90s ranks.

Reply to this note

Please Login to reply.

Discussion

ManiMe 3w ago

That's a good idea. But we'd also like to be able to search by result value as well as context string. A good solution may be something like this:

["w", "", ""]

["v", ""]

Where "context" MAY be any arbitrary string, but the nip may also specify some useful "conventions". And every "w" tag SHOULD be followed by a "v" tag, which MAY contain any arbitrary (JSON safe) string. This allows BOTH context and result to be indexed.