nips
nips copied to clipboard
nostr-protocol
Add NIP-77 for expressing trust
This seems to be the smallest common denominator of what people think about web-of-trust or trusting people.
From here, we can branch out, use this common format in apps, clients, relays, algorithms, DVMs, et cetera.
Two specific branches already exist:
- Tapestry Protocol for creating a language for the context field (https://github.com/wds4/tapestry-protocol/blob/main/guides/grapevineIncorporation/NIP-proposal.md#contexts)
- A NIP for extending relay filters to support querying / filtering based on web-of-trust (https://github.com/lez/nips/blob/nip76/76.md)
IMHO trust is contextual and not transitive. In the context of "is this person worthy of listening to, or are they a spammer/asshole that nobody likes" then there is some transitivity.
But my prediction is that people won't bother to create this data, and so this will wither and die even if implemented. Yet I'm not against people giving it a try.
In hierarchies trust is transitive (e.g. the owner trusts the CEO, the CEO trusts the CTO, the CTO trusts the dev manager, and so on...) This is one way to create organizations in a decentralized and scalable way. Really, there are a lot of ways one can regard trust, and the aim with this NIP is to create a common representation / language of how we formalize them.
In the real world, sometimes trust is transitive and sometimes it's not, which is why NIP-77 provides a mechanism (actually two mechanisms) to indicate whether it is transitive or not. One is with the optional "transitive" tag. The other mechanism would be to specify transitivity as part of the context.
One of the things I really like about NIP-77 is that the way context is specified is left open ended. Context could be a human-readable string like "to curate content in Wikifreedia" or it could be an event id or naddr pointing to context as defined using whatever protocol or ontology you want to use. This will allow different devs to experiment with different ways to represent context. I have my own way of representing context which I'm working on now, but I invite other devs to play with different ideas.
Mike does have a point: people aren't going to issue trust attestations unless they are sufficiently motivated to do so. The question from a dev perspective is: what's the lowest hanging fruit, i.e. the easiest thing to build using NIP-77 that people will want to use? Wikifreedia is one possibility I'm thinking about. Katherine Maher's involvement with Wikipedia illustrates the need. To be honest, for MOST articles, censorship is not going to be at the forefront of most users' minds. But that's OK, bc for SOME articles, it will, and some is enough.
In #1220 I explore a simple way (T tag added to a parameterized replacable event with a d tag set to the reviewed pubkey) to discover good wiki article versions (written by well rated pubkeys).
Transitivity is possible in the case of wikis cause if me or my follow say pubkey A wrote a good article on "NIP"s the pubkey A is also expected to have some good knowledge on "Nostr" topic. So pubkey A should be able to rate people on both topics.
So if pubkey A positively rates pubkey B on "Nostr"...
...then 1) pubkey B may have written a good article on "Nostr" or 2) pubkey B may have positively rated pubkey C on "Nostr" and so on.
It all starts with me or my follow clicking a thumbs up or down on a wiki article.
IMHO trust is contextual and not transitive. In the context of "is this person worthy of listening to, or are they a spammer/asshole that nobody likes" then there is some transitivity.
But my prediction is that people won't bother to create this data, and so this will wither and die even if implemented. Yet I'm not against people giving it a try.
It's contextual AND transitive. And both of those (context and transitivity) should be subjective.
@lez wondering what you make of this summary (a similar system built on Urbit):
https://gist.github.com/vcavallo/e008ed60968e9b5c08a9650c712f63bd
Re: users' laziness in issuing trust. This should likely be an (opt-in) feature that is transparent to the user. Example: on a long-form writing platform, I "like" a piece that comes with some tags from the author. This action can be construed as signaling X amount of trust for the author along the contexts represented by the tags. Developers could provide a "hard mode" that would allow a more proficient user to manually assign trust and/or use different context than what is in the author's tags. Or even to assign "negative" trust. (Imagine it's a post on how great McDonald's is and tagged with #recreation. An advanced user could give this author negative trust for #cusine).
But Ive digressed a bit. Application. Developers should provide sane defaults that intuit from users' natural behavior. And disclaim these features + provide overrides for those who wish to opt-out or take more control.
Getting normal users to create these is a different issue from defining them for people who do want to create them. I agree that there is plenty of signal in like/follow/reply etc that can be used to approximate "trust". This more formal proposal shouldn't replace that, just complement it. And I like the design, looking forward to seeing implementations.
This more formal proposal shouldn't replace that, just complement it.
I agree with this 100%. I used to favor explicit, contextual trust attestations over proxy indicators such as follows and likes, but I've since realized that we need to use both at the same time. What we need is a single composite contextual trust score that synthesizes highly abundant but low quality data (e.g. follows) with scarce but high quality data, e.g. attestations that follow the NIP-77 format. To do this right, we need a way to give less "weight" to a low quality data point (a follow) than a high quality data point. And the confidence score is an essential part of NIP-77, because it is a factor telling us how much weight to give to an individual data point. (With a second, independent factor being the most relevant trust score of the issuer.)
I propose weighted averages to be the cornerstone of how we synthesize data from multiple sources into a composite contextual trust score. What we do is we "interpret" low quality data, like follows, as if it were NIP-77 format, and we assign it an extremely low confidence because as we all know, follow != trust.
On the topic of lazy users: no one is going to issue any NIP-77 attestations at all unless there's a reason, which means we need to go ahead and build the weighted average method of calculating trust scores. Follows and mutes will yield a trust score that's kinda sorta a little bit useful, meaning that it's better than nothing, but if we throw in a small handful of NIP-77 attestations, maybe even just one, we will be able to catapult the composite score into the extremely useful range. Which means that users will be motivated to issue NIP-77 attestations, even if no one else is doing them yet. I'm in the process of building this at brainstorm.ninja (what I call the "Influence Score" is the composite trust score I'm talking about here) but if anyone else beats me to it, I won't mind!
I think we need to formalize specific situations so that processing them can be semantically meaningful.
To me, trust is always binary IN a context: "I trust my brother with my life I don't trust him to manage my money".
We can ask that question in the app and write two events with:
...
["c", "life"]
["transitive", "false"],
["score", "100"],
["confidence", "100"],
...
["c", "money"]
["transitive", "false"],
["score", "0"],
["confidence", "100"],
How useful are those events for anyone processing that? Probably very useful. But they need to know what was the question asked. Otherwise just money and life could mean so many different things that it becomes basically useless.
The more well-defined the context, the more useful (probably). But I like that NIP-77 specifies context as a string, like "money" or "life", with no additional formal structure (for now), which will allow devs to experiment with different ways to represent context.
My own impulse would be to represent context using two fields: an action and a category. The action might be "to give me advice on" and the category might be "money." Or action: "to rate and review", category "movies." Or action: "to serve as product manager", category: "social media websites." Or action: "all actions," category: "all categories." But is everyone going to agree with this semantic structure? I suspect other people will have other ideas.
In NIP-54, wiki categories are simple strings, selected by the author. Perhaps a similarly simple approach is the best place to start. If we want to add more fields we can do that later, but I suspect it's going to be very difficult to get everyone to agree on any particular semantic structure without playing around with it first.
My long term view is that my WoT will manage the semantic structure for me, but that's waaaay beyond this NIP.
I like the action + context.
But I think we need to be very prescriptive in the beginning to get traction. Let's make sure it can be flexible, but also get one or two useful use cases out of the gate to bootstrap this idea.
Informal use, refined over time through experimentation is the way to go IMO. Describing trust is as complex as language itself, whose goal is to communicate meaning. Meaning doesn't fit into rigid hierarchies, attempts at the semantic web notwithstanding. Unspecified c tag meaning also leaves room for using any existing ontology though, if that's preferred. A lot of this is relevant to what I was trying to accomplish with NIP 32.
For https://github.com/lez/nips/blob/nip76/76.md - do you have a proposal for how to achieve the depth/transitive filtering? I recommend modeling the graph as a maximum flow problem (or "capacity constrained flow").
This maybe raises a few tangential questions, though: is negative trust allowed? is 0 "I don't know..." or "explicitly anti-trust" ? signalling positive trust is one thing, but negative trust / dis-recommending is another.
Edit: Duh, sorry. You're proposing using Grapevine. I'm going to leave my above comment because I still hold out hope for a max-flow algorithm being useful somewhere in WoT.
My view is that in the long term, we are going to have a myriad of algos for a variety of applications. Just bc I propose doing things one way doesn't mean I see no value or think there is no place for doing them a different way.
In what I'm building: I don't (currently) use negative trust, because my goal is that the Grapevine tells me how much attention to pay to a profile (or a piece of content) in some given context. This is the function of the Influence Score. A score of zero means I pay zero attention to that user in that context, and that's as low as it gets. You can see an implementation of the Influence Score at brainstorm.ninja where I calculate it based on follows and mutes and use it to stratify wiki content. My next step will be to calculate contextual influence scores based on follows + mutes + contextual attestations. I realized recently that merging highly abundant but low quality trust data (follows and mutes) with scarce but high quality trust data (NIP-77 formatted) is the way to go, so hopefully I will be able to demonstrate what I'm talking about.
Of course, there's a difference between completely ignoring a user because I have zero information on that profile, versus ignoring because I have information that the user is a bot or scammer or whatever. From that perspective, yes there is a role for a "negative" trust score or trust rating. So the question is not whether to allow negative scores, but what tools to build and most importantly, in what order to build them. My own roadmap, which I revise constantly, involves introducing the Concept Graph in stages; at some point, your Grapevine will have the ability to use the Concept Graph to invent new trust attestations (including those with negative scores) and new algorithms to process trust attestations into composite scores.
ADDENDUM: the Influence Score at brainstorm.ninja is my way of implementing transitive trust. The "depth" is managed by the attenuation factor, a number between 0 and 1 which decreases the confidence of each attestation and therefore decreases amount of attention we pay to users with each additional hop away, so a lower AF effectively means less "depth". This is a setting that will eventually be adjustable by the user, although for now I'm trying to keep things as simple as possible, so the AF is kept under the hood and is fixed at the default value of 0.8.
On the question of whether 0 means "explicitly anti trust" versus "I don't know": in my view, your question underscores the fact that trust requires two numerical fields, not just one. One for the score and one for the confidence. Because otherwise it is ambiguous whether 0 means anti trust versus no information. As users, we are already accustomed to two fields: when you go to Amazon, for example, you see an average score (the rating) and the number of raters (which is an imperfect and flawed proxy for confidence, with more raters = more confidence; obviously flawed bc more raters might simply mean more money to pay for ratings farms!).
Thanks, makes sense @wds4!
And I agree that eventually including negative trust will be important. A few months back there was a debate about "mute lists" and most of the proposed solutions were too centralized and would unnecessarily narrow the notes a user might see without their control. NIP-77-backed "mute lists" is the way to go, in my opinion:
Various users would have "lists" of "these people suck (+ context)" by virtue of their NIP-77 negatives. I could choose to Trust these users on that context, effectively delegating my mute list to them. (that context may even just be something like "is a spammer". or "posts too much porn")
In this way, "community curators" could naturally arise without needlessly tying users' hands or blinding their eyes without their consent. If I'm feeling like I don't like the work a given "curator's" mute list is working, I simply stop trusting them on that and the bots and spammers (and a few high-quality accounts the curator muted but I would prefer to see!) re-appear. Sovereignty-preserving without loss of functionality. This is the way, naturally.
With some imagination and entrepreneurship, "curators" could charge for their work...
I definitely envision that one day curators will charge for their work. Perhaps we will all become curators. Imagine that instead of leaving a review for a coffee shop for free at Yelp, you create an attestation and charge a few sats, which I am happy to pay bc it's only a few sats and I know it's worth it bc my WoT tells me you're trustworthy for that context (no need to be a coffee afficianado; I mostly just need to know you're a real person and not a bot!). Or perhaps you gain a reputation for having good judgement and ability to discern users who are real people but have a propensity to veer into troll-like behavior, trigger flame wars, etc. No need to be outright blocked, but maybe such a user deserves to be weighted a little bit less. Or the opposite: profiles who you may want to weigh a little bit more. It would take work + good judgement to make these calls and if you're good, perhaps you could turn it into a side gig!
On the topic of mute lists: When I calculate influence scores, I do what I call "interpretation," which means I take some piece of data, like a follow or a mute, and I treat it AS IF it were a NIP-77 formatted attestation. A follow is "interpreted" as a score of 100, and a mute is interpreted as a score of 0. And I give them a confidence of only 5% (a parameter than eventually the user will be able to adjust, if desired) because proxy trust data is low quality and ought to be given less weight than an explicit trust attestation.
If you think that some profile is worthy of higher-than-average attention in some context, for example: a wiki on Economics written by Lyn Alden is worth 10x more attention than some randomly selected non-bot author, and you are highly confident of that fact, then you can issue an attestation in the context of Economics, rating: 1000 (10-fold higher than 100), confidence: 80%. Or something like that. So the average user will have an Influence Score in the context of Economics of 1 (or a little less) based on follows, but Lynn will be one of only a handful of users with a score way higher than 1, bc she's been flagged by one or a few users as having special talent, worthy of your attention.
Bit of a tangent, but incidentally: I believe one of the key ways to convince the uninitiated of the virtues of this new world is to show how it doesn't deprive anyone of the (vampiric) features they are accustomed to and (think they) want. Example: The NY Times sets up a Nostr account with NIP-77 involved. They put their editors to work attesting trust and building up an enormous trust graph. They charge $[NY Times subscription amount] for "subscribers" to have access to this trust graph. The users/subscribers install some client (maybe one created by NTY) that by default assigns 100% trust and confidence in the NYT graph.
Bam, they have the same managed worldview as yesterday, but operating on a new substrate. (In fact, the nefarious activities of a propagandistic publisher are enhanced in this world. Not only can they determine which words you read - and therefore your opinions - but they can also determine which Wiki articles you see, which social network users you see, which Yelp reviews are "right", etc.) If freedom tech is working properly, it both supercharges freedom but also supercharges manipulation - BUT the manipulation is always opt-in and exitable.
Imagine being one of these "default client" users and then one day turning off the big filter and finding all sorts of new restaurants you'd never heard of, new comedians who actually make you laugh, high-quality news articles that make you question everything you had read previously. That's the world I want to live in... And for those who panic and turn the big filter back on, so be it. At least they know what they're doing and I have the tools to avoid them.
Regarding the NYT: you are 100% on target. This is exactly how we are going to attract the masses. Because WoT is the only way to prevent the manipulation that you describe. Yes, the NYT will pay for 100k bots to upvote it, but if those bots are not verified by my social graph, their influence score will be zero, which means their impact will be nullified. They may as well not exist. And sure, the NYT can instruct their editors and their community to upvote the NYT. But the Influence Score requires a weight for each attestation, and the weight is determined by the contextual influence score OF MY CHOOSING, and if I choose a score that proscriptively eliminates people who work for the NYT (sets that particular score to zero), then their little manipulative game is once again nullified.
btw, one of the reasons I keep bringing up the Influence Score in this thread is that it follows a similar format as a NIP-77 trust attestation in the sense that it is composed of three required fields: a context which is a string, a confidence which is an integer between 0 and 100, and a score which is also an integer. The only difference is that I have a slightly different interpretation of the score: I interpret a score of 0 as worthy of zero attention, and a score of 100 as worthy of the same amount of attention as you would give to any other randomly selected "real person" profile. Which opens the door for scores ABOVE 100, interpretation being that you think this profile is worthy of MORE attention than some randomly selected real person profile.
Just read the NIP again. A few questions:
The special value
*represents general trust in the person.
How about, just like score, leaving it undefined (meaning not sure) means general trust?
A Trust event is transitive by default (e.g. Alice trusts Bob, Bob trusts Charlie, therefore Alice trusts Charlie). Non-transitive Trust events MUST contain the
["transitive", "false"]tag.
Why is this? That's not at all how trust works in real life (friends of friends of friends means nothing to me) so should be non-transitive by default. That said probably nothing should be written about transitive trust, and be left to reads/computation of NIP-77 events.
A Trust event can be revoked by its author. Revoked Trust events MUST contain the
["revoked", "true"]tag.
This is a PRE so why not simple remove it instead of marking it as revoked?
This is a PRE so why not simple remove it instead of marking it as revoked?
Are you referring to NIP-9 for event deletion? I know PREs used to be described by NIP-33 but got moved to NIP-1. Is there a separate protocol to remove a PRE as opposed to replacing it?
This is a PRE so why not simple remove it instead of marking it as revoked?
Are you referring to NIP-9 for event deletion? I know PREs used to be described by NIP-33 but got moved to NIP-1. Is there a separate protocol to remove a PRE as opposed to replacing it?
What I mean is updating the 30077 event with no c, score or confidence tags, effectively replacing whatever was attested earlier.
What I mean is updating the 30077 event with no
c,scoreorconfidencetags, effectively replacing whatever was attested earlier.
That makes sense. In practice I imagine I will write code to interpret a 30077 event with no c/score/confidence tags as a deleted event that supersedes and revokes any older events with the same pubkey + d combination, which means that the revoked tag would in effect be optional, which raises the question of whether it would make sense to employ the revoked tag in the first place, given that it would be superfluous. If anyone uses it then we'd all have to write extra code to see if the revoked tag is present and true, so perhaps makes more sense not to use it.
Just read the NIP again. A few questions:
The special value
*represents general trust in the person.How about, just like
score, leaving it undefined (meaning not sure) means general trust?
I imagine I will probably write code to interpret '*' or a blank or absent context in the same way: they each refer to generic trust, the "superset" of all contexts. Perhaps both of these could be suggested in the NIP but not required, and we see how various devs decide to use it.
To me, the heart and soul of this NIP is simply that we should have 3 fields: context, score, and confidence. I'm OK with being open to the idea that different devs may find reasons to use / interpret / format these 3 fields in ways we might not necessarily foresee yet.
A Trust event is transitive by default (e.g. Alice trusts Bob, Bob trusts Charlie, therefore Alice trusts Charlie). Non-transitive Trust events MUST contain the
["transitive", "false"]tag.Why is this? That's not at all how trust works in real life (friends of friends of friends means nothing to me) so should be non-transitive by default. That said probably nothing should be written about transitive trust, and be left to reads/computation of NIP-77 events.
I would be in favor of the trust field being entirely optional. If absent, it will be left to the consumer of the attestation to decide how to interpret it.
To me, the heart and soul of this NIP is simply that we should have 3 fields: context, score, and confidence. I'm OK with being open to the idea that different devs may find reasons to use / interpret / format these 3 fields in ways we might not necessarily foresee yet.
💯