Curious 👀

Had to watch three times!

It’s really amazing how many NIPs are being proposed “out there” in various repositories and event kinds on Nostr.

NostrHub is under active development AS WE SPEAK to render ALL THE NIPs from ALL of these sources in a consistent manner, with decentralized rating and review (powered by WoT) for all of them.

Take a look 👀
@nprofile1q...
https://nostrhub.io

Have faith in Nostr.
@nevent1qqs...

Hey @npub15ypxp... … have you teamed up with @npub1gmmrk... yet … to make d-commerce great again?

@nevent1qqs...

lol. It’s not git over Nostr. Sorry if that was confusing. It’s a client for developers to explore Nostr nips and apps and (nip 34) git repos. WIP.

https://nostrhub.io 👀
Is already a great client for this.
Shortly we will support WoT powered rating and review of NIP proposals submitted from across Nostr… and other repos as well. New release on its way out the door. Stay tuned.
@nprofile1q...

Taking a look 👀 @naddr1qqsx...

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", "<context>", "<schema>"]
["v", "<result>"]

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.

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:<context>”, “<result>”, “<data_type/schema>”]

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:<context>”, “<result>”, “<data_type/schema>”]

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 @npub1gcxzt... , 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 …?

- I actually rewrote the entire NIP (while I was at it) for clarity. So a diff would not be as useful as you may think.

- also, the updated spec does allow for the “type” categories (index 1 in the tag) to be any arbitrary value … even if only ONE service provider supports it. These are only intended to hint at the underlying data type returned.

- given this, it does make sense to have a standard “w” label for the tag itself (index 0 in the tag) and also … for indexing purposes.

- give that the arbitrary “context” string will end up being the “d” tag value for (spec TBD) a user published “algo config” event … indexing these “w” tags makes sense for other users to discover each other’s “configured algos” … without necessarily exposing the users actual algo config.