A suggestion to add an optional parameter representing the reference to a pre-agreed (or implicit) contract. This can either be an order id, a transaction id etc, or even the hash of the digital version of the contract document signed by the two parties involved.

We add the optional parameter as a special marker to the p-tag that contains the public key of the person being rated.

Usage scenarios:

1. Alice orders an item online. She uses the order id on her receipt to rate the seller. (In practice, the seller may provide the signed version of the order id for this purpose)

2. Bob uses a contractor to refurbish his house. They sign a written contract beforehand, the contract is scanned and the hash of the resulting digital document is used as the reference in the event/tag.

I'll be implementing this approach soon for nostr.directory: https://github.com/nostr-protocol/nostr/issues/20#issuecomment-913027389

Any feedback is appreciated, perhaps we can resurrect and formalize this NIP with datatypes as mentioned in the linked comment.

I don't know how you're going to do that, but I'm for it, sounds great.

Experiment with the best ways to format structure, once you reach a point that looks good we can NIP it.

Regarding reputation datatypes.

I think this should be a rating NIP, not a reputation NIP.

If it is one person's opinion about another person at a particular point in time it's a rating. Using the same structure (tags with domain-specific keys and 0-100 integer values), but specifying the pubkey of a restaurant vs a person in "p" tag, or even an event in a "e" tag covers multiple use cases. Rating a person, rating a restaurant, rating a recent post.

For me, reputation is the current state of how "trustworthy" or "good of a driver", or any other characteristic associated with a person. Reputation can be calculated from ratings from multiple people, or even a single authority if I trust them. This is closer to a Kind 0 metadata event in how a relay should handle it.

As an example of the relationship between rating and reputation: the movie Venom has a "movie review critic" score of 30% based on 364 professional reviews, but an audience score of 80% based on 25K+ user ratings. I trust the audience score more, because for me personally, the reputation of movie critics is to favour movies that are "high-concept" and serious, which I don't enjoy as much.

this is great https://github.com/nostr-protocol/nostr/issues/20

i would like designate a special "reputation type" for "claim verification". where you are asserting you have personally verified that a public key "is honest about what they claim". obviously you can lie. but a reputation system is a web-of-trust and liars eventually are ejected from the system

the idea is to prevent centralized identity systems from being invented or needed in the nostr ecosystem,

i'm thinking only 2 things:

• claims attached to a pubkey (part of profile data)
• verifications of those claims (signed message from anyone)
• revocation of claims (signed message from anyone)

example:

• i claim to be the official pubkey for the libertarian party of nh
• verification service with a high reputation signs a message confirming that
• other people can choose to use that service or not

claim-types can be standardized (individual full identity, organization identity, whatever)

Recommended changes:

All "Assign Reputation" events MUST have NIP-13 proof-of-work.

The amount of valid proof-of-work is the rating.

The content MAY contain a string comment.

The new rating tag MUST contain a string identifying ONLY 1 arbitrary category. It MAY have a second element that is a plus (+) or minus (-) to indicate whether the rating is good or bad, respectively. If the +/- is omitted, the rating is assumed to be good. This can be used to interpret the amount of proof-of-work as a signed integer.

The category SHOULD be all lowercase and have as few non-alphanumeric characters as possible to eliminate inconsistencies which may break rating aggregation.

For consistency in categorization, I recommend the following specs as well:

If the category is a verb, it MUST be the bare infinitive of a verb.

drive, not driving

cook, not cooking

If the category is a noun, it MUST be the singular noun.

If you are rating your friend's vehicle, you use car as the category, not cars.

If you are rating your friend's footwear, you use shoe, not shoes.

Other advice for categories:

Avoid abbreviations and acronyms: Labels should be written in their full form to prevent confusion and to maintain consistency. For example, use 'television' instead of 'TV'.

Use common and easily understood terms: Choose labels that are widely recognized and understood to prevent ambiguity. Avoid jargon, slang, or overly technical terms.

Adopt a standard format for compound words: Decide on a consistent format for compound words, such as using hyphens, spaces, or merging the words. For example, choose either 'ice-cream', 'ice cream', or 'icecream' and use it consistently.

Interpreting reputation is left up to clients: web-of-trust, fancy mathematics for weighting, etc.

Reputation assignments can be used to assess the assigner as well.

The sum of all assigned PoW multiplied by the average of all PoW creates a score for an assigner that tells you how active they are (sum) and how much effort they generally put in (average) in a single value. These calculations would treat all PoW as unsigned, for example.

Idea: Category suggestion feature based on categories already used in the wild, encouraging them to choose from established categories and reducing the likelihood of creating new, inconsistent categories.

Also, AI could be used to aggregate semantically similar categories.

proof-of-work

i feel like zaps are a proxy for pow. a "reputation-zap" contains real sats (real work) and can be as high or as low as you want. but pow is simpler. but it's also slow, and just as easy to game. i'd like to explore attaching structured JSON to a ZAP as a "reputation event".

pay-to-profile nip57 events seem like they can carry all the metadata needed if we want to add a "weight" to reputation scores.

still, i personally wouldn't care at all about a negative reputation someone posts about a good friend of mine - even if they paid 10k sats (or equivalent POW) to post a crappy review. social distance matters more to me, and i think it matters more to everyone.

thinking on this more: an attestation by a friend.... of any kind, should carry weight. an attestation by someone i dont know, regardless of how much they spend or how much proof of work there is, should carry no weight at all for most things

so i'm unconvinced proof of work matters more than network distance

here's my scoring mechanism:

reputation(ent) = sum(1/(distance(self, rater)**2) * score(rater, ent)) * sum(distance(self, rater)))xe 

where immediate friends are distance 1, and distance 0 is weight 10k

we do that, and i think we're good.

EXAMPLE:

entity A has been zero weight manual scored by me, as a 4, which essentially overrides everything ( i have a 10,000 weight)

entity B has been poorly rated by my friends, but a bunch of far-distance scammers gave him 5/5 score. it's ok, my friends win.

squared distance weights is a mathematically robust solution to reputation weightings that takes into account the typical topology of social networks.

now we can use a simple signed tag-value reputation score, and it will properly account for my social network

also, i've run in to two other issues with reputation:

1. fairly sure we want reputation events to (typically? optionally?) use NIP-33, and be replaceable
2. very sure we need the ability to store private reputation scores (i don't want other people to know my opinion, but i want to record it and have it used in any client-side algo's that apply to me)
3. might want to formalize "scores" and not just make it fully application specific (or at least have it so that any numeric field named "score" has a suggested aggregation)
4. POW stuff could be optional and this could be included in the spec... enabling POW sums to accumulate

#2 comes into play a lot when you work with pseudonyms, etc.

Closing as superceded by #532