Fleetmesh fleetmesh

The fleetmesh Protocol · part 10 of 10

Open questions

Protocol parameters under active empirical evaluation during alpha testing.

Open questions

Open Empirical Questions

Four questions are undecided. Each names what would settle it and what happens if the measurement comes back the wrong way, because a question with no losing answer is not a question. Everything else this document raises, it answers in the section that raises it.

  1. Whether commitments are enough, or aggregate proofs are needed. Grants operate as blinded commitments encrypted to the subject. Third parties query via standing/1.0 rather than scraping public tables. This shields the peering graph from passive surveillance. Production deployments will measure two operational factors: whether query response rates are sufficient to evaluate newcomers, and whether declining to answer remains socially neutral. If either condition degrades, aggregate zero-knowledge proofs (§ Trust weighting) will transition from an optional enhancement to a core requirement.
  2. Whether proof mode is ever economic. The verification modes in § Compute market make a self-verifying work unit expressible, and confidentiality is only affordable because of it — a proof-mode receipt can be adjudicated by a third party that never sees the job. What is unmeasured is the price. Proving costs orders of magnitude more than executing, and it breaks the denominator: msat_per_mfuel prices execution, and a prover's bill is not proportional to the fuel it proves about. Alpha should measure which mode buyers actually select, and at what ratio of proving cost to job cost proof stops being theoretical. If the answer is never, the mode is deleted rather than defended, and confidential jobs stay disputable only by disclosure. Nothing in the protocol assumes a prover exists.
  3. How the second implementation happens. Formal NIP standardization requires two independent implementations. There is now one, written alongside this document by the same hand, which is not independence: it proves the arithmetic runs and it cannot prove the document is readable by somebody else. What it did settle is that the document is implementable, and it found several defects doing so, each recorded where it was fixed. All required fleetmesh capabilities (§ Implementation) are designed for straightforward integration into existing relay codebases (such as strfry or khatru). The fastest path to a second implementation is adding fleetmesh adapter modules to an existing relay rather than constructing a new node from scratch.
  4. Whether algorithm profiles are ever needed. Every primitive this document relies on is named once in constants.json under crypto. Two of them are on no FIPS 140-3 approved list: BIP-340 over secp256k1 and NIP-44. The design note The curve is not on the list has the audit. The shape of a profile is settled. It is policy and not a version. It is declared as a c capability. It is negotiated at the handshake as an intersection the way transports are. It is described by a document with its own digest for anyone who needs to cite one. It is never a second protocol tag: a digest compared for equality would partition the network. It never lands inside the digested constants: a change a handful of operators want would rev every node's declared version. What is not settled is whether to build it. Doing so widens the envelope scheme and the agreement-key codec from constants to sets that every implementation must parse. It also needs an envelope convention for kind 30801 and 30811 content that no NIP defines. The trigger is the one this section already uses: a consumer that asks. Until then a compliant deployment is a gateway boundary and the base does not move.