Thread

Trusted Assertions is overly verbose with limited usefulness. Why all these kinds and subjects and d tags? Wouldn't a better solution allow more freedom for end users? Help me understand ... This Trusted Assertions NIP (aka : NIP-85) specifies how clients can request explicit *trusted numbers* from a trust *service provider*. These numbers may be *trusted metrics* related to a user (like: "User Rank", "First Post Time", "Post Count", ect...), or they may be *trusted counts* related to event kinds (like: "Follower Count", "Reply Count", "Reactions Count", ect...). And there may be other *trusted numbers* also. Either way, the TYPES of *trusted numbers* available for requesting from a *service provider* are BAKED INTO THE PROTOCOL, and a rather LONG LIST ALREADY, with no facility to scale as needs change. While this NIP tries to address (rather verbosely) how to obtain *trusted counts* for various event kinds (number of events published within a user's trust network), the data retrieved are NOT THE ACTUAL *trusted events* (only a count of events), and DO NOT PROVIDE any means for a client to request these events, and are also SOMEWHAT POINTLESS given that the counts received from a black box algo (the trust service provider) CANNOT BE TRUSTED TO BE CONSISTENT with whatever algo is THEN used to RE-DISCOVER and request the ACTUAL TRUSTED EVENTS from the user's preferred relays. This seems labyrinthine? Which begs the question ... How exactly SHOULD a client request "Not Spam Replies" for a post, and "Not Spam Posts" for a feed, and any other *trusted events* in a manner that is CONSISTENT with the *trusted count* of events? While these oversights MAY BE BY DESIGN (for NIP simplicity) there is an even MORE IMPORTANT INTERFACE for **Trust Service Providers** that this NIP kind of skirts around, but DOES NOT actually specify ... MORE IMPORTANT than *trusted numbers*. A NIP for **Trust Service Providers** SHOULD establish a standard RPC interface by which END USERS can SUBMIT AND SHARE their own PROVIDER AGNOSTIC ALGO CONFIGS using ARBITRARY EVENT KINDS and other stuff. IMHO, sovereignty for end users to CONFIGURE AND SHARE their own algos is the MOST IMPORTANT specification for webs of trust. Everything else is downhill. This NIP starts to (but does not quite) solve for this need of USER SPECIFIED ALGOS AND ALGO PROVIDERS, and is kind of stuck in an awkward in-be-tween. I'm not entirely clear how to proceed, but as it stands, this NIP seems OVER SPEC'D to me, and may benefit by NARROWING ITS FOCUS . Avoid specifying *trusted counts* (for fixed event kinds), and only specify the bare minimum for *trusted metrics* (numbers that stand on their own). WHILE, this NIP does do a GREAT JOB at specifying how users should publish their preferred **Trust Service Provider** (via kind 10040) ... maybe a FULL RPC SPEC for **Trust Service Providers** is too much to ask at this point for this NIP. So ... trim it down? These are my thoughts so far. This topic needs more attention than I can give right now, but I hope the conversation continues. Am I on the right track, or off track entirely? Help me understand. (Also, please forgive my YELLING. It's neither personal nor emotional, just *colorful*.)
GitHub
Trusted Assertions by vitorpamplona · Pull Request #1534 · nostr-protocol/nips
Certain calculations in Nostr require access to the entire dataset of events and are impossible to do directly by Clients. This PR offers a simple ...
 📃.md

Replies (5)

🛡️
Frankly, the tags just grew over time with people asking me to add them based on their clients' needs. Either here or somewhere else, we will need to specify each of these tags so that different clients can have the information they need for their own interfaces. In that way, many providers can agree to offer scores labeled by specific tags that everybody agrees on what they mean. We will likely keep adding more as needed and deleting those that get deprecated over time. > How exactly SHOULD a client request "Not Spam Replies" for a post, and "Not Spam Posts" for a feed, and any other *trusted events* in a manner that is CONSISTENT with the *trusted count* of events? This NIP does not define a query interface. It just stores the scores for events and pubkeys so that another NIP can specify querying. Right now, there are querying options via NIP-50, via DVMs and via HTTPs APIs because each of these options has pros and cons that different use cases might need. So, instead of defining all kinds of queries in one NIP, this one just defines how to save the scores to let other NIPs define the interface to access them.
🛡️
I like the general design of TAs, and I think the most important next step to advance WoT in nostr is to encourage TA incorporation by multiple clients. You're working on this here on NostrHub, a few other devs are working on it in other clients, but TA adoption (as is) is where most of our attention and efforts should be. I do agree that the list of tags is unwieldy. In principle, there's no upper limit to the number of tags that we're going to need. Who manages this list of tags? My tentative answer to that question is that the list of tags can be managed by my Grapevine using Decentralized Lists NIP. However, decentralized list curation has not yet been built out, which means we're not ready to curate the list of tags for this NIP. In terms of building, I think our attention needs to be focused on: 1. encouraging TA incorporation by clients (and TA publication by service providers) -- definitely top priority 2. demonstration of vanilla curation of decentralized lists -- can do this right now, but lower priority than (1) After 1 and 2, we can talk about using decentralized lists to curate tags, but there's no urgency. This discussion will be much easier once we have working implementations of TAs and list curation for all of us to play with.
🛡️
Sharing algo configs is definitely something that needs to be done, but I think that should be done independently of this NIP. What is the data format for algo configs? Eventually, we will need decentralized curation of semantics/ontology. How *exactly* do we do that? That's an interesting and worthwhile discussion to have, but for now it's very hypothetical. Once we can all play with decentralized curation of simple lists, and everyone sees how that works, it will be MUCH easier to envision how we curate more complex data structures like data formats for algos. In the meantime, cloud fodder has expressed interest in writing a NIP for an API to manage WoT Service Providers. Similar to NIP-86: Relay Management API, which he is very familiar with. The WoT Service Provider Management API will need a way to communicate about algo configs -- maybe something you and cloud can work on together?
🛡️
Another thought: if the tag is an event id or naddr, then we can in principle pack one or two or a thousand algo parameters into just one string. The Concept Graph will (eventually) be able to handle something like this in a straightforward manner. But we can implement TAs now, even though we don't (yet) have the Concept Graph method all up and running.
🛡️
It just occurred to me today that there will be two quite distinct categories of tags. First category: tags like `rank` or `followers`, that will have wide utility and will not specify the algorithm. Followers means verified followers, and lots of people will have lots of ideas of what constitutes "verified," and that's a good thing. Second category: tags that DO specify the algorithm, in ALL of its excruciating detail. These may have detailed human-readable-ish names like `personalizedGrapeRank_influence_attenuation0.6_rigor0.9` or maybe even event ids or naddrs where we can find constants like attenuation and rigor and all of the other details of whichever algo it refers to. New, simple clients may support the first category by default, meaning that they will hardcode the commonly used metrics, like rank to filter spam and followers to stratify content. They won't necessarily need to give users the option to select other tags. Other clients may give users the ability to select lots of metrics for lots of use cases. One pair of metrics to filter and stritify trending list, another pair to filter and stratify responses or reactions, another slew of metrics to display on individual profile pages. Suppose the client lets you select the tag that you use to eliminate spam. This will require not only selection of the tag, like personalizedGrapeRank_influence_attenuation0.6_rigor0.9, but also the cutoff, like 0.1. One tag may range 0 to 100, another tag 0 to 1, another tag something else entirely, and any individual client may or may not provide support for any given tag.