Nostr Rating Mass

[motorina0]

Note

• below the full content of the PR document can be found
• initially posted as a gist here

---

Problem

Ratings give the reputation for a person, service or product. They are important for creating an open and free-market.
It helps participants make decisions based on what their peers previously experienced with that person, services or product.

Having a rating system in an open and decentralized system (like nostr) is hard because anyone can join and give ratings.
Thus bots will be created to overtake the honest human's votes.

Some solutions have been proposed for this problem, but none of them is satisfactory (see first comment).

Suggested Solution

In order to avoid spam, each rating must have associated with it the proof that a tiny fee has been paid. The fee should not be paid to a centralized service that can cheat (see first comment), but to an impartial, decentralized system (like the bitcoin blockchain).

Rating Mass

A user can register its public key in a Merkle tree and the root of the tree is then persisted (by a specialized service) on the bitcoin blockchain using the OP_RETURN operator (thus paying a fee). Similarly with what open-timestamps does.

If the public key is registered as the root of the tree then the rating mass is 1, if it is registered on the second level then the rating mass is 1/2 (there can be two leaves). The lower one goes in the tree, the more leaves it can register, but also the less each leaf is worth (rating mass is 1/2n where n is the depth - starting at 0).

The properties of the tree are:

• Each leaf is of the form: [<tree-level>, <leaf-index>, <public-key>].
• Leaves can exist at any level. The closer to the tree root a leaf is, the more valuable it is.

---

Highlighted in the image is the path to leaf [4, 0, a728...] which is composed of 4 elements: [hash([4,1,a728...]), H2, H7, H9]. This path has a rating mass of 1/4.

For the above example (image), the public key a728... (yellow rectangles) has purchased 9 rating options with a total mass of 0.8125 (2 * 1/22 + 2 * 1/24 + 4 * 1/25), whereas public key 1acf... (purple rectangles) has purchased 3 rating options with a mass of 0.1875 (3 * 1/24). The total mass of the tree will always be 1 (eg: 0.8125 + 0.1875), because everybody knows that 1+2+4+⋯+2𝑛 = 2𝑛+1 - 1.

Rating Mass is not the Rating Value

The rating value can be an integer between 1 and 5, or it can be a float between 0 and 1 (see this NIP-32 PR), or any other rating system.

The rating mass represents the importance or intensity that a user gives to a particular rating. It also guarantees that the rating is not spam.

For example I might dislike a film and give it a rating value of 2 stars and a rating mass of 0.03125 (consume a leaf on level 5 of the tree: 1/25). Or I might dislike that the Uber driver just dropped me off in a bad neighborhood and give it a rating value of 2 stars, but a rating mass of 0.5 (consume a leaf on level 1 of the tree: 1/21, more intense).

Using Rating Mass in Nostr

Ratings in nostr can be achieved by publishing a particular event (see this NIP-32 PR to get an idea of how the event could look like) and attaching a rating mass to the event.

This rating event should be a Parameterized Replaceable Events (NIP-33) and have these additional tags representing the rating mass:

{
  "kind": 30030,
  "pubkey": <public key of the event creator>,
  "tags": [
    ["tx-id", <id of the transaction where the `OP_RETURN` was included>],
    ["output-index", <index of the `OP_RETURN` output>],
    ["leaf", <tree-level>, <leaf-index>, <public-key of the event creator>],
    ["leaf-path", <hash1>, <hash2>, ...],
    ["d", <hash(tx-id, output-index, <tree-level>, <leaf-index>, <public-key>, <hash1>, <hash2>, ...)>],
    ...
  ],
  "content": "...",
  ...
}

The d tag is the most important one because it aggregates all the other values and because it is the one used to replace the NIP-33 event. This means that the same leaf cannot be used in two different rating events. Trying to reuse the leaf will simply replace the previous rating event. On the other hand, if I have "consumed" one of my ratings for liking a song that I later discover it was plagiarised then I can take that rating back and reuse it one something else.

Note
The public key in the leaf must be the same as the public key of the event creator.

Note
Rating events without a rating mass or which have a very long path (are almost free) should not be taken into consideration

