NIP-101 - Decentralized Trust System for Nostr #1718
Conversation
…tion, a life, and NIP-100 is designed for this type of paradigm.
…n the Nostr network through a decentralized and user-driven trust model.
|
Please get rid of the json object inside the .contents and move those properties to the tag array as usual. |
101.md
Outdated
| ```json | ||
| { | ||
| "kind": 33, | ||
| "content": { |
There was a problem hiding this comment.
it must be a stringified json. also, its better to use tags instead of a json on content.
…using the `tags` array for metadata.
better like this ? |
|
Yes, it is quite similar to a Web of Trust (WoT) conceptually. Both systems rely on decentralized trust relationships between individuals to establish credibility, reduce spam, and curate meaningful interactions. However, there are some nuanced differences that distinguish this NIP from traditional Web of Trust implementations: Similarities:
Differences:
Why Not Just Call It Web of Trust?While NIP-101 shares foundational principles with a Web of Trust, its focus, mechanisms, and application to social content filtering make it a specialized adaptation for Nostr. Referring to it simply as "Web of Trust" might imply it’s a direct replica of older systems, which could lead to confusion about its purpose. This proposal is essentially a modernized, use-case-specific Web of Trust, optimized for decentralized social networking. Would you like to incorporate this clarification into the proposal? |
|
I agree with you. sorry about that but it helps me a lot to transform this idea https://web.archive.org/web/20230324134924/https://adecentralizedworld.com/2020/06/a-trust-and-moderation-system-for-the-decentralized-web/ into a NIP (i got only one valid arm for typing)
Algorithm simulation has pretty nice performance. Mute/Follow action could send normalized "rating" event to initiate dataset |
applyed in last commit |
101.md
Outdated
| import math | ||
|
|
||
| def calculate_trust(user, friend_ratings, all_ratings): | ||
| trust_score = 0.0 | ||
| num_raters = 0 | ||
| for friend, direct_rating in friend_ratings.items(): | ||
| if friend in all_ratings and user in all_ratings[friend]: | ||
| mutual_rating = all_ratings[friend][user] | ||
| if mutual_rating > 0: | ||
| trust_score += direct_rating * mutual_rating | ||
| num_raters += 1 | ||
| return math.sqrt(trust_score / num_raters) if num_raters > 0 else 0.0 | ||
|
|
||
| # Example: | ||
| all_ratings = {"A": {"B": 50, "C": 20}, "B": {"D": 100}, "C": {"D": 40}} | ||
| user = "D" | ||
| friend_ratings = {"B": 80, "C": 60} | ||
| print(calculate_trust(user, friend_ratings, all_ratings)) |
There was a problem hiding this comment.
this python code is invalid and unreadable
There was a problem hiding this comment.
thanks for noticing. been fixed in latest version
|
I had a proposal years ago that was basically exactly this, but I don't think it will work anymore, it's too complex and most people won't bother. I don't know what is the solution. |
@fiatjaf best option is to keep it unstandard and let clients/relays do the web of trust rating using their custom model based on user config or any other approach. making it an standard would limit them. we have data over nostr, relay or client can use them in any ways to check trust rate and more. |
|
I think @wds4 and @pippellia-btc are already working on this problem, you should consider looking at their work. |
|
Hey @papiche, first of all let me say that this proposal has the benefit of being simple.
For what is worth, very soon @franzaps and I are going to share our approach to solve, not trust (which is vague), but "spamminess" and its opposite, relevance. |
|
Hi @pippellia-btc thank you for the feedback! You're absolutely right—prescribing a specific algorithm might overly constrain experimentation. The proposed formula is expecting users to rate others on a scale of -100 to +100 that coud be awkward. Concerning UX, clients could associate "trust signal" to actual user actions expressing mood level on a "Hate ↔ Love" scale. For example :
It could also be associated with other "signals" The score is user categorized and capped between - 100 and +100 as the maximum value |
|
Trying to make a NIP-101 nostr client basic implementation code repo : https://github.com/papiche/NIP-101 |
|
@papiche Have you read previous discussion on WoT systems here in the NIPs repo? What are your thoughts on those? |
No i don't, do you have some discussion to spot to me ? |
|
@papiche here's a relevant couple of episodes from my podcast that you might enjoy: https://fountain.fm/episode/SJJKS7tr2WI9R4gaVXxO |
This one for example: #1208 Nostr is permissionless, so you can build anything you want on it. It looks like you put quite some effort and your NIP looks interesting. I don't know how familiar you are with the process, or how new to nostr you are, but we have been debating web of trust for a long time. Just that don't expect this NIP to reach consensus soon, especially if you haven't yet considered other stakeholders' points of view. I personally have a hard time seeing how these love/hate input signals get implemented and meaningful enough to derive any result from. With @pippellia-btc we're building Vertex, a service offering different trust metrics between nostr pubkeys. |
Proposed WoT solutions virtually always get more and more complex until they collapse under their own weight, before even leaving the drawing board. Like a math problem that diverges to infinity every time we try to solve it. We gotta figure out how to normalize it to make the infinities go away, like Richard Feynman and colleagues back in the day. One of the techniques that I propose as a way to solve our own infinities is what I call interpretation. I really need to write it up as a long form nostr post. But the down and dirty is this. Suppose you get an idea in your head of The Perfect WoT Algorithm. Algos need raw data, right? And the data needs to be in a format ready for digestion by the algo, right? So now we have two classes of data:
In the fiat world, where all platforms are centralized, the platform devs have the luxury to impose class 1 = class 2. But in the real world, the decentralized world where data is messy and not under our control, no one has (or should have) the power to set class 1 = class 2. The problem is that we haven't as a community figured that out yet, so we have solution after solution where we try to do the impossible, which is to set two things equal that simply cannot ever be equal. Which is why our solutions always blow up in our faces as draft NIPs before they even leave the drawing boards. And so I propose that the only solution is to INTEPRET: we accept that class 1 data and class 2 data are NOT EQUAL and will NEVER BE EQUAL. Which means we write scripts to translate, i.e. interpret, whatever data we can find into a usable format. We write scripts that ingest class 2 data, spit out class 1 data, and feed class 1 data into our algos. The best thing is that Alice and Bob are free to interpret the world in accordance with their own individual preferences, beliefs, and values. That's it. That's the idea. |
I still love NIP-77! Why? because the format of NIP-77 was convenient for My Favorite WoT Algorithm: GrapeRank. But as discussed above: by advocating for NIP-77, I was attempting to do the impossible: get all of nostr to generate data in a format convenient to me. But I was quickly convinced by many in the nostr space that it ain't gonna happen. People aren't gonna generate data in a particular format just bc I want them to. But they WILL generate LOTS of data in a myriad range of other formats. Data that is imperfect to my purposes because it's maybe only tangentially on topic, and it's often highly ambiguous. But we gotta learn to make do with what we got. Hence, the need to interpret. |
NIP-101 - Decentralized Trust System for Nostr
This merge request introduces NIP-101: Decentralized Trust System for Nostr, a proposal designed to improve content filtering and moderation on the Nostr network through a decentralized and user-driven trust model.
The key highlights of this proposal include:
We believe this NIP will enhance the overall quality of conversations on Nostr, reduce spam and misinformation, and provide users with greater control over their experience.
Why this matters:
The proposed system aligns with Nostr’s core principles of decentralization and openness, offering a scalable, flexible, and community-driven moderation alternative.
We encourage the community to review, provide feedback, and test this implementation to help refine and integrate it into Nostr clients and infrastructure.
Let’s work together to make the Nostr ecosystem more dynamic, user-centric, and trust-driven!