From 37741f7ecb8e81fad5bca6ff73730b6c07ddceb3 Mon Sep 17 00:00:00 2001 From: Vlad Stan Date: Tue, 13 Jun 2023 17:41:33 +0300 Subject: [PATCH] doc: initial commit --- 320.md | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 320.md diff --git a/320.md b/320.md new file mode 100644 index 00000000..8311aea3 --- /dev/null +++ b/320.md @@ -0,0 +1,80 @@ +# Nostr Rating Mass + +## 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](https://gist.github.com/motorina0/874912282d2419be4eaf89de8d0c4464?permalink_comment_id=4597165#gistcomment-4597165)). + +## 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](https://gist.github.com/motorina0/874912282d2419be4eaf89de8d0c4464?permalink_comment_id=4597165#gistcomment-4597165)), but to an impartial, decentralized system (like the bitcoin blockchain). + +### Rating Mass +A user can register its `public key` in a [Merkle tree](https://en.wikipedia.org/wiki/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](https://opentimestamps.org/) 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/2``n` where `n` is the depth - starting at `0`). + +The properties of the tree are: +- Each leaf is of the form: `[, , ]`. +- Leaves can exist at any level. The closer to the tree root a leaf is, the more valuable it is. + +
+ +![rating-points-tree drawio(4)](https://user-images.githubusercontent.com/2951406/245187057-bb6ba330-e766-4c59-9519-1f2b09b4501c.png) + +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/2``2` + `2 * 1/2``4` + `4 * 1/2``5`), whereas public key `1acf...` (purple rectangles) has purchased `3 rating options` with a mass of `0.1875` (`3 * 1/2``4`). 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](https://github.com/nostr-protocol/nips/pull/532)), 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/2``5`). 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/2``1`, more intense). + + +### Using Rating Mass in Nostr +Ratings in `nostr` can be achieved by publishing a particular event (see this [NIP-32 PR](https://github.com/nostr-protocol/nips/pull/532) 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)](https://github.com/nostr-protocol/nips/blob/master/33.md) and have these additional tags representing the `rating mass`: + +```json +{ + "kind": 30030, + "pubkey": , + "tags": [ + ["tx-id", ], + ["output-index", ], + ["leaf", , , ], + ["leaf-path", , , ...], + ["d", , , , , , ...)>], + ... + ], + "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](https://github.com/nostr-protocol/nips/blob/master/33.md) 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 \ No newline at end of file