-
Notifications
You must be signed in to change notification settings - Fork 567
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 <arthur.a.franca@gmail.com>
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.
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