architecture · system capabilities · § Compute · § Shards · § Delivery · § Identity · § Reputation

The Future of the Mesh: Bilateral Federation and Compute

fleetmesh coordinates independent relays through verifiable transmission, granular shard replication, discrete compute escrow, and deterministic protocol accounting.

This document outlines core design capabilities. Peering, synchronization, published budgets, dispute reports, and shard claims run on the reference node. The compute market (§ Compute) is formally specified across compute/1.0 and kinds 11803, 30810, and 30811.

Architectural Overview

Bilateral accounting provides verifiable bounds on relay resource consumption.

Nodes coordinate using W3C DIDs, negotiate explicit bilateral budgets, verify message transmission with signed receipt hash chains, and settle discrete computation through cryptographic preimage escrow.

Section 01 · Distributed Compute Layer

Contractually accountable nodes as a compute fabric

fleetmesh enables relays to negotiate discrete computational tasks. Every node possesses a verified cryptographic identity (DID), authenticated bilateral messaging (DIDComm v2), and an established bilateral ledger. Computation is negotiated and settled directly between client and executor.

Figure 1: Compute escrow flow. Work is sealed under key k and delivered before payment; payment reveals the preimage that decrypts the result.

The compute architecture provides four core mechanisms:

Accountable Preimage Escrow: The worker executes the job in a sandboxed WebAssembly runtime (ComputeExecutor), encrypts the result payload with an ephemeral key k, and issues an invoice whose payment hash is SHA256(k). The buyer receives the sealed ciphertext first. Settling the invoice reveals key k to decrypt the payload.
Dual-Track Standing Separation: Reputation is partitioned between message transit (view_transit) and compute execution (view_compute). A node that fails a compute job receives a finding scoped strictly to compute, leaving message transit standing unaffected.
Sampled Re-execution: Deterministic computations are verified by re-executing the WASM binary over the input digest. Discrepancies produce cryptographic evidence for dispute reporting.
Independent Compute Markets: Compute capacity is negotiated independently from relay reputation.

Section 02 · Built-in Redundancy & Shards

Shard exchange: structured replication and recovery

Storage in fleetmesh is organized into discrete shards defined by tags, filters, and time ranges under kind 30803 coverage claims. Peers reconcile shard state using NIP-77 Negentropy range bisection.

Kind 30803 Shard Claims

Declarations of historical completeness

d-tag: Stable Shard Identifier (e.g. uk-events-2026Q3)
Filter: Deterministic Nostr filter (kinds, authors, tags)
Fingerprint: Order-independent Negentropy root hash over the set
Mode: asserted (provable SLA) or replicated (best-effort)

Self-Healing Replication

Multi-peer resilience against hardware failure

Set Verification: Peers sample shards and verify set consistency in logarithmic time
State Recovery: A restored node rebuilds complete state from peered shard assertions
Local Policy: Operators explicitly federate designated shards of interest
Accountability: Withholding events while claiming completeness produces an S2 finding

Peered nodes synchronize shared shards using Negentropy range comparisons. Peers compare set fingerprints, identify missing events within two round trips, and transfer only the missing delta.

This model maintains continuous replication across peered nodes that declare coverage. Data recovery is verifiable down to individual event signatures.

Section 03 · Verifiable Transmission & Delivery

Cryptographic receipts and non-repudiation on the wire

fleetmesh implements verifiable event delivery using signed receipt hash chains. Peers confirm event acceptance and custody with signed statements.

Batch Encapsulation & Transmission Node A packages outbound events into an authenticated frame and transmits them over the bilateral channel.

Signed Custody Receipt (Kind 11803) Node B accepts the batch, validates signatures, stores the events, and signs a receipt acknowledging event IDs, byte count, and timestamp.

Hash-Chained Meter Statements Each receipt binds to the hash of the preceding receipt, creating an append-only, tamper-evident audit ledger between both nodes.

Attribution of Delivery Failures When an event is dropped, Node A presents the signed receipt of Node B as proof of custody. Contract deviations produce signed audit evidence.

This audit chain enables verifiable service agreements across independent relays, providing mathematical confirmation of data delivery.

Section 04 · Sovereign Identity

Cryptographic identity and capability grants

fleetmesh anchors every node and agent in a decentralized identifier (W3C DID) that operates independently of DNS, hosting providers, or external certificate authorities.

Multi-Key Identity Descriptor

Three specialized keys unified under a single DID subject

secp256k1: Nostr Core Identity · Schnorr event signatures, NIP-01 compatibility
x25519: Key Agreement · DIDComm v2 Diffie-Hellman encryption
ed25519: Transport Proofs · High-throughput frame signing and handshakes

Identity Capabilities

Authorization via cryptographic keys

DIDs: Support for did:key, did:peer, and did:nostr
NIP-42 Auth: Mutual cryptographic challenge-response on connection
Gift Wrapping: NIP-59 sealed envelopes preserving metadata privacy
Delegation: Capability tokens authorizing workers without exposing root keys

