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. An order is closed successfully
2. The Coordinator will send a Zap Request Event (https://github.com/nostr-protocol/nips/blob/master/57.md#appendix-a-zap-request-event) to the dev-fund server, this request event will point out to the p2p order event (NIP-69) originally posted on the global order book, and will follow the standard zapping process:

{
  "kind": 9734,
  "content": "",
  "tags": [
    ["amount", "21000"],
    ["lnurl", "lnurl1dp68g...2x9xp"],
    ["p", "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"],
    ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"]
  ],
  "pubkey": "97c70...05ad98e322",
  "created_at": 1679673265,
  "id": "30efed5...4b7d93",
  "sig": "f2cb581a84ed...374d9d"
}

• pubkey: Coordinator's pubkey
• tags:
  • p: Federation pubkey
  • e: P2P order event id

4. The Federation receives the Zap and publish the Zap receipt event https://github.com/nostr-protocol/nips/blob/master/57.md#appendix-e-zap-receipt-event:

{
    "id": "67b48a14f...dda446",
    "pubkey": "9630f464cc...48238f31",
    "created_at": 1674164545,
    "kind": 9735,
    "tags": [
      ["P", "97c70a44366a6...64705ad98e322"],
      ["e", "3624762a1274d...e836a1eaf86c3b8"],
      ["bolt11", "lnbc10u1p3...hnqpy6gyf0"],
      ["description", "{...zap event...}"],
      ["preimage", "5d006d...99f97344c15f"]
    ],
    "content": "",
  }

• pubkey: Federation's pubkey
• tags:
  • P: Coordinator pubkey
  • e: P2P order event id

5. The user decides to rate the coordinator using a 5-stars system.
6. 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"],
        ["d", "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
  • d: Order + Coordinator unique identifier. Same as the one used in order's nostr event.
  • rating: User's rating

7. 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 receipt zap as a validation of a legit order.

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.

[bitcoinpirate]

Hi @KoalaSat , I am thinking about implementing this. When you mention Federation are you talking about a set of coordinators? How would they share publickey?

From my understanding the devfund donations are currently implemented using keysend like so:

robosats/api/tasks.py

Lines 93 to 138 in 054093d

	def send_devfund_donation(order_id, proceeds, reason):
	"""Sends a fraction of order.proceeds via keysend as
	donation to the RoboSats Open Source project devfund.
	"""
	from decouple import config
	from django.contrib.auth.models import User
	from api.lightning.node import LNNode
	from api.models import LNPayment, Order
	from api.utils import get_devfund_pubkey
	target_pubkey = get_devfund_pubkey(config("NETWORK", cast=str))
	order = Order.objects.get(id=order_id)
	coordinator_alias = config("COORDINATOR_ALIAS", cast=str, default="NoAlias")
	donation_fraction = min(1.0, max(0.00, config("DEVFUND", cast=float, default=0.2)))
	message = f"Devfund donation; {coordinator_alias}; {order}; {donation_fraction}; {reason};"
	num_satoshis = int(proceeds * donation_fraction)
	routing_budget_sats = int(max(5, num_satoshis * 0.000_1))
	timeout = 280
	sign = False
	valid, keysend_payment = LNNode.send_keysend(
	target_pubkey, message, num_satoshis, routing_budget_sats, timeout, sign
	)
	if not valid:
	return False
	lnpayment = LNPayment.objects.create(
	concept=LNPayment.Concepts.DEVDONAT,
	type=LNPayment.Types.KEYS,
	sender=User.objects.get(
	username=config("ESCROW_USERNAME", cast=str, default="admin")
	),
	invoice=f"Target pubkey: {target_pubkey}; At: {keysend_payment['created_at']}",
	routing_budget_sats=routing_budget_sats,
	description=message,
	num_satoshis=num_satoshis,
	order_donated=order,
	**keysend_payment,
	)
	order.log(
	f"Development fund donation LNPayment({lnpayment.payment_hash},{str(lnpayment)}) was made via keysend for {num_satoshis} Sats"
	)
	return True

. Those aren't seen by anyone in the Federation except the devfund node. The donations should be public in my opinion so step 7 could be verified independently. I think it could be achieved by using nostr zaps https://github.com/nostr-protocol/nips/blob/master/57.md .

Is there currently any verification that the coordinators are paying their devfund donations as they advertise? I think this would be important to ensure that the user can give a review.

[KoalaSat]

Hi @bitcoinpirate thanks for checking this issue!!

As you said, the federation is the group of coordinators. So far the only thing they shared was:

• The frontend federation file (where you can find their pubkeys)
• The DevFund node where they were sending their donations

With the next release (v0.7.2-alpha) they will be also share a global orders book over nostr (NIP-69) with a STRFRY interconnected network #1362

Using zaps as donation to keep a registry of it is an awesome a idea, as you said, the only one who can validate this right now is the DevFund internally. I'm going to work on changing the definition of this issue to include it.

[KoalaSat]

I updated the flow using Zaps and honestly now it looks way simpler, thanks for the idea!

[KoalaSat]

Final proposal merged #1869