Next Steps

• detailed doc for the tree structures

• create a services that allows users to buy rating mass

  • the user selects the levels it wants to register it public key at
  • the services computes the cost
  • the user pays the invoice and receives the full tree

• create a service that computes ratings based on the rating mass assigned to each rating event

  • this can be part of the relay, or a standalone service

• integrate with social media clients, market clients, etc

[arthurfranca]

Ok reposting here as asked:

@motorina0 very clever math. Maybe I misunderstood but isn't this creating a system where only rich people ratings matter?

Unless when I buy an item or use some service, the store/service provider use part of the money to buy me a rating mass tree leaf/root registration.

But yet how do we stop a rich person from buying many rating mass tree root registrations and creating fake positive ratings to his crappy product or fake negative ratings to a good competitor product?

[staab]

Payments complement nostr, but should not be hard dependencies. This should be implemented using NIP 13's proof of work specification, or orthogonal to use case (i.e. an additional tag that can be attached to any event, and includes a proof of payment). Web of trust is a better solution for sybil resistance anyway.

[protocoel]

Ok reposting here as asked:

@motorina0 very clever math. Maybe I misunderstood but isn't this creating a system where only rich people ratings matter?

Unless when I buy an item or use some service, the store/service provider use part of the money to buy me a rating mass tree leaf/root registration.

But yet how do we stop a rich person from buying many rating mass tree root registrations and creating fake positive ratings to his crappy product or fake negative ratings to a good competitor product?

Exactly what I was thinking. Also, there's no inventive for others to pay to rate a Nostr profile. Except for the profile owner themselves to pay to rate themselves.

And for products and services, the ratings can be gamed in a system like by the established player, which is a terrible thing for new entrants isn't it?

[motorina0]

@arthurfranca

But yet how do we stop a rich person from buying many rating mass tree root registrations and creating fake positive ratings to his crappy product or fake negative ratings to a good competitor product?

This is a very good point, someone with a high budget can indeed buy a large rating mass and try to game the system.

It is important to remember that each rating mass must reference a public key and only that public key can use the purchased rating mass.

The service that computes the ratings (based on mass and value) is not necessarily a "dumb" aggregator. It can implement some heuristics to eliminate/reduce bad actors. This service can be on the client side or on a 3rd party server side.

Some basic heuristic examples:

• red flags:
  • a public key with no activity that purchased a high rating mass and starts rating stuff
  • a public key that gives high value, high mass ratings to an obvious scam
  • a public key that tries to reuse the rating mass frequently
• positive flags:
  • a public key that has received many positive ratings (itself or the events it posted)

The spammer can either:

• create many fresh public keys but with low credibility
• or invest more funds and try to build "good reputation" public keys, but risk loosing all the rating mass if discovered

This solution is not a silver bullet, but it can slow down spammers and make it more risky to get in the business.

[ecdsa]

I had a similar idea about 8 months ago, just before I heard about Nostr. I wrote the following whitepaper that describes my idea tweethash.pdf.

I did not publish my whitepaper, because I later discovered a vulnerability in it (and also because I found about nostr). However, I notarized the sha256 of that pdf on the Bitcoin blockchain, see transaction 97b977431657acf9eb91f1852bdea263a0359e6ffa3956064e037bbbd42eeddd

The vulnerability I discovered is that miners can trivially cheat the system, by notarizing very large trees for free. The only solution I found to avoid that is to burn the coins in the OP_RETURN output, instead of paying mining fees. However, that makes the whole thing unpractical, since one also needs to pay mining fees.

[motorina0]

@staab

Payments complement nostr, but should not be hard dependencies.

• I agree, but I do not consider rating mass to be a hard dependency, it is optional

This should be implemented using NIP 13's proof of work specification, or orthogonal to use case (i.e. an additional tag that can be attached to any event, and includes a proof of payment).

Some problems with NIP-13 PoW by client:

