Replying to Avatar Vitor Pamplona

It's fine if they all have different calculations to estimate rank. Apps will use whatever users want as "rank". Basically different signing keys for TAs can have different behaviors but they will all be used in the same way by the client.

What clients need to know is that rank is the score of the user, and "followers" is the follower count in whatever way that provider defines it.

It's kinda similar to DVMs. The NIP defines a contract between client and provider but after that the provider can do whatever it wants.
Avatar
ManiMe 3w ago

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:”, “”, “”]

Reply to this note

Please Login to reply.

Discussion

Avatar
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.

Avatar
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.