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 (1)

🛡️
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.