• it is not practical on mobile devices, it can drain the battery and make the device hot and slow
• older devices are disadvantaged
• at some point a sort of difficulty adjustment will have to be introduced. The difficulty today will simply be too low in a few years (decades?) to block the spammers. This means that posts made today can be flagged as spam in the future (created_at can help, but it is not guaranteed).

Some problems with NIP-13 Delegated PoW:

• it must be requested on the spot (after the event is built and the id known). It cannot be bought in advance.
• same issue with difficulty adjustment
• this equation is true 1 sat = PoW with difficulty adjustment

Web of trust is a better solution for sybil resistance anyway.

• web of trust works well 2 or 3 levels down, but it just grows exponentially. WoT can be complimentary to rating mass.
• if we assume each participant has only 100 friends, then:
  • my direct friends: 100
  • second level friends: 10 000
  • third level friends: 1 000 000 <- it just gets very hard to query and compute at this level or below
• if I visit amazon.com, I would hardly find reviews from any of my first or second level friends

[motorina0]

@ecdsa

The vulnerability I discovered is that miners can trivially cheat the system, by notarizing very large trees for free.

• nothing is free, if the miner decides to include an OP_RETURN output, then it uses block-space that it could otherwise have sold for sats
• a very large tree can be built (and include a lot of data), but it does not have to be a balanced tre. The level on which a leaf is located is relevant.

[motorina0]

@protocoel

And for products and services, the ratings can be gamed in a system like by the established player, which is a terrible thing for new entrants isn't it?

• can you please detail on the the established player?

[ecdsa]

• nothing is free, if the miner decides to include an OP_RETURN output, then it uses block-space that it could otherwise have sold for sats

In my proposal, this cost is small compared to the actual mining fee (see section 'overpaying the miners').
Maybe you will find a better way to do that; I am providing my paper so that you don't end up with the same vulnerability.

• a very large tree can be built (and include a lot of data), but it does not have to be a balanced tre. The level on which a leaf is located is relevant.

Exactly the same idea, see page 3: "the trees created by notaries are not balanced"

[staab]

