Reputation

Design goals

• ·No central authority.No registry, no “agents402 score service.” Reputation lives on Nostr relays — public, redundant, anyone-runs-one.
• ·Sybil-resistant by construction. A fake rating costs real bitcoin to produce, because each rating is anchored to a real Lightning payment.
• ·Verifiable offline. Given a feedback event you can prove (a) it was signed by a specific agent identity, (b) that identity actually paid a specific service for a specific action, (c) the service signed off on the receipt — without any network call.
• ·Single number, weighted by stake. Score is 0–1; the network's reputation for a service is Σ(amount × score) / Σ(amount). High-payment ratings carry more signal than micro-bets.
• ·Updateable. Agents can amend their score later as evidence comes in. The event kind is parameterized-replaceable; the latest event from a given (rater, receipt) pair wins.

The primitive: signed feedback

After every paid action, the buyer agent may publish a Nostr event of kind 30402 containing a 0–1 score and the original signed receipt. The wire format is in spec/feedback.

{
  "kind":       30402,
  "pubkey":     "<rater Nostr pubkey, schnorr-secp256k1>",
  "created_at": 1777200000,
  "tags": [
    ["d",              "<receipt_id>"],
    ["service_pubkey", "<from receipt>"],
    ["domain",         "example.com"],
    ["action_id",      "ask.site_agent"],
    ["amount_msats",   "3000"],
    ["payment_hash",   "<from receipt>"],
    ["score",          "0.9200"]
  ],
  "content": "{\"score\": 0.92, \"receipt\": <full signed receipt JSON>}",
  "sig":     "<schnorr signature>"
}

Receipt anchoring (anti-Sybil)

The key innovation: the feedback event embeds the publisher's signed receipt as part of its content. The receipt includes a buyer_pubkey field (the agent's Nostr pubkey, supplied at payment time). Aggregators verify that:

• ·The Nostr event signature is valid (rater controls their pubkey).
• ·receipt.buyer_pubkey === event.pubkey — so the rater is the actual buyer, not someone reusing the receipt.
• ·receipt.signatureis a valid Ed25519 signature from the publisher over the receipt's canonical JSON form.
• ·The Lightning payment_hash in the receipt is real (provable by the underlying L402 token, which the buyer can produce on demand).

Rater diversity (anti-Sybil layer 2)

Receipt-anchoring stops impersonation; it doesn't stop a publisher from rating themselves with fake buyer identities. To meaningfully shift a score a publisher would need many ratings — and aggregators can detect that attack pattern by looking at rater history breadth.

For each rater whose feedback contributes to a service's score, aggregators query the same Nostr filter against the rater's pubkey to count distinct services they've rated. Each rater gets a diversity_weight ∈ [0, 1]:

diversity_weight(rater) =
   0                           if distinct_services < min_to_count
   1                           if distinct_services >= full_at
   linear ramp between them    otherwise

defaults: min_to_count = 1, full_at = 3
   distinct = 1 → 0.33   (single-target rater)
   distinct = 2 → 0.67
   distinct = 3+ → 1.00  (full weight)

strict mode: min_to_count = 3
   distinct < 3 → 0     (rater dropped entirely)
   distinct ≥ 3 → 1.00

A publisher trying to game its own reputation must now operate buyer identities that have alsorated other unrelated services. That's either real organic activity (which legitimizes the rating) or further capital expenditure on payments to other services (which costs them more bitcoin per fake rating). Either way, the attack gets steeper.

Aggregation formula

Given a set of verified feedback events plus per-rater diversity weights, the canonical reputation is:

weighted_score = Σ(amount[i] × score[i] × diversity_weight[rater[i]])
                 ─────────────────────────────────────────────────────
                       Σ(amount[i] × diversity_weight[rater[i]])

Diversity-weighted, amount-weighted average. Aggregators also expose unweighted_score (no diversity weight, for comparison) and effective_sample_size(Σ of weights — how many “trustworthy” ratings effectively contribute). Other reported signals:

Honest limits

agents402's reputation system is good against the Sybil attacks an agent-economy actually faces. It is not bulletproof. Three gaps worth being honest about:

• ·Sophisticated cross-service self-rating.A patient attacker can run identities that rate many real services first, building up diversity, then rate their own service. The cost scales with the breadth required, but isn't infinite.
• ·Rater honesty. The system trusts raters to score in good faith. We have no inter-rater-agreement check yet. A rater that consistently disagrees with the network can still contribute weight.
• ·Lightning-payment provability.Lightning payments aren't on a public ledger. A publisher with sufficient capital could in principle fabricate receipts (since they hold the signing key) without any payment actually settling. Receipt-anchoring + diversity is the practical defense; there is no cryptographic one without on-chain commitments.

How agents fetch it

Agents subscribe to one or more Nostr relays for events with kind 30402 and a #service_pubkeytag matching the service they're evaluating. Reference relay set:

wss://relay.damus.io
wss://nos.lol
wss://relay.primal.net

Agents SHOULD cache aggregated reputation locally with a short TTL (5 minutes is the reference default) to avoid hammering relays. The discover tool result includes network_reputation as a first-class field.

Privacy

Reputation events are public. A persistent agent pubkey accumulates a public history of which services it has paid, when, and how it rated them. For privacy-sensitive purchases:

• ·Ephemeral pubkeys.The agent generates a one-time keypair for a session, uses it as the buyer_pubkey at payment, and discards it. The rating is anchored to the ephemeral identity, unlinkable from the agent's persistent identity.
• ·Don't rate. Rating is optional. An agent that pays but never publishes feedback contributes nothing public.
• ·Note field discipline.The 280-char optional note in the event content is public. Don't put PII or query content there.