Thread

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

Replies (1)

Here is a proposed update to Trusted Assertions NIP that allows both users and providers to customize their own WoT services and contexts for querries. Similar to David's comment above, but the "categories" would simply be ordered elements in a tag array. In the TA events published by service providers, these tags would have the following format: - The first element is `w` ... because (publicly) published WoT results SHOULD be standardized and indexable (to feed deeper contextual queries) - The second element is a 'top level' service offered by a provider. These can be standardized in the NIP, but also MAY be arbitrary strings offered by any provider. - The third element is an arbitrary string representing a user's configured WoT filter OR (one of) a service provider's default, thus adding 'context' to deepen a WoT query. - The fourth element is the service provider's computed value - Additional elements are optional. Here are a few 'top level' services that providers could offer (accounting for ALL of the "hard coded" tags in the original TA NIP) - "rank" : provides a 0-100 integer representing the "trustabilty" of an npub or an event on a given "context" topic. - "count" : provides any integer representing a count of "trusted" or "verified" npubs or events on a given "context" topic. - "value" : provides any number representing a "trustworthy" value derived from reading and processing event content. - "list" : provides a unique "subscription_id" and an optional "relay_url" for which a REQ may be sent by the subscribed user to retrieve the computed list of events The computed (and possibly encrypted) results from a service provider (using examples above) might look like this : ``` js { "kind": 30382, "tags": [ ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"], ["p", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411", "<user-home-relay-url>"], // relay hints to find the user ["w", "rank", "<arbitrary_context_string>", "89"], ["w", "count", "zap_cnt_sent", "42"], ["w", "info", "zap_amt_sent", "1000000"], ], "content": nip44Encrypt(JSON.stringify([ ["w", "list", "<arbitrary_context_string>", "<subscription_id>", "<relay_url>"] ]) //... } ``` The `10040` preference event would provide info on 'top level' service categories, as well as specific (user provided or provider default) 'contextual' filters. ``` js { "kind": 10040, "tags": [ ["30382:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"], ["30382:rank:this_providers_popular_filter", "3d842afecd5e293f28b6627933704a3fb8ce153aa91d790ab11f6a752d44a42d", "wss://nostr.wine"], ["30382:info", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"], ], "content": nip44Encrypt(JSON.stringify([ ["30383:rank:my_secret_ranking_filter", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"], ["30384:list", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"], ]), //... } ``` The above changes to Trusted Assertions NIP ... COULD be backward compatible to support the FEW published TA events in the wild. But IMHO, we are too early to worry (too much) about legacy support for "hard wired" tags that constrain users and service providers from exploiting TA to it's fullest.