Nostr Web Client

Ok that's more clear, thanks for explaining. "Type" really nails it, Schema may be good too, either would be a more concise label for the tag than categories.

Discoverability is a good argument for `w`, I'm sold.

Nice work 👍

Vitor Pamplona 3w ago 💬 2

What is the discoverability gain? I am curious about the separation of the old tag name into type and context. With the new one, I cannot search for all users with rank=90 anymore. I can only filter for w=rank on Nostr filters. The other ones are weird because the "value" context doesn't say which value. So, if my client displays zaps sent only via `zap_sats_sent`, I cannot filter only the events that include `zap_sats_sent`. I can only filter by w=value, which doesn't seem that helpful.

We could add `w=zap_sats_sent` directly to the old TA spec if needed so that we can filter by all users monitored by the `zap_sats_sent` provider of the user.

Reply to this note

Please Login to reply.

Discussion

Justin (shocknet) 3w ago

The W would disambiguate the kind if there's any collision, so you could reasonably query for the NIP-85 structure and find attestations that might be available where you don't necessarily know or care exactly what types they contain

zap_sats_sent would be a good type in my view, rather than just value, zap_sats_sent would be better having values under it... perhaps things like week month year. So yea to your point I don't think value is itself is a good top-level type example, I mostly like eliminating the registry in the NIP.

Vitor Pamplona 3w ago 💬 2

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 …?

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.