Reputation System

The reputation system is the social fabric that holds the Made Open ecosystem together. Without trust, there is no economy, no governance, and no community. This system makes trust portable, multi-dimensional, transparent, and forgiving — a fundamental shift from the opaque, centralized, punitive reputation systems run by platforms today.

The Problem with Today's Reputation

Reputation is currently fragmented and platform-controlled:

• Your GitHub reputation doesn't transfer to Stack Overflow
• Your Airbnb reviews don't help you on eBay
• LinkedIn endorsements mean nothing to someone hiring via a community board
• Platforms calculate scores using opaque algorithms — you don't know how, who sees it, or how to recover from mistakes
• A platform can delete or manipulate your reputation at will

Users rebuild trust from scratch on every platform. This serves the platforms (lock-in) and not the users.

The Solution: The Social Ledger

The Social Ledger is a comprehensive, portable, transparent trust framework:

• Multi-Domain: Reputation tracked across all activity contexts, not a single number
• Portable: Stored as W3C Verifiable Credentials (VCs) in the user's wallet; follow the user everywhere
• Transparent: All scoring algorithms are open source and auditable
• User-Controlled: Users decide who sees their reputation and in what detail
• Forgiving: Clear mechanisms for rebuilding trust after mistakes
• Interoperable: Bootstraps trust from existing platforms (GitHub, LinkedIn, etc.)

The 7 Reputation Domains

Reputation is tracked separately per context. Cross-domain inflation is prevented — your marketplace seller score doesn't inflate your governance participation score.

1. Marketplace

2. Governance

3. Resource Sharing

4. Data Quality

5. Content Creation

6. Technical Contribution

7. Community Moderation

Context-Aware Scoring

A single score per domain is computed from all relevant VCs the user holds. The formula prevents stale credentials from dominating:

Score(u, c) = Σ [ vc.score × Decay(vc.age) × Weight(issuer, c) ]
              ─────────────────────────────────────────────────────
              Σ [ Decay(vc.age) × Weight(issuer, c) ]

Where:

• vc.score — score embedded in the credential's credentialSubject.score
• Decay(age) — exponential time decay: 0.5 ^ (age_in_days / half_life) (equivalent to e^(-k × age) with k = ln(2) / half_life)
• Weight(issuer, c) — fixed issuer weight applied by the current service:
  • Peer-issued (another user's DID, did:key: or did:web:): 1.0
  • Self-issued (same DID as owner): 0.0 (ignored)
  • External bootstrap (GitHub, Stack Overflow, etc.): 0.3

Current implementation note. ReputationService.computeScore uses the fixed issuer weights above rather than a recursive 1 + Score(issuer)/MaxScore formula. A recursive issuer-weight pass is a future enhancement.

Time Decay Constants

As defined in HALF_LIFE_DAYS in apps/hub/src/services/reputation/ReputationService.ts:

Effect: A TrustedSellerCredential from 3 years ago contributes ~25% of the weight of an identical credential from today. Reputation must be continuously earned, not coasted on.

Trust Delegation

Trust delegation enables "if people I trust trust this person, I have more confidence in them."

Users can designate other users as trusted in their trust graph. When calculating a seller's reputation for a potential buyer:

1. Collect all the seller's relevant VCs
2. For each VC issuer, check if the issuer is in the buyer's trust network
3. Delegated trust VCs receive slightly lower weight than direct VCs from the buyer's own transactions
4. Score incorporates both direct credentials and delegated trust

Alice trusts Carol (direct trust relationship)
Carol issued TrustedSellerCredential to Bob
→ When Alice views Bob's listing: "Seller Reputation: 4.7 (1 credential from your trusted network)"

The trust graph is stored as a Postgres adjacency-list table (trust_relationships) and the current service does single-hop delegation only (ReputationService.getContextualScore). Multi-hop traversal via a dedicated graph database is a future enhancement.

Reputation Privacy

Users control who sees their reputation and in what form:

Selective Disclosure

A Verifiable Presentation (VP) lets users choose which credentials to include:

{
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    "TrustedSellerCredential",   // show this
    "ReliablePayerCredential"    // show this
    // DisputeLostCredential    // NOT included — user's choice
  ]
}

Zero-Knowledge Proofs

Users can prove a reputation threshold without revealing their exact score:

"I can prove my marketplace score is above 4.5 without revealing it is 4.73 or that I have 23 transactions."

ZKP libraries: Circom + snarkjs. The proof is verifiable by anyone who knows the scoring algorithm and the user's public DID.