If this is useful (I can't tell if it works or not), could it be generalized to cover all note types, rather than just ratings? It seems like it would be nice to be able to prove payment for regular notes, DMs, etc as well.

[motorina0]

If this is useful (I can't tell if it works or not), could it be generalized to cover all note types, rather than just ratings? It seems like it would be nice to be able to prove payment for regular notes, DMs, etc as well.

The d tag as interpreted for NIP-33 events has the nice property that a rating mass (a leaf in the tree) cannot be double-spent (use it for two different reviews at the same time).

Other event types (non NIP-33) would allow the rating mass to be reused for multiple events.

[protocoel]

@protocoel

And for products and services, the ratings can be gamed in a system like by the established player, which is a terrible thing for new entrants isn't it?

• can you please detail on the the established player?

An established player is an existing product company in the market with enormous capital accumulated over the years, this person have the money to spam new entrants in the market with bad reviews.

[motorina0]

An established player is an existing product company in the market with enormous capital accumulated over the years, this person have the money to spam new entrants in the market with bad reviews.

OK, then the answer is the same as in this comment

[dadofsambonzuki]

I don't like pinning the weight of a rating to ones ability to pay.

I would like to see the weight of a rating a function of the network graph of an npub.

[motorina0]

I don't like pinning the weight of a rating to ones ability to pay.

• why not?
• for an individual it can be a tiny amount (order of millisats)
• for a spammer it adds up to high amounts and it has no guarantee that it will work (if it gets black-listed)

I would like to see the weight of a rating a function of the network graph of an npub.

Assume

• on average an npub has only 100 friends
• and I want to compute to graph the 5th degree

How many npubs would I have to take into consideration?

[earonesty]

I see no reason why a simple web of trust tree using kind 3 follower sets and inverse squared social distance as a proxy for mass isn't superior to this proposal

it solves all of the problems you listed in the comments, without any tie-ins to purchasing reputation

[motorina0]

I see no reason why a simple web of trust tree using kind 3 follower sets and inverse squared social distance as a proxy for mass isn't superior to this proposal

it solves all of the problems you listed in the comments, without any tie-ins to purchasing reputation

Here are some reasons:

Too much data

It is just too much data. Here is a back-of-the-napkin computation (I might be wrong, please correct me):

• I open my social media client and the first post loads (it has 256 "likes")
• my software has to compute using the social-graph how many of these "likes" are real
• by real we mean that the like belongs to an npub in my social graph
• lets say that we consider connections relevant up to level 3 (level 1: direct fried of mine, level 2: friend of a direct friend, ...)
• also assume that each npub only has 100 (unique) friends (in reality it is higher)
• then the total number of npubs in my social-graph is 1003 = 1 000 000
• for each of the original 256 likes I have to iterate over my social graph and check if it is part of it
  • the npubs can be sorted and use a divide-et-impera search (which is much faster)
• for each of the posts that is loaded I have to repeat the above computation

Bots can be friends

• one of the npubs in my social-graph can be tricked to have a BOT as a friend
• the bot can then have a large number of bot friends which become part of my social-graph and are therefore considered valid
• the scoring is no longer relevant

Excludes valid npubs

• "likes" from real people which are not part of my social graph are excluded
• this is not desirable

Markets and other use-cases

• the social-graph is not relevant for other usecases (like nostr-markets)
• there is a small chance that some one in my social graph has rated some products that I'm interested in

[earonesty]

• too much data

yes, this is why we run a service that can compute weight-on-request for mobile clients. it maintains a social graph for "everyone", and then can reply quickly when someone wants to know the aggregate scores for a set of events.

• bots can be friends

yes, however every node should have equal weight at its point in the tree. having a billion followers at a distance 2 is the same as having one. a single bot friend can only contribute singly. it will be one friend out of many and its recommendation weight cannot be higher

• excludes valid npubs

imo. this is desirable. there can be no meaningful difference between a fully unknown npub and spam, however "paid for". i suspect there's also no such thing as a disconnected real person. we're all 6 degrees of separation from each other. add some more friends to get a better score.

• markets

this is literally what we're using it for. it's perfect. incredibly useful to take marketplace NIP-32 scores and aggregate them in this way

[motorina0]

yes, this is why we run a service that can compute weight-on-request for mobile clients

• sooner or later someone will have to pay somehow for this service (just like for relays)
• will this service know every post/product/services that I'm interested in (because I want to know its rating)?

yes, however every node should have equal weight at its point in the tree

• ok, this can be mitigated

imo. this is desirable.

• it is also desirable too see how popular something is (eg: for a video with 1 billion likes I could only see 300 likes)

there can be no meaningful difference between a fully unknown npub and spam.

• there can be if the "unknown npub" pays a tiny cost (millisats) to rate

• market
  this is literally what we're using it for. it's perfect. incredibly useful to take marketplace NIP-32 scores and aggregate them in this way

• I'm also working on a nostr marketplace (based on NIP15): https://github.com/lnbits/nostrmarket
• that is the reason why I'm interested in a decentralized rating system

Let me give you and example of how the social graph (didn't) work for me:

• last month I have bought this device from Aliexpress
• 
• 45 reviews, high score
• I went to check who the reviewers were:
  • 
  • not only that I know none of the reviewers, but there are zero from my country

Maybe there are not so many orders from my country, or maybe I have few friends, but social graph does not seem to work. I have repeated the test (only first level friends) on airbnb, booking.com and emag.ro (local amazon), same result.

I challenge you to check your last 5 products purchased online and try to manually build a social-graph and get a relevant review.

PS: what market are you building?

[earonesty]

• sooner or later someone will have to pay somehow for this service (just like for relays)

yes we will probably have a free in-app version that goes 3 levels deep and charge for "deeper", more comprehensive ratings (but still based on your graph)

• will this service know every post/product/services that I'm interested in (because I want to know its rating)?

only stuff that's been rated via NIP-32 or stuff sold by someone with an NPUB key

• it is also desirable too see how popular something is (eg: for a video with 1 billion likes I could only see 300 likes)

yes, we can have different scores for popularity, versus trust. as a marketplace, we're primarily concerned with trust.

• there can be if the "unknown npub" pays a tiny cost (millisats) to rate

no, because there's far more profit to be made fake-rating things than truth-rating things. the incentive model "pay to rate" is totally broken. you get nothing if you're honest, and you make $$$ if you lie.

• I'm also working on a nostr marketplace (based on NIP15): lnbits/nostrmarket

we're not using nip15. we're using a social-chat/telegram-style market:

this is outdated, but the basic idea is "anyone can post something for sale" using structured tags in the post:
https://github.com/ArcadeLabsInc/arcade/wiki/ArcTrade

there are no "stalls or stores", just people and channels

• that is the reason why I'm interested in a decentralized rating system

agreed, we are too, and i acknowledge there can be isues

Maybe there are not so many orders from my country, or maybe I have few friends, but social graph does not seem to work. I have repeated the test (only first level friends) on airbnb, booking.com and emag.ro (local amazon), same result.

but you cannot test 7 levels deep. because it's too difficult. but our server goes 7 levels now using nostr's existing graphs. and i see very few isolated graphs. and the ones that are are almost all based on language, region... or are isolated by bots & spam. (at 7 levels you basically have 100% coverage).

I challenge you to check your last 5 products purchased online and try to manually build a social-graph and get a relevant
review.

well, my wife has a massive social footprint, and she does all the shopping, and uses instagram a lot, so it's probably not a fair comparison. maybe it will work better for some that others.

i think if there's no connection, we should look for highly trusted nodes that are adjacent to your network, and then recommend them as "possible follows" when you start the app. so you can bootstrap into a better network.

[motorina0]

yes we will probably have a free in-app version that goes 3 levels deep and charge for "deeper", more comprehensive ratings (but still based on your graph)

• this is like me googling: "What is the rating for this product?"
  • google tracks all my searches and builds a profile of what I prefer.
  • wouldn't this "free" service have the same capabilities?

no, because there's far more profit to be made fake-rating

• there is also more risk for the cheeter. Once a pubkey is marked at "fake" all its ratings are nullified (loses money).

the incentive model "pay to rate" is totally broken

• the incentive for "pay to view score" already exists. It is called google ratings. I pay with my privacy.

but our server goes 7 levels now using nostr's existing graphs.

• 7 levels deep is ~100% of the population, so its like having no filter/graph
• "bot friends" issue comes into play

[nostronaut]

The problem of subjective reputation is stated, as bots sybil-attacking with a very large number of accounts and overtaking the reputation system

The solution proposed involves creating a scarce resource from mining fees (an external resource), that can be used to weight the vote (rating mass) and then on a second layer have the vote itself (rating value) (both rating mass and rating value are subjective and picked by the user, and besides of semantics, its not clear why they need to be separate)

again, an external resource, here bitcoin, needs to be spent in order to buy the rating votes, that can be later dispersed. This makes the proposed protocol strongly coupled with bitcoin for a highly specific, non-generic, usecase, and that typically is not so good. Composing the rating vote proposal with the zap protocol would be a more typical solution.

[nostronaut]

Below is an alternate way of looking into the reputation problem.

our assumption is: the native asset of a social network is the reputation of its users itself, that is decorrelated, non-sybil accounts monitoring and interacting with each other over large periods of time

staking reputation as a scarce resource may be a better fit for this problem, as it is the native asset of a social network

then the issue is how to bootstrap reputation in order to stake it to create such a system.

we have a rough sketch of such a proposal on issue #419

it makes each user behave like a signing oracle with a single, linear history that they stake over time, similar to how a blockchain does

[motorina0]

@nostronaut

both rating mass and rating value are subjective and picked by the user, and besides of semantics, its not clear why they need to be separate

• see explanation at Rating Mass is not the Rating Value

This makes the proposed protocol strongly coupled with bitcoin for a highly specific, non-generic, usecase, and that typically is not so good.

The protocol assumes:

• a cost for rating
• bitcoin as the dominant online payment method

Therefore "strongly coupled" with bitcoin is not an issue.

we have a rough sketch of such a proposal on issue

• there are some technical terms that I do not understand, can you please do a TLDR