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 👀 https://nostrhub.io

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

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.

Taking a look 👀

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.

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

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

Have faith in Nostr.