Replication

Replication

Replication Boundaries & Synchronization Rules

Nostr events are immutable and self-authenticating, so replication is set union over a grow-only set, with deletions and replaceable-supersession as the two exceptions. There is no ordering guarantee beyond created_at, no consensus, and no notion of a primary. Two nodes that have exchanged every event in a shard hold identical sets; two that have not are both correct and simply behind.

Interest contracts

A peer does not receive a firehose. It declares an interest — a filter, a time range and a direction — and the grant is scoped to it. Pushing an event outside the interest is an S3 finding, not merely inefficient: it is the mechanism by which a misbehaving peer would try to make its traffic someone else's problem.

• pull — the peer fetches; the issuer serves within budget.
• push — the peer sends; every event MUST match the interest filter.
• both — symmetric, and the common case between anchors.

Reconciliation uses NIP-77 negentropy. A node MUST support NIP-77 to peer. Range synchronization is an essential protocol prerequisite. The legacy alternative—re-broadcasting timestamp windows and discarding duplicates—wastes bandwidth and renders duplicate-ratio reputation metrics ineffective.

Pluggable Storage & Deterministic Range Fingerprints (MeshStore)

To allow existing relays (e.g. strfry, khatru, nostr-rs-relay) to join the mesh without changing their underlying database engine, all event storage, retrieval, and range indexing is abstracted behind the async MeshStore trait.

#[async_trait]
pub trait MeshStore: Send + Sync + 'static {
    /// Retrieve an event by its 32-byte identifier
    async fn get_event(&self, id: &[u8; 32]) -> Result<Option<Event>, StorageError>;

    /// Insert an independently authenticated event into local storage
    async fn insert_event(&self, event: &Event, now: u64) -> Result<InsertStatus, StorageError>;

    /// Check presence of an event without decoding its payload
    async fn has_event(&self, id: &[u8; 32]) -> Result<bool, StorageError>;

    /// Calculate a deterministic NIP-77 range fingerprint over (filter, since, until)
    async fn fingerprint_range(&self, filter: &Filter, since: u64, until: u64, now: u64)
        -> Result<[u8; 16], StorageError>;

    /// Enumerate all event IDs matching a filter within a timestamp interval
    async fn enumerate_range(&self, filter: &Filter, since: u64, until: u64, now: u64)
        -> Result<Vec<[u8; 32]>, StorageError>;
}

Deterministic range fingerprinting. The fingerprint is NIP-77's, not a second one. fleetmesh defines no fingerprint of its own, because a node that speaks NIP-77 already computes this and a second construction over the same data is one more thing for two implementations to disagree about.

acc  := Σ (id as 32-byte little-endian uint) mod 2256
fp   := SHA256(acc as 32 bytes little-endian || varint(count))[0..16]

varint is base-128, most significant digit first, high bit set on all
but the last byte. 16 bytes on the wire, and the count is what stops the
additive structure colliding on cardinality alone.

It is a sum, and that is the point. Set reconciliation works by splitting a range and comparing halves. Because addition composes, the fingerprint of a range is the sum of its sub-ranges: a split is an index lookup, and a node can maintain running sums rather than re-reading events. An order-dependent chained hash would force a re-hash of every element in every new sub-range at every level of the split, which is the wrong shape for the protocol this document already requires. It also makes the fingerprint order-independent, so no sort rule is needed to compute it — sorting by (created_at ASC, id ASC) remains required for enumerate_range, whose output order is observable.

Which events are in the set. Pinning the algorithm is only half of agreement; the other half is membership, and two backends can each compute NIP-77 correctly over different sets and never converge. Four rules decide it, and each is a place where a locally reasonable choice silently breaks reconciliation. They are normative and live in constants.json under store.

• Ephemeral kinds are never stored (20000 ≤ n < 30000), so they never enter a fingerprint.
• Replaceable and addressable kinds keep only the winner — later created_at, and on a tie the lexicographically lower id. Retaining a superseded version is not a local choice, because it changes the fingerprint.
• A NIP-09 deletion removes only events its own author signed, and removes them permanently: the id is tombstoned so a later re-offer cannot resurrect it. The kind 5 is itself stored and replicates, because a peer that never receives it never learns of the deletion. A deletion that arrives before its target still binds, so a tombstone records which key asked — the authority check needs the target's author, and that is not known yet. Checking it on arrival instead is what makes the outcome independent of the order the two events turned up in.
• An expired event is not in the set. Two peers evaluating either side of that instant disagree for as long as their clocks differ, bounded by the same 60 second skew allowance the accounting uses. This is why the range methods take now.

