Fleetmesh fleetmesh

deep dive · protocol economics · kinds 30801 & 30802

Reverse Reputation and Bilateral Accounting

Published bilateral budgets, cryptographic receipt chains, and subjective trust weighting in fleetmesh.

Core Architecture

Nodes publish explicit rate budgets and verify consumption using signed receipts. Adverse evidence requires counterparty signatures and direct peering history.

Each node signs and publishes the exact budget allocated to an upstream peer. The peer enforces limits locally and proves consumption through chained cryptographic receipts. Dispute reports require an active grant relationship and subject-signed evidence.

Part 01 · Overview

Rate Limiting Architecture and Verification

Static Rate Limiting

Unilateral Server Limiting

Traditional relays configure private rate ceilings, dropping burst traffic silently or returning uninformative HTTP status codes.

  • Upstream peers have no advance visibility into bandwidth budgets.
  • Application-layer throttling resembles transient network packet loss.
  • Peers cannot verify compliant delivery or dispute unfair drops.
  • Abuse defense relies on third-party blacklist subscriptions.

Fleetmesh Bilateral Verification

Published Grants and Receipts

Nodes negotiate explicit throughput allowances and verify accounting using signed delivery receipts.

  • Deterministic commitments: Both nodes agree on window parameters in advance.
  • Autonomous metering: Peers monitor local egress against active grant limits.
  • Cryptographic reconciliation: Server measurements verify client-signed usage counters.
  • Counterparty evidence: Dispute filings require valid cryptographic signatures from the alleged offender.

Kind 30801

1. Peer Grant Envelope

An addressable Nostr event using a blinded identifier derived via HKDF-SHA256 from shared Diffie-Hellman secrets. Payloads are encrypted to the subject via NIP-44, defining bandwidth limits, trust tier, shard filters, and window duration.

DIDComm budget/1.0

2. Receipt Hash Chains

The subject transmits periodic signed accounting receipts. Receipts chain sequentially using SHA-256 hashes of previous receipts, preventing retroactive modification. Each receipt documents cumulative counter consumption and forwarded origins.

Kind 30802

3. Conformance Report

An addressable event published when sustained protocol violations occur. Reports require an active grant issued by the reporter and must include verifying signatures produced by the subject.

The Grant Loop Diagram
Figure 1. The bilateral grant and measurement equilibrium loop.

Part 02 · Protocol Mechanics

Severity Ladder and Subjective Trust Weighting

Deterministic Severity Ladder

Protocol remedies follow deterministic, published rules. Breaches distinguish between unmetered volume (S1) and accounting misreporting (S2):

S0 · drift
Normal operation: traffic within 110% of limits; signed receipts agree with measured issuer counters.
no action · streak +1
S1 · overrun
Honest burst: sustained over budget, but signed peer receipts match observed traffic.
limit × 0.5 · notice first
S2 · misreport
Dishonesty or active silence: receipts diverge from measurement, or receipts fail to arrive despite active traffic egress.
limit × 0.25 · probation tier
S3 · abuse
Floods and protocol violations: traffic outside granted scopes, malformed floods, excessive duplicates, or repeated hop-limit violations.
limits → 0 for 24h · public report
S4 · malice
Cryptographic attack: forged signatures, corrupted receipt chains, transport key impersonation, shard poisoning, or grant-evasion routing.
revoked · grant deleted · report published

Partition Tolerance · Egress Verification · § Partition tolerance

Asynchronous Silence Classification: To differentiate between network disconnects and deliberate non-accounting, fleetmesh evaluates physical egress counters:

Active Silence (Traffic > 0, receipts missing)

Classified as S2 Misreport. Nodes transmitting events must provide matching signed accounting receipts.

Inactive Silence (Traffic = 0, receipts missing)

Classified as a standard partition. The evaluation window closes without penalty, streaks remain intact, and no adverse report is created. When traffic resumes, a new receipt chain opens.

Mathematical formulation

Local reporter weight: w(r)

Every node evaluates a reporter r using the local grant to r, the clean interaction streak age, and historical reporting accuracy for r:

w(r) = tier_weight(grant(my → r)) × age_factor(r) × (1 − false_report_rate(r))
  • tier_weight: probation (0.00), member (0.25), trusted (0.60), anchor (1.00)
  • age_factor: min(1.0, clean_windows / 168), 168 default hourly epochs (a one-week streak) to reach 100%
  • false_report_rate: (unsupported or refuted reports by r) / (reports by r evaluated); immune when the evidence verifies and the finding follows from it

Ordinal threshold

Subjective view horizon: θ = 1.0

Severity is an ordinal scale rather than an arithmetic average. A finding takes effect when accumulated weighted reports reach the binding horizon:

Σ w(r) ≥ 1.0  (over reporters alleging severity ≥ S)
  • 1 anchor reporter (weight 1.0)
  • 2 trusted reporters (weight 0.60 each = 1.20)
  • 4 member reporters (weight 0.25 each = 1.00)
  • ∞ probation reporters (weight 0.00: unverified nodes carry zero influence)

Part 03 · Simulator

Interactive Trust and Reputation Simulator

Test reporter tiers, clean-window streaks, and false reports to observe how weight w(r) converges across the evaluation horizon.

Reporter Weight and Threshold Engine

Live client-side calculation per § Trust weighting
1. My grant tier to reporter trusted (0.60)
2. Clean windows streak 168 windows (1.00x)
0 (fresh)84 (0.5x)168 (1.0x mature)336 (seasoned)
3. Contradicted false reports 0 / 10 evaluated (0% penalty)
0 (honest)3 (30% slash)7 (70% slash)10 (pariah)
4. Identical reporters collaborating 2 nodes

Step-by-step calculation

tier_weight = 0.60
age_factor = min(1, 168 / 168) = 1.000
false_penalty = 1 - (0 / 10) = 1.000
w(single) = 0.60 × 1.000 × 1.000 = 0.600
Total accumulated weight (Σ w)
Threshold satisfied (≥ 1.0): S-remedy binds
1.20
0.0θ = 1.00 (binding horizon)2.0+

Part 04 · Lifecycle

Peering Lifecycle: Epochs, Disputes, and Audits

Phase 1 · onboarding

Genesis Handshake and Probation Grant

Nodes establishing peering over DIDComm peering/1.0 begin in the probation tier with conservative traffic limits. Unproven peers hold weight w(r) = 0, preventing malicious claims against third parties.

Phase 2 · active epochs

Accounting and Additive Increase

Traffic circulates under active grants. At the close of each evaluation window, the peer submits chained accounting receipts. Clean windows increment the streak counter and expand bandwidth limits under additive increase.

Phase 3 · disputes

Complaint and Remedy Procedure

When an issuer detects volume overruns (S1) or receipt discrepancies (S2), it transmits a private DIDComm complaint/1.0 notice. The peer has a grace window to submit missing receipts or accept revised grant terms prior to public filing.

Phase 4 · audits

Third-Party Standing Inquiries

Before establishing new connections, nodes query mutual trusted peers over standing/1.0. Peers respond with selective tier disclosures (tell) or private refusals (decline). Declining carries zero negative connotation.

Wire Formats and Cryptographic Schemas

Part 05 · Design Rationale

Game Theory and Security Properties

Game theory

1. Sybil Resistance

Generating arbitrary key pairs yields zero influence (Σ w(r) = 0) because probation nodes carry zero reporting weight. Multihoming and sybil relay farms are countered through ASN diversity checks, explicit leaf selection, and severe S2 penalties for fabricated topology.

Sovereignty

2. Local Subjective State

The network operates without global reputation registries or consensus voting rounds. Nodes evaluate peers through direct bilateral relationships and local trust parameters, remaining immune to coordinated third-party censorship.

Accountability

3. Reporter Accountability

Filing unverified or fraudulent dispute claims penalizes the reporter false_report_rate, permanently devaluing future testimony across the network.

The alpha contract · safety guarantee

Zero Risk to Existing Infrastructure: Participating in fleetmesh peer accounting never compromises local database state or existing relay operations. Bilateral rate enforcement affects only inter-node replication budgets, and operators can disengage via configuration at any time.

Specification references: § Grants, § Severity ladder, and § Trust weighting. Visual references are available on the Protocol Emblems page.