-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trusted Assertions #1534
base: master
Are you sure you want to change the base?
Trusted Assertions #1534
Conversation
@alexgleason I think you already have something like this, using the same kinds |
Follower count can be easily gamed by automated agents. And this NIP encourages that. |
Deciding what counts is up to each service provider and user. This NIP just specifies how they declare trust in each other. |
Concept ack, need to try it. |
Co-authored-by: arthurfranca <[email protected]>
It is possible to add event quotes too? |
WoT "scores" are not absolute for any user, but relative from the perspective of an "observer". So the event sent (from service) SHOULD specify an observer tag as well as the recipient of the score. In addition ... our service (and prolly other WoT recommendation engines) would prefer to output a list of scores (possibly thousands) for any given observer. So maybe having a "d" tag for the whole event is not the right format? |
Correct, but for these events, they will have to be absolute. Picture a WOT algorithm that is just a "page rank" for pubkeys.
No, I don't think this would work (too much data - quadratic on the amount of users). DVMs would work better for the personalized score services (which this PR does NOT replace) |
I would use DVMs to do this. Most people think of them as a request/response flow, but they also easily support zero requests and 0+ responses. A client looking for these events would just query for the DVM response without publishing a request. |
That was my initial conclusion as well. But after months of testing and debates, I think that just overloads the DVM spec with a use case that needs a different tooling from what they use. It's a similar thing with your recent NIP-29 fork. It initially looks similar, but in the end it's not the same thing. |
Actually, on a second read of the PR you're right. It's a totally different use case, even if it could be shoe-horned into the same structure. Onward 🫡 |
I CAN picture a WoT algorithm that is just a "page rank" for pubkeys. It's called GrapeRank, and there is no such thing as an absolute WoT score. https://github.com/Pretty-Good-Freedom-Tech/graperank-nodejs There MAY BE such a thing as an "average observed" score for a pubkey, but this is only useful AFAIKT if the requestor either does not have a pubkey of their own (because directly observed scores ARE more accurate for any user's use case) or if the requestor does not want their "observed network" to be transmitted publicly. In this latter case, we are working on a better solution for transmitting WoT scores privately. And you may be right about DVMs being a better solution for WoT lists. An API architecture that accommodates a "list of recommendations for a given observer" is MUCH more useful for transmitting WoT "scores" (and other user and content recommendations) than the NiP proposed here. IMHO, mostly because WoT scores ARE relative, I do not think this proposal actually solves for any real world problem of transmitting WoT recommendations from a remote service. |
It's not hypothetical, this is one of the main use cases for this PR. Apps don't need high-precision in WoT scores most of the time. We just need some basic reputational scores to.. say.. rank search results when people are trying to @ someone. Things like that. Sure, personalized and private WoT are better versions of this but the added performance costs sometimes are not acceptable. For instance, I need the WoT to show up while the user scrolls really fast in the app. We wouldn't be able to call a server for each user in time. Obviously, this doesn't replace the need for personalized and private WoT. It's just solving a different need. |
I appreciate the need for speed when clients make use of WoT recommendations ... but I still don't think "generic" scores are a great solution. Indeed, a cached "wot list" may perform even better than discrete "wot score" requests.
In many ways ... an observer-centric "recommendation list" is a better solution for "wot scores" than this proposal. IMHO |
Interesting! In Ditto I am using these kind 30382 events with It competes slightly with what I'm doing with labels, but not by much. The drawback of using labels in this way is that they store fixed values (not dynamic ones), they're not replaceable events, and when you start labeling a lot of things at once they can have collisions. A good way I'm using labels is for trending posts, but now I'm considering moving my captcha solved label to kind 30382. |
The cool part of moving to 30382 is that you can add ditto's pubkey to the user's trusted providers and then I can display the same info you have on Amethyst. And maybe one day Ditto can rely on other service providers as well. |
I think kind 30078 should be extended, to require a third parameter of the d-tag, "p", like this: ["d", "<pubkey>", "p"] And then a p-tag with a matching pubkey is also required or else validation fails. Same with "e", "r", etc. This way you can also p-tag query them, and it enforces the type of the "d" tag. I think this should be a general rule for d-tags whose value references another common type of tag. EDIT: See #1536 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on the idea; I think something like this is useful.
I don't think this should include the WoT stuff; that's a cheap and subjective calculation that belongs in the client; all indications of an absolute-ish WoT score are pervasive − even if here it's presented as "WoT from the point of view of the service provider" -- it will lead to misunderstandings and misuse.
ACK
Are you referring to the follows of follows set of keys that everyone calls web of trust in Nostr? If so yes, that is cheap, but that is not WoT in my mind. My hope for the WoT is to do a full graph analysis of all keys and iteratively assemble a score for each pubkey from a global perspective. I don't think that can be done in the client. And again, that does not replace any other approach, neither simpler nor more complex, for WoT calculations. It just offers a base layer that will likely be whatever algorithm the provider wants to make. We will have a competition for the best WoT providers out there. |
You lost me at global. 😂 I wouldn't call that WoT, the nature of WoT implies that it would be from someone's perspective, I'd say a "global WoT" is an oxymoron. Anyways, this is beside the point of this PR and I don't want to derail the conversation. Are you working on implementing one of these services? |
Makes sense. We can call it rank or something else.
Yes, but I don't really want to. I don't really want to run any services at all. I find these decisions (when the app also runs the service) extremely centralizing in the long run. If anyone puts a service like this, I will completely shutdown mine. |
Created wss://nip85.nostr.band and uploaded 30382 by "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe" with "rank" scores (instead of "wot"). Let me know if that looks good. |
- Adds relay hints for base events. - Adds private list options - Adds kind to the list-tag settings
explains kind:tag in the trusted service lists.
We DO need a NIP for clients to retrieve 'on-demand' rankings of users and content from trusted sources, but these values will ALSO need to be 'relative' to the pubkey of the client user (the network observer). With a couple tweaks, I believe this NIP could be perfect for publishing Assertion events with such an 'observer' relationship. @nostrband @vitorpamplona @pablof7z To indicate this 'observer' relationship, a kind The argument is such : If a signed kind ALSO : To be clear, if an Assertion event is published in this manner, then the value of "d" tag would need to reflect this relationship. So... "d" == "p" as suggested by @alexgleason would NOT always work for kind |
["p", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411", "<user-home-relay-url>"], // relay hints to find the user | ||
["rank", "89"], | ||
["zap_amt_sent", "1000000"], | ||
], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
["delegation", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe"], // publish this assertion on 'behalf' of another pubkey ... as for 'relative' ranks of user and content
| name | kind | `d` tag value | result tags | | ||
| ----------------------- | ----- | ------------- | ----------------------------------- | | ||
| Follower Count | 30382 | pubkey | `"followers"` (int) | | ||
| User Rank | 30382 | pubkey | `"rank"` (int, normalized 0-100) | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolute ranks are pointless. Relative ranks will require "d" tag to reflect the ID of 'observer' AS WELL as 'subject'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the relative rank should be made via a DVM, where there is a request/response that facilitates creating each pair that matters. Otherwise, generating ranks for every pair of public keys in Nostr will take a huge processing power.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @vitorpamplona
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
generating ranks for every pairs of public keys in Nostr will take a huge processing power.
No. Ranking services won't have to calculate "Every pair of public keys" on Nostr.
-
Services will only calculate "subject" pubkeys for an "observer" who "trusts" and authorizes (and subscribes to?) the service.
-
Services will (presumably) cache rankings for each "subscribed" observer.
-
Clients and services only need to handle rankings for ONE "observer" (client user) per session.
In the end... this is no additional work for the client ... and services providers can "optionally" provide relative (observer centric) rankings or not.
+1 for this NIP. The list of names should be open enough to include all of our disparate ideas. We have different ideas about what WoT means... just add multiple names for each different algorithm people are actually implementing. So I don't think fighting over which ones are in that list makes any sense, just add more as we make up more, and deprecate ones that nobody ended up using. |
I hard disagree. It means instead the following: "Hey Mr nostr client that I am currently using, please get this data from the service I specified". It doesn't mean the service can sign on your behalf. At all. |
I would change the name of this PR to something more like "Data Aggregation". The fact that someone publishes an event that says "I accept the values this relay is giving me" is the smaller part of this... the larger part is the data being published. |
I’ve done a test run of kind 30382 Trusted Attestations, all authored by me (pk:
I've included all pubkeys with a nonzero GrapeRank score which comes to about 88k events for this run. There are various other scores I can include, including followers count (only includes pubkeys in your extended Follows Network so excludes thousands of spam accounts for many users) and any of the other scores you see at the grapevine-brainstorm profile page. I haven't yet pushed the changes but when it's ready then anybody will be able to go to https://grapevine-brainstorm.vercel.app, generate personalized WoT scores and publish their own personalized batch of Trusted Attestations. Here's an example event:
If there's enough interest in using these Trusted Attestations then I could easily set up a schedule to refresh them on a periodic basis. (Daily would be no problem.) |
Ohh this is super interesting. Will you be generating new keys for each algorithm? In that way a user could have Grapevine and Pagerank as two keys they could choose in the app. In that way the entire set can also be easily deleted when updating it. The only issue is that for clients, the user will need to know the pubkeys of each algo. 🤔 |
Hum.. on a second thought, managing multiple keys will be a mess. We might as well just have different standard tag names for different algos. |
Yup I agree: different tag names for different algos is probably the way to go. GrapeRank is designed to be contextual, and to have a string field to represent the context, which could be a human readable string (e.g. "genericTrust") or not (e.g. it could be a note id, naddr, something that points to some more complex data object). So far, I've only done a single GrapeRank context and I haven't assigned it a string bc there are no other scores to distinguish it from yet, but if I were forced to do so it would be "verified real nostr user" or "notSpam" or something like that. When I do start to produce contextual GrapeRank scores, I'll have to figure out how to craft the tag. Maybe personalized_grapeRank_. I imagine I'll wait and see how you and other devs utilize the generic trust scores and go from there. |
Given that each user produces on the order of almost 100k events for these scores and that that number will grow as nostr grows, I worry about flooding nostr with all those events. I can imagine storing them on a specialized relay; either your own personal WoT relay or a third party service. Each user could designate a relay contains those events. Maybe modify NIP-65 with a special tag so you can point to your Trusted Assertions relay in a kind 10002 event? Something to think about. For now, I'll plan on storing all of them in my own relay: |
Following this NIP I am declaring the Trusted Service Provider as a kind 10040 note. The following is an example:
The initial plan is for Trusted Assertions to be self-published, as indicated in the above example, where the TSP and the event author are the same. Hopefully in the near future, I'll create a service to play the role of Trusted Service Provider which will automatically update Trusted Assertions on some sort of schedule. Longer term, my plan is to build personalized WoT relays with personalized Trusted Service Provider capability, among other things. |
Looks like poster.place is using kind 30382 notes to record captcha. Here is a sample note. |
After we launched Vertex there was a bit of debate around NIP-85 vs web of trust DVMs, on nostr socials and here, so I'm going to give our view of how they compare. From previous discussion on here it's clear that precomputing Personalized Pagerank is not ideal as it scales as
We are left with "global", which as Pablo has said is an oxymoron in nostr, and far from ideal in practice as influencers and bots get a disproportionate amount of rank. So this is the first downside of NIP-85 for web of trust. I will break down the different use-cases below and try to replicate these DVMs using NIP-85. Please correct me if I made any mistakes. A general observation is that for NIP-85 a significantly larger amount of events need to have their signatures verified in the client, which may be taxing to low power devices.
|
My published NIP-85 scores are personalized, not global. |
For use cases where a huge number of scores will be needed, then you can make an argument that it makes sense to package lots of scores into one event, to avoid the problem you mention. And a WoT DVM could be a good answer to that. We should avoid the mindset that there is a competition between Trusted Assertions and WoT DVMs. My current stance is that we need both. The question is not which is better in an absolute sense. The questions are these: what are the tradeoffs to each approach; and what are the scenarios where we should use one approach as opposed to the other. |
I'm currently building a personalized WoT relay (strfry + neo4j graph database) that will precompute personalized PageRank (to be followed soon by other scores, like personalized graperank) periodically. Could be once an hour, whatever. Could also recompute in response to some event that would trigger a significant change in a high profile trust score. In the context of personalized WoT relays, storing precomputed personalized trust scores locally using something like NIP-85 makes a lots of sense to me. Now that I think about it, personalized WoT relays could ALSO offer access to scores via a WoT DVM. Why not both? |
I always assumed that calculating WoT for a given pubkey on-demand would take too long. Is that true? If so, can NIP-85 be seen as a cache for the DVMs? On the content DVMs, Users don't wait more than 2 seconds for a DVM to return. If it takes more than that they already think it is broken. |
iirc our DVMs using Personalized Pagerank return in ~800ms on average, and we haven't started worrying about optimization or vertical scaling. To the point where we will also offer them via REQ filters. Yes we could produce NIP-85 events for Global Pagerank maybe. WoT DVM responses can also be cached. |
For now, I could probably provide personalized PageRank on demand, which means NIP-85 and WoT DVMs are both viable options; but personalized GrapeRank would take to long to calculate on demand, which means I either stick to NIP-85 or deliver a precalculated result through DVM. I could optimize GrapeRank to calculate it faster, but at a fundamental level I think we need to embrace the fact we can do some of the calculations on the fly some of the time, but we won't be able to do all of the calculations on the fly all of the time. Which means we may as well go ahead and embrace the NIP-85 method. But here's something I like better about the WoT DVM method: suppose I want to sell my WoT data for a few sats. For that use case, the NIP-85 method won't work. We need both methods. |
Nothing stopping you from returning slightly stale data from your DVM as well. We could add a freshness timestamp or similar if necessary. |
We're using mmalmi's nostr-social-graph to cache the WoT on the unreleased Nestr client so on-demand scores become trivial to calculate. |
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 way for users to declare trust in service providers for those calculations.
Yes, it's similar to DVMs, but without the need to request/response each item. The service just runs constantly and updates events as quickly as it can.
Read here