The since and until arguments bound the time axis, and a filter's own since/until narrows further: the intersection, so that neither can silently widen the other.

Every storage backend — LMDB, SQLite, PostgreSQL, flat files — MUST produce byte-identical fingerprints for identical event sets. How it does so is deliberately unspecified: a prefix-sum index, a segment tree over the timestamp axis, or a naive scan are all conformant, because only the value on the wire is normative. An implementation is free to make range splits O(1) and most should.

The delivery envelope

Events crossing between nodes are wrapped, and the wrapper is where accountability lives. Every node that forwards an event appends its signature over (event_id, prev_hop, at). A receiver therefore knows not just who handed it the event but the whole chain back to the node that first put it into federation, and when each of them passed it on. at is inside the signature because a field a signature does not cover is a field anyone may rewrite: without it a hop could be lifted onto another moment, and a path proved that a node forwarded an event but never when. It is also the only thing a forwarder signs for an event it did not write, which is what lets an envelope stand as evidence against the forwarder.

A sync/1.0/deliver carries its events in these envelopes and nowhere else, one per event, and its body is the count. A receiver MUST refuse a deliver that carries no delivery-envelope attachment, and MUST NOT store an event no verifying envelope covers. The rule is not tidiness. An event accepted without provenance is an event whose delivery can never be reported: a report may cite an envelope, or an event the peer itself authored, and a third party's event with no envelope is neither, so omitting the attachment would be a free way to commit the interest offence unpunishably. Carrying the events in the body as well, which an earlier draft did, cost twice the bytes for one copy nobody read — and those bytes are metered against the receiver's own grant.

{
  "event": { … the nostr event, unmodified and independently verifiable … },
  "path": [
    { "node": "did:nostr:<origin>",  "at": 1787000001, "sig": "…" },
    { "node": "did:nostr:<relayer>", "at": 1787000004, "sig": "…" }
  ],
  "grant": "<event id of the grant this delivery is charged against>",
  "window": 496389
}

msg := SHA256("fleetmesh/hop/1" || "|" || event_id || "|" || prev_hop || "|" || at)
sig := BIP-340(node_key, msg)

event_id   the wrapped event's id, 64 lowercase hex
prev_hop   the previous path entry's node string, exactly as written; empty for the first hop
at         this hop's own unix seconds, in decimal

The domain label keeps a hop signature from being mistaken for a nostr event id or for anything else the same key signs. A path longer than max_forward_hops (three) is rejected, and a peer that keeps sending them is committing the hop-limit S3 the ladder already names. vectors/envelope.json pins a two-hop path under deterministic keys, so an implementation can check its messages and signatures byte for byte.

Deletions and supersession

• NIP-09 deletion authority. Stores MUST verify that NIP-09 deletions target events authored by the deletion signer. This ownership check ensures safety: a hostile peer's Kind 5 deletion cannot alter another author's data, regardless of forwarding path.
• Replaceable and addressable supersession is resolved by created_at, then by lexicographically lower event id, exactly as NIP-01 specifies. Peers MAY exchange only the winner.
• NIP-40 expirations are honoured on receipt. A node MUST NOT accept an already-expired event from a peer, and a peer that sends them in bulk is backfilling garbage — S1.
• A deletion is a request, not an erasure guarantee. This document does not pretend otherwise, and neither should any interface built on it.

Blobs

Blossom BUD-04 (PUT /mirror) provides HTTP fallback. Servers MUST verify the authorization event's x tag against the computed SHA-256 hash of the received payload. Nodes MUST NOT credit unverified blobs toward coverage claims. Nodes SHOULD reject blobs lacking associated local events to prevent unauthorized CDN exploitation.

Never replicated

The full list is in § Two networks, because most of it is a boundary rule for operators bridging an existing estate. Two entries are protocol-level, and every node enforces them against every peer whether or not any other service is anywhere nearby:

• Kind 24133 — NIP-46 signer traffic. Ephemeral, and federating it would let any node observe every pairing and every signing event of every bunker in reach. MUST NOT cross, on any transport, under any grant.
• Kind 1059 — gift wraps replicate only to nodes named in the recipient's own kind 10050 DM relay list, a check any node can perform from public data. Never in bulk, and never on a filter a third party supplied.

