Distribution & conformance

Distribution

Reproducible Distribution & Verification

Decentralized protocol governance requires verifiable software distribution. Downloading binaries over TLS relies on blind trust in hosting providers. Because on-wire protocol declarations are verifiable, the software producing those declarations must be verifiable as well.

What any distribution mechanism must do

Distribution is specified as architectural properties rather than a proprietary product. Fleetmesh does not hardwire a central package manager. Having eliminated centralized constants throughout the protocol, introducing a mandatory distribution registry would reintroduce central control.

npack satisfies all four

npack is a Nostr-native package manager that distributes signed release metadata over relays and stores immutable .npk artifacts — deterministic tar, zstd-compressed — on Blossom-compatible servers. It is the recommended distribution path for fleetmesh implementations, and it is recommended rather than required.

Binding a release to a protocol version

This is the one fleetmesh-specific addition, and it uses a tag npack already has. A release of a fleetmesh implementation SHOULD declare the protocol version it speaks as a capability:

["name", "fleetmesh-node"], ["version", "0.3.1"],
["provides", "fleetmesh/0.1-draft@6d8c8126a619e25c…"],
["x", "<sha256 of the .npk>"],
["repo", "30617:<pubkey>:fleetmesh-node"], ["commit", "<commit id>"]

This binding allows operators to verify the protocol version a binary speaks before installation. Nodes cross-check descriptor declarations against signed release events. A node declaring a version digest unverified by its installed release commits a misreport. The severity ladder prices this discrepancy as an S2 finding, with the publisher-signed release serving as evidence.

The distribution chain has no centralised dependency at any step. Source commits produce deterministic build archives. Independent operators sign the release hashes. Installed binaries declare canonical version digests, and peering handshakes check that those declarations match.

Reproducing the binary, without trusting who built it

A signed release proves who published a build. It does not prove what the build contains, and a single publisher key is a single point of compromise for every node that installs from it.

Release binaries MUST therefore be built under hermetic, reproducible toolchains — Nix or a pinned container image — and their SHA-256 digests MUST be independently rebuilt, verified and signed by at least two independent operators, using nostr software attestation events, before deployment. Independence is judged the same way it is everywhere else in this document (§ Governance).

Two operators agreeing on the bytes is not proof of absence of a backdoor. It is the difference between trusting one party and trusting a collusion, which is the same trade the rest of the mesh makes.

What this does not solve

Conformance

Conformance Testing & Verification

Four suites, each runnable without a network:

Interoperability is the primary criterion. A conformant mesh node MUST function as a standard, unmodified Nostr relay for any client that lacks mesh awareness.

Registration

Protocol Event Kinds & Standardization

All ten event kinds were verified against three independent registries on 2026-08-29 and re-verified against live copies of all three on 2026-09-01. All ten allocations are collision-free. The verification process follows the strict, empirical guidelines defined by the NIP maintainers.

Availability

Registry is nostr-protocol/registry-of-kinds, the machine-readable YAML the NIPs README now points at as preferred over its own table — 265 kinds defined, highest 39701. NIPs table is the 187-row human-curated table in the NIPs README. Issues & PRs is a GitHub search of every issue and pull request in the NIPs repository for each number, open or closed. Nothing matched anywhere.

The range classes check out against NIP-01's own wording: replaceable is 10000 ≤ n < 20000, ephemeral is 20000 ≤ n < 30000, addressable is 30000 ≤ n < 40000. So 11801–11803 are replaceable, 21801/21802 are ephemeral and 30801–30804, 30810/30811 are addressable, as the specification assumes throughout.

The compute kinds sit in the same two bands and were cleared the same way: 11803 has 11871 as its nearest neighbour above, and 30810/30811 fall inside the same gap as 30801–30803. Adjacent kind numbers show how the ecosystem is distributed. The 11k–12k band holds 11111, 11871 and 12473. The 21k–22k range holds 21000–21003, 21059 and 22242. Around 30k sit 30617/30618 and 30817–30828. The 30801–30803 allocation sits securely in the open gap between git repositories and wiki kinds.

What it takes to become a NIP

The NIPs repository publishes five acceptance criteria. Two of them decide this outright:

• “Fully implemented in at least two clients and one relay.” A specification written and implemented by one organisation does not qualify, however good it is. A NIP submission is therefore gated on a second, independent implementation existing — which is a statement about the mesh's adoption, not about the document.
• “There should be no more than one way of doing the same thing.” Reviewers will ask how Kind 30802 differs from a NIP-85 kind 30385, whether the one merged NIP-85 defines or the one PR #2418 proposes under the same number. The distinction is fundamental. Kind 30385 is a third-party score about a relay, read by clients selecting connections. Kind 30802 is an evidence-backed peer verdict, carrying subject-signed cryptographic proof, read by nodes setting bilateral budgets. Different consumer, different evidentiary standard. A node publishes both, and the first is derived from the second and cites it (Bridge 2 in § Ecosystem Bridges).

The backlog is the other half of the picture. The repository has 454 open pull requests. PR #1585, NIP-37 Transport Method Announcement — which is roughly half of what this specification's node descriptor does — has been open since November 2024 and was last touched in March 2026. Planning around a merge is planning around something outside anyone's control.

The recommended path, in order

• 1
  Register the kinds nowSubmit the ten definitions to registry-of-kinds, whose stated bar is “any reasonable event definition can be added here” and which explicitly does not require an implementation guide. This is collision avoidance, it is cheap, and it is the step that stops someone else taking 30801 next month.
• 2
  Publish and implementShip this document and the reference implementation, with kind numbers treated as alpha-mutable per § Alpha contract. Standards on nostr emerge as often from someone doing a thing and others copying it as from a document, and the repository says so itself.
• 3
  Publish it on nostr, not only over HTTPA specification reachable only at one domain asks the reader to trust that domain stays up. NostrHub carries decentralised proposals as addressable kind 30817 events and browses repositories announced under NIP-34, so the document and its source become ordinary events that any relay can serve and anyone can mirror. scripts/publish_nostrhub.py builds both: the kind 30817 NIP from nip/fleetmesh.md, whose tables are generated from the same schema/ files this version digest is taken over, and a kind 30617 announcement of the repository. This costs nothing and asks nobody for permission, which is the same argument as step 1.
• 4
  Submit a NIP when a second implementation existsDo not submit prematurely. When ready, split the submission. The node descriptor and reputation kinds are separable. A targeted NIP covering bilateral grants and conformance reports has a far higher probability of consensus than a monolithic federation specification.
• 5
  Reconcile with #2418 on the way inA node publishes a derived kind 30385 beside its kind 30802: the same evidence, summarised as a client-facing score. It is published now, under merged NIP-85 and NIP-73, because those are the documents that already assign the number; Bridge 2 in § Ecosystem Bridges gives the shape and ref/projection.py is the serialiser. Reuse answers criterion 4 better than an argument does, and it cost one serialiser. The proposal is still open and its thread has never discussed the collision. If it merges on another number a second serialiser follows it. If it merges on this one the k tag tells the two shapes apart.