Pseudonymous Reputation

Users can maintain separate reputation identities for different contexts. A DID for professional work, a DID for community organizing — each with its own reputation history. Credentials issued to one DID don't automatically apply to another.

Reputation Recovery

The system is designed to be forgiving. Mistakes don't permanently destroy reputation.

Redemption Credentials

After a dispute is resolved (user makes the affected party whole), the aggrieved party can issue a DisputeResolvedCredential. This partially offsets the negative impact of the DisputeLostCredential.

Expiration of Negative Credentials

All negative credentials expire:

After expiry, the credential's weight decays to zero. A user who committed a mistake 5 years ago and has since maintained positive behavior will have that reflected in their current score.

Rehabilitation Programs

Community Governance can define rehabilitation programs — structured paths for rebuilding trust:

Program: "Marketplace Trustbuilder"
Requirements:
  - Complete 10 successful transactions without dispute
  - Participate in 3 governance votes
  - Provide 2 SkillProviderCredentials

On completion: Governance issues RedemptionCredential
Effect: Partially lifts CommunityViolationCredential weight

External Reputation Bootstrap

New users can bootstrap credibility from existing platform reputations via OAuth + VC issuance:

Bootstrap flow:

1. User connects external account via OAuth
2. Universal Connector fetches reputation data from external API
3. Reputation Service issues a VC attesting to the verified external reputation
4. The credential is stored in the user's wallet and visible in their profile

External credentials are weighted lower than peer-issued in-platform credentials. They establish initial baseline trust, not a substitute for earned reputation.

Use Case Scenarios

Scenario 1: Buying from a New Seller

Bob wants to buy a data product from Alice, whom he's never interacted with.

1. Bob views Alice's marketplace listing
2. UI queries Reputation Service: Alice's marketplace score
3. Service fetches Alice's TrustedSellerCredentials
4. Service checks Bob's trust network:
   → Carol (whom Bob trusts) issued a TrustedSellerCredential to Alice
5. Score calculated: direct credentials + delegated trust from Carol
6. UI shows: "Seller Score: 4.7 / 5 (23 transactions, 1 from your trusted network)"
7. Bob purchases with confidence

Scenario 2: Recovering from a Dispute

Alice (seller) lost a dispute → received DisputeLostCredential → score drops 4.8 → 4.2

Alice contacts buyer, offers full refund + 20% future discount
Buyer accepts, issues DisputeResolvedCredential to Alice
Score recovers to 4.5 (partial offset)

Over 2 years:
  DisputeLostCredential weight decays exponentially
  Alice's score continues improving if she maintains good practice
  After 2 years, DisputeLostCredential expires

Scenario 3: Bootstrapping via GitHub

Charlie (new to platform) has 5,000 GitHub followers, 50 popular repos
1. Connects GitHub via OAuth
2. GitHub Connector fetches reputation
3. Reputation Service issues GitHubFollowerCountCredential
4. Charlie's profile shows: "GitHub: 5,000 followers, 50 repos (verified)"
5. Charlie can participate immediately with established credibility

Data Model

Defined in supabase/migrations/00005_phase5_marketplace.sql:

-- Cached reputation scores (recalculated periodically or on-demand)
reputation_scores (
  id             uuid         PRIMARY KEY DEFAULT gen_random_uuid(),
  owner_id       uuid         NOT NULL REFERENCES auth.users(id),
  domain         text         NOT NULL,        -- 'marketplace','governance','resource_sharing',...
  score          numeric(5,2) NOT NULL DEFAULT 0,
  vc_count       integer      DEFAULT 0,
  last_computed  timestamptz  DEFAULT now(),
  UNIQUE (owner_id, domain)
)

-- Trust relationships (who trusts whom) — adjacency-list trust graph
trust_relationships (
  id          uuid         PRIMARY KEY DEFAULT gen_random_uuid(),
  owner_id    uuid         NOT NULL REFERENCES auth.users(id),   -- who is trusting
  trusted_did text         NOT NULL,                             -- who is trusted (DID)
  weight      numeric(3,2) NOT NULL DEFAULT 1.0
                           CHECK (weight > 0 AND weight <= 1.0),
  context     text,                                              -- 'marketplace','governance','general'
  created_at  timestamptz  DEFAULT now(),
  UNIQUE (owner_id, trusted_did)
)

Verifiable Credentials are stored in the user's credential wallet (Supabase Vault or client-side). The Reputation Service does not store the credentials themselves — it reads them from the user's wallet when calculating scores.

Capability Rollout