Web of trust FTW
#wotathon
nostr:note1gqgn4wsas9ekm0wcrw6akax8kxyy4gx5wfdadpc2s0mqxvmg8n7qjum8k8
Discussion
Did you see the “update” I pushed for Trusted Assertions? Working RN on a UI flow to improve “forking and updating” for all NIPs!
I’d like to see some devs who have used TAs ( nostr:npub1zl3g38a6qypp6py2z07shggg45cu8qex992xpss7d8zrl28mu52s4cjajh, nostr:npub19ma2w9dmk3kat0nt0k5dwuqzvmg3va9ezwup0zkakhpwv0vcwvcsg8axkl, nostr:npub1xvtwx6tduaxnn9v3y7uasskl277achgu0tu2qncmc7hdsz6y2zyqce64sa … who am I missing?) weigh in on the changes you proposed — the discussion could happen on your custom NIP or on nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z ‘s original version:
The updates I’m making to NostrHub right now will show BOTH versions (of an ”updated” nip) on a single tabbed page and allow discussion to happen across versions…
Ah, that will be cool.
btw you may have already seen this - one of the spammy NIPs shows a score of +2 when it should be -2.
Will check it out 👍
The formatting here is a little hard to grasp fully, if this could be a proposed diff on the github PR that would be ideal for review
What I do grasp I think I agree with, the NIP as currently constructed is mostly a registry... I don't think its a good idea to hard code a bunch of possible metric tags into the NIP itself... Mani's arbitrary string give it more forward-utility without future changes.
An example expansion in my case would be, if I want my paid services to signal that a user paid for something, or was invited/sponsored by another user, I might arbitrarily want to use NIP-85 to publish a paid_user attestation from that service so other services might whitelist them as a non-bot without their yet having a broader WoT in the form of followers etc.
(open to suggestions for a paid_user/invitation NIP or NIP-85 adaptation to bootstrap WoT)
I'm not sure I see the value in the W tag, seems superfluous with the kind and the fact I'd be looking for a specific tag anyway, but perhaps i'm missing something.
I also think the categories themselves being part of the NIP is the same flaw as the registry, unless they're just meant as examples for a top/bottom leveling tags. This may be where formatting of the site as opposed to git makes things unclear. Basically if I were to make a diff the NIP would be half the size or less.
Unfortunately can't make the call tomorrow but look forward to discussing further and reviewing a diff.
- 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.
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 👍
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.
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.
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.
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 …?
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.
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:
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.
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.
