Coordinator ratings over Nostr

[KoalaSat]

Is your feature request related to a problem? Please describe. Currently, Robosats offers a 5-star rating at the end of the order process. However, this information is static data that resides and remains within the coordinator system. A more reliable solution would be to enable users to independently send their ratings directly to the federation. To ensure the legitimacy of ratings, the federation can also use the dev-fund payments as a method to prevent users or coordinators from creating ratings for free and avoid rating improvement through brute force.

Describe the solution you'd like The idea is to utilize the Nostr as an independent network where none of the three parties have control. The proposed flow is:

1. A transaction is finished successfully
2. The Coordinator ask to the dev-fund node to create an invoice with the assigned donation, this invoice will additionally include:

• Robot's public key
• Order's unique identifier
• Coordinator's unique identifier

3. The Federation receives this payment and stores the information described above.
4. The user decides to rate the coordinator with a 5-stars system.
5. The webapp creates a new Nostr note and send it to the Nostr network:

{
    "id": "675bab...8c1221",
    "pubkey": "bf2376...26bce",
    "created_at": 1673347337,
    "kind": 1986,
    "tags": [
        ["p", "bf2376...26bce"],
        ["p", "6fb4d86...ade63da"],
        ["subject", "123"],
        ["rating", "3"],
        ["L", "review"],
        ["l", "review/coordinator", "review"],
    ],
    "content": "nostr:npub...hxs64d8 was rated with 3 stars",
    "sig": "6fb4d8...a329186"
}

• pubkey: Robot's pubkey
• content: Formatted rating to be easily displayed by a Nostr client
• tags:
  • p: Federation pubkey
  • p: Coordinator pubkey
  • subject: Order unique identifier
  • rating: User's rating

6. When the Federation detects a new 30078 message including its public key, it will verify the sig. Subsequently, it will map Coordinator's pubkey to the Coordinator unique identifier and use it together with subject and pubkey values to search for this information in the data stored during step 2. I believe it's important to keep a maping between coordinator pubkey and unique identifier to restrict Coordinators to easily switch pubkey if the rating is bad.
7. If the Federation identifies a match and no similar note has already been submitted to Nostr, it will proceed to create and send a new note:

{
    "id": "675bab...8c1221",
    "pubkey": "bf2376...26bce",
    "created_at": 1673347337,
    "kind": ?,
    "tags": [
        ["e", "6fb4d86...ade63da"],
        ["p", "6fb4d86...ade63da"]
    ],
    "content": "",
    "sig": "6fb4d8...a329186"
}

• pubkey: Federation's pubkey
• tags:
  • e: Robot note id
  • p: Coordinator pubkey

8. The webapp will be able to fetch and filter notes by a Coordinator's pubkey ["p", "6fb4d86...ade63da"] or use["rating", "3"] to count by rating value. Additionally clients can display Federation's validation so an user can choose to trust or not on the Federation.

Describe alternatives you've considered There was an initial proposal where the coordinator was involved on the validation of the note, but that would allow to block bad ratings.