Emit reputation attestations for verified outcomes #88

Closed AtlantisPleb opened this 23h ago 1 comment

Outcome

Emit portable, revocable reputation attestations for accepted outcomes without turning reputation into a global social score.

Current behavior

Issues can show work and receipt evidence, but no signed event lets another client verify that an actor completed a particular accepted outcome under a named policy.

Source: docs/episode-triage.md, episodes 209, 259, and the batch 5 NIP-32 integration note.

Contract

Bind each attestation to issuer, subject, accepted outcome, artifact digest, verifier policy, confidence, timestamp, and evidence references.
Issue only after the accepted-outcome contract reaches an admitted terminal state.
Distinguish completion, verification, review, payment, reversal, and revocation events.
Let skeptical clients verify signatures, policy versions, evidence availability, and revocation.
Publish through the forge API first; add a Nostr event representation only when it preserves the same semantics.
Apply transparency tiers and repository authority to linked evidence.
Never infer identity credit from presence, token volume, online time, or unverifiable narration.

Acceptance criteria

A client can verify one attestation without trusting the UI that displays it.
Reversed or later-invalidated outcomes produce a linked revocation or correction.
An attestation cannot be replayed for another issue, revision, verifier, or actor.
Private work can remain undisclosed while preserving a bounded private attestation.
Ranking systems treat attestations as scoped evidence, not a universal score.

Verification

Test signing, verification, replay resistance, policy changes, revocation, privacy, key rotation, and stale evidence. Qualify one forge bounty attestation after project 8 settles it.

Dependencies

Depends on project 3 accepted-outcome receipts and project 8 verified bounty settlement.

AtlantisPleb opened this issue 23h ago
A AtlantisPleb Author 19h ago
Landed on main as f769743.

A reputation attestation is now one Ed25519-signed canonical claim binding the issuer key, the subject, an accepted outcome receipt, the repository, the issue, the revision, the artifact digest, the admitted verifier policy version and digest, a confidence in parts per million, evidence references, a timestamp, and a nonce. Completion, verification, review, payment, reversal, and revocation stay distinct facts.

Issuance requires an accepted outcome decision that already reached its terminal state, so presence, token volume, online time, and narration are not attestable. There is no score and no leaderboard: subject evidence is counted inside one repository and reports score: null.

A skeptical client verifies a claim without trusting the interface. New read routes publish the claim verbatim next to its signature, the admitted public keys, and the policy rules:
```
GET /api/v3/reputation/policy
GET /api/v3/reputation/keys
GET /api/v3/repos/:owner/:repo/issues/:issue_number/attestations
GET /api/v3/repos/:owner/:repo/attestations/:id
GET /api/v3/repos/:owner/:repo/attestations/:id/verification
GET /api/v3/repos/:owner/:repo/reputation/subjects/:subject_id
```
The client recomputes the canonical digest, checks the signature, reproduces the policy digest, resolves each evidence reference, and reads revocation state. A claim presented for another issue, revision, verifier, or actor fails its binding. A reversed outcome gets a linked reversal or revocation attestation and the original claim stays readable. Retiring a key never invalidates the history it signed, and no private key enters the database. Disclosure follows repository authority, and a private attestation withholds the outcome reference and every evidence reference from the signed claim while staying verifiable.

Contract recorded as REPUTATION-001 in INVARIANTS.md, documented under "Reputation attestations" in priv/docs/rest-api.md, and proven by test/openagents/reputation_test.exs and test/openagents_web/controllers/reputation_controller_test.exs. mix precommit passes.

Not in this change: a Nostr representation, which stays out until it can carry identical semantics, and bounty qualification, which waits on project 8 settling a forge bounty.

Written by Devin
closed this as completed 19h ago