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. |
You're absolutely right. In a peer-to-peer information system, each user operates from their own relative "point of view." This is a fundamental aspect of decentralization, where no single entity controls the narrative or the data.
Your idea of interpretation as a way to bridge the gap between "class 1" (perfectly formatted data) and "class 2" (messy, real-world data) is particularly insightful. This concept resonates with what we might call N1 (friends) and N2 (friends of friends) informational social polyhedrons. These layers of trust and interaction allow users to navigate the network based on their own relationships and preferences. As you noted, achieving consensus on Web of Trust (WoT) systems is inherently challenging. The most notable historical example is PGP, which struggled to maintain consistency beyond 100,000 members. This is largely due to the CAP Theorem (Consistency, Availability, Partition Tolerance), which highlights the trade-offs in distributed systems. In a decentralized network like Nostr, we must accept that fragmentation and differing perspectives are natural outcomes of a permissionless, P2P architecture.
This is a crucial point. NIP-101 is designed to provide a base layer for establishing relative trust between users and messages through categories. However, its success depends on client adoption and the generation of Kind 33 events. To address this, I’ve started prototyping a strfry plugin that intercepts regular client events and translates them into Kind 33 trust events. For example:
By automatically generating trust signals based on user actions, clients can use these events to calculate a relative trust horizon for each user. This allows clients to apply their own formulas and algorithms to provide personalized trust metrics, tailored to individual choices. In parallel, we are exploring the correlation of this scoring system with the Ğ1 token, a decentralized cryptocurrency built on the Duniter protocol. The Ğ1 token leverages a Proof of Humanity (PoH) mechanism, which uses a Web of Trust to certify unique human identities. This system ensures that each certified human creates the same amount of tokens daily, promoting fairness and reducing the risk of noisy or manipulative behavior. |
Cool! My app, which you can try out here, currently translates follows and mutes into a GrapeRank "rating" where a follow is a score of 1 carrying a relative weight ("confidence") of 3, and a mute is a score of 0 carrying a relative weight of 50. In both cases, the rating context is "real nostr user." These ratings are then fed into the GrapeRank algorithm to produce a score between 1 (verified "real nostr user") and 0 (not verified). Now, we could get into a long and tiresome debate leading nowhere over whether the score should range from 0 to 1 (my preference) or from -100 to + 100 (your preference). But the notion of interpretation saves us from that debate. It allows us to acknowledge that there is no one-size-fits-all interpretation. We can do both: we can interpret using my method when we want to use the GrapeRank algo, and interpret using your method when using a different algo. We can play around with the interpretation and optimize it along with our algos at the same time. Meanwhile, the nostr ecosystem continues to churn out follows and mutes, formatted according to NIPs that can be optimized to good UX, unrestricted by our ever-changing ideas about what we're going to do with the data. And of course we're not limited to follows and mutes. Interpretation allows us to use whatever data is available to us: Reports, replies, reactions, zaps, badges, labels, the list is endless. |
Nice. One of my upcoming projects is going to be to pair strfry with neo4j, probably the most mature FOSS graph database, and build a personalized WoT relay. It will use interpretation to ingest whatever data is available and best suited for calculation of various WoT scores and will use those scores to manage strfry filters and plugins. In this way, you will have exquisite control over which events you request (filters) and which you discard (plugins). If NIP-101 data is available, GrapeRank will have the ability to make use of it.
You probably already know this: talk about new cryptos will be seen as a red flag by many. But the great thing about nostr is that you don't need anyone's permission to build what you want! |
|
@wds4, GrapeRank’s binary approach (real vs. not real) is excellent for spam prevention and identity verification, while NIP-101’s Kind 33 events enable nuanced, context-specific trust metrics (e.g., social trust vs. expertise in a topic). As you’ve pointed out, our “score range expressions” are compatible:
The key difference lies in how these scores are interpreted and used:
This flexibility allows clients to choose the method—or a hybrid of methods—that best suits their needs. The Role of Ğ1 Proof of Humanity (PoH) By linking Nostr pubkeys to Ğ1 smith keys, we introduce verified identities that can serve as a foundation for trust. The Ğ1 system rewards each verified user with a fixed amount of tokens daily, creating an economic incentive for meaningful participation and reducing noisy behavior. Those Verified identities allow us to rely less on computationally intensive WoT algorithms like GrapeRank. Ğ1’s PoH enhances the reliability of Kind 33 ratings, making them more effective for content filtering and trust-based interactions (limited to N1/N2) N1/N2 Visual Exploration App A visual, intuitive interface could makes it easier for users to navigate their social connections. I imagine an interface that places you at the center of his social universe. With cards arranged like constellations. The goal is to offer a clear and personal view where user is the explorer. Each person you follow or who follows you is represented by a unique card, a little portrait of who they are, what they talk about. The border colors—green, blue can indicate the type of relationship you have with them.
Clicking on one of these faces opens another level, exploring a circle of friends of friends. The data you see is categorized to help you navigate easily, with categories and trust scores, a bit like a compass that guides you through this social labyrinth. By combining GrapeRank’s binary verification, Ğ1’s proof-of-humanity, and NIP-101’s nuanced trust metrics, I think we can create a comprehensive trust system that enhances the Nostr ecosystem. Let’s continue collaborating to make this vision a reality! |
I agree it does. Good question. |
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!