Nostr Web Client

The registry will have to stay so that we have some common labels that people can use. In theory that list should increase as new labels show up. We just need client and provider to clarify what each label provides so that they can use it correctly. Not defining it would be a mistake IMO.

ManiMe 3w ago

If we don’t need a “single letter” at the tag 0 index (which I assumed we did … to allow searching by relays) then having an arbitrary “context” in this position can still be achieved … using a colon syntax?

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

It’s important to remember that we HAVE NOT landed on a NIP spec for the algo config event, who’s “d” tag MAY BE the “context” string for these TA results. As such nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z , some “standard” type of calculation (like “rank”) useful for clients will likely be configured differently for each user or use case … AND these different configurations MAY each have their own “context” string to identify them. So TA events will prolly need to recognize an arbitrary context string somewhere along the line …?

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 3w ago 💬 2

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.

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

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.

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.