Access control, routing limits, and peering privileges are managed through signed capability grants. Node identity remains portable across host migrations without loss of peering history or standing.

Section 05 · Protocol Interoperability

Standards compliance and protocol convergence

fleetmesh integrates with existing network infrastructure and standard protocols across the decentralized stack.

Nostr Ecosystem

Native Nostr Core

Compatibility with NIP-01 (event model), NIP-42 (authentication), NIP-44 (encryption), NIP-59 (gift wrapping), NIP-66 (relay monitoring), and NIP-77 (Negentropy).

W3C Standards

Decentralized Identity

Adherence to W3C DID Core v1.0 and DIDComm Messaging v2. Nodes speak universal protocols capable of federating with standard identity systems and mobile enclaves.

Security & Peering

FIPS 140-3 & Overlay Peering

Cryptographic boundary mapping compatible with NIST FIPS 140-3 environments, alongside routing interoperability with the Free Internetworking Peering System (FIPS).

Micro-Settlement

Lightning & Ecash

Settlement adapters for the Lightning Network (BOLT-11, BOLT-12, L402) and Cashu ecash mints, supporting sub-satoshi accounting and micro-payments for compute and retrieval.

Compute Runtime

WebAssembly & WASI

Deterministic execution sandboxes using Wasmtime and Wasmer, enabling portable, secure, and verifiable compute workloads.

Open Reference

Public Domain

All specifications, schemas, test vectors, and the reference node (meshnode) are dedicated to the public domain under CC0 1.0 Universal.

Section 06 · Relay Protection & Rate Accounting

Rate control and Sybil defense at the protocol layer

fleetmesh regulates resource usage through bilateral published grants and deterministic severity ratings.

Anti-Abuse Controls Across Relay Architectures
Threat Vector	Traditional Open Relay	Closed Paywalled Relay	fleetmesh Bilateral Mesh
Sybil Key Generation	Unbounded new key generation	Per-key fee requirement	Quarantined: Fresh keys are constrained to Tier 0 sandbox budgets until proving clean window streaks over time
Relay Traffic Floods	Resource exhaustion under load	Arbitrary administrative caps	Hard Bounded: Bilateral grant (kind 30801) enforces strict byte and event limits per time window
Malicious Withholding	Unprovable event drops	Unprovable operator drops	Provable Fault: Signed receipt chains reveal custody; withholding data claimed complete yields an S2 breach
Blacklisting & Censorship	Opaque IP or pubkey blocklists	Administrative account suspension	Objective Evidence: Only signed cryptographic proofs (S1–S4) impact standing; trust is weighted locally (view(x))

Deterministic Severity Ladder

Protocol non-conformance follows an objective severity ladder:

S0 (Clean Operation): The peer honors grant budgets, signs valid receipt batches, maintains consistent Negentropy roots, and responds to heartbeats within latency bounds.
S1 (Protocol Deviation): Malformed JSON, minor timestamp drift, or schema deviations that do not threaten cryptographic state. Results in rate reduction and telemetry warnings.
S2 (Cryptographic & State Breach): Forged signatures, corrupted receipt chains, transport key impersonation, deliberate shard poisoning, or claiming completeness over a shard while withholding events. Triggers instant peering demotion, grant suspension, and public broadcast of the signed evidence.
S3 (Denial of Service & Network Flood): Deliberate socket saturation, continuous violation of bilateral budget limits, or distributed flooding. Peering is terminated and quarantined.

Subjective Trust Weighting

fleetmesh avoids centralized blocklists. When Node A detects that Node B committed an S2 breach, Node A publishes a signed finding with evidence. Node C receives the finding, validates the signature and proof, and updates its local trust score view(B) according to its own weights.

Section 07 · Autonomous Systems

Agent workloads, capacity management, and partition tolerance

fleetmesh provides infrastructure for autonomous agents and resilient network operation:

HORIZON 01

Autonomous Agent Substrate

Autonomous software agents require an open, identity-native substrate to discover peers, purchase compute, exchange encrypted shards, and settle micropayments in real time. fleetmesh provides standard protocols for autonomous agent interaction.

HORIZON 02

Dynamic Capacity Management

Through dynamic capacity management (node/capacity.py) and directional strain ledgers (node/strain.py), fleetmesh nodes manage high traffic surges. Under pressure, nodes shed low-priority sync tiers while maintaining core routing.

HORIZON 03

Partition Tolerance

The multi-hop store-and-forward architecture and localized Negentropy reconciliation allow disconnected network partitions to continue operating independently, reconciling delta logs once connectivity is restored.

Next steps in the reference architecture:
Explore the hands-on deployment guide in Running a Node and Operator Manual, study the accounting principles in Reverse Reputation & Receipt Chains, inspect storage economics in Retrieval-Based Settlement, or read the formal fleetmesh Specification.