Symmetrical Ingress & Egress Policy Seams (pluginIn / pluginOut)

An operator has as much reason to govern what leaves their relay as what arrives. In addition to NIP-77 interest filters, fleetmesh specifies symmetrical policy seams on both ingress and egress paths. These seams allow external policy engines or plugins (compatible with strfry write-policy and nostr-router) to evaluate, filter, and redact traffic dynamically.

Prior art

Integration with Existing Relay Tooling

Relay synchronization has established production tools, notably strfry router. Any new specification must clearly state its relationship to existing tools. The comparison begins with a straightforward distinction: router is deployed and operational at scale; fleetmesh is a formal specification.

The core distinction is structural. strfry router is a replication tool; fleetmesh is a peering protocol. Router coordinates event transfer between pre-trusted relays. Fleetmesh establishes bilateral relationships, dynamic capacity allocation, and mutual accountability between untrusted peers. The two designs address different operational requirements.

How router works

One process, acting as a nostr client to many relays, driven by a config file of named streams. Each stream has a direction — up, down or both — a list of relay URLs, an optional nostr filter, and optional plugins consulted before storing or before transmitting. Edit the file and it reloads, computing the minimally invasive change rather than restarting. A relay that cannot be reached is retried forever.

Where router is simply better

Four of these are gaps in this document rather than differences of philosophy. They are listed because a comparison that only flattered the author would be worth nothing.

Where fleetmesh answers something router leaves open

Router's documentation notes that bidirectional streams echo events back to source relays, which then reject them as duplicates. Fleetmesh's dup_ratio limit and envelope origin tracking address this condition directly. Accounting for duplicate ratios provides empirical feedback on network topology efficiency.

The second distinction is explicit bilateral consent. A traditional router stream configured with dir = "up" transmits events to a relay that never signed an agreement to accept them. In practice, operators configure streams only between allied relays. However, the legacy protocol provides no mechanism to record this bilateral relationship. Fleetmesh makes bilateral consent a first-class protocol primitive: a grant is a signed, auditable, and reciprocally enforced contract.

Quantum Relay (quantum-rely), and continuous-time propagation

Built on the Go rely v2 framework and packaged for self-hosting via quantumrelay_ynh, Quantum Relay uses continuous-time quantum walks over graph Laplacians. It calculates note propagation probabilities to prioritize fetching from neighboring relays, combined with diffusive consensus and exponential reputation damping.

Like router, Quantum Relay is a concrete, working implementation with rigorous benchmark suites (Jacobi eigendecomposition for N ≤ 128 nodes, sparse Taylor approximations for larger graphs) and automated multi-node stress tests. The comparison clarifies how a physics-inspired routing engine contrasts with an accountable, contract-driven peering standard.

Where Quantum Relay is simply better

Where fleetmesh answers something Quantum Relay leaves open

Ecosystem Bridges

Ecosystem Standards & Interoperability Bridges

A protocol that builds custom silos where proven open standards exist wastes engineering effort and fractures the network. fleetmesh follows a strict rule: offload whatever a merged, standardised Nostr NIP already does. Then bridge in both directions, so ordinary clients and relays gain mesh capabilities without running fleetmesh code.

Standardized Primitives Reused Directly

Bidirectional Ecosystem Bridges

{
  "kind": 30166,
  "pubkey": "<the node>",
  "tags": [
    ["d", "wss://pocketrelay.live"],                 // the endpoint, canonical
    ["n", "clearnet"],
    ["N", "1"], ["N", "11"], ["N", "40"], ["N", "59"], ["N", "77"],
    ["R", "!auth"], ["R", "!payment"], ["R", "!writes"], ["R", "!pow"],
    ["t", "bristol"],                           // a shard it claims
    ["expiration", "1789692000"]                // the descriptor's
  ],
  "content": "<the NIP-11 document the face serves>"
}

{
  "kind": 30385,
  "pubkey": "<reporter node>",
  "tags": [
    ["d", "wss://relay.example.org"],                    // the subject's endpoint, canonical
    ["k", "web"],                                       // NIP-73: the identifier is a URL
    ["p", "<subject node>"],
    ["a", "30802:<reporter node>:<subject node>"],  // the report it is derived from
    ["rank", "25"],                                     // S2: 100 × 0.25
    ["expiration", "1787186400"]                        // the report's
  ],
  "content": ""
}