I2133

What it is

Objective

Bound the discovery channel, every reply a runtime reads and the candidates it accepts; answer a refused registration with its refusal alone; and give every link retry a floor and jitter.

Why

The provider channel is unbounded (apps/majordomus-cli/src/mesh/manager.rs:425 channel()) and feeds one thread that runs an Ed25519 verify per datagram, with no per-source rate and no drop counter (threat T3). Rendezvous and link replies to the dialer are read with an unbounded read_to_end (apps/majordomus-cli/src/mcp/bridge.rs:84-85) under a per-read timeout only, so a slow trickle holds the worker and the per-runtime round lock (apps/majordomus-cli/src/mesh/cooperation.rs:2383-2387) (T4), and the candidate count received is unbounded. docs/MESH.md:341 lists 'messages (900 KiB)' as a flood bound, which holds only for what the answerer receives (apps/majordomus-cli/src/mesh/cooperation.rs:1769-1779, 2010-2020) and the dialer sends (apps/majordomus-cli/src/mesh/link.rs:883-888). mesh.register answers its own envelope and up to 32 candidates even when the caller's envelope is refused (apps/majordomus-cli/src/mesh/manager.rs:623-636), and the candidates include untrusted nodes of any repository (apps/majordomus-cli/src/mesh/registry.rs:342-357) (T2, T13). An UnknownLink answer is retried with zero delay (apps/majordomus-cli/src/mesh/cooperation.rs:2592-2595), so a peer that welcomes and then refuses sync drives a busy loop, and the link backoff has no jitter (apps/majordomus-cli/src/mesh/cooperation.rs:2611-2614). Baseline audit of 2026-10-09 at master 1fb8d6be44, mesh gaps 5 and 11, threats T2, T3, T4 and T13, drift 5.

Now

Inputs the answerer receives are bounded; the discovery channel, replies the dialer reads, received candidates and registration answers are not.

Wanted

Providers send through a bounded queue (OBSERVATION_QUEUE, 1024) whose drops are counted as overflow in mesh.status refusals; a refused registration is answered with the refusal alone, and an admitted one with this node and the trusted nodes of the caller's own repositories (MeshRegistry::candidates_for; the unfiltered candidates is gone); an answerer that keeps answering unknown_link is retried no faster than a heartbeat after the first immediate retry. The deferred part, the dialer's reply and candidate bounds, jitter on the link backoff and a test of the unknown_link retry rate, is I2704.

Done when

unknown: the record declares no `completion`

Risk

unknown: the record declares no `risk`

Acceptance

Scope

Touches

apps/majordomus-cli/src/mesh/manager.rsapps/majordomus-cli/src/mesh/rendezvous.rsapps/majordomus-cli/src/mesh/registry.rsapps/majordomus-cli/src/mesh/cooperation.rsapps/majordomus-cli/tests/mesh.rsapps/majordomus-cli/tests/mesh_cooperation.rsdocs/MESH.md

Not

unknown: the record declares no `non_scope`

Depends on

none

Priority

p1

Profile

implementation

Parallel safe

false

Owner

unknown: the record declares no `owner`

The work so far

Synchronisation

Adapter

scripts/github-sync

Repository

unknown: the derived plan's header carries no repository

External issue

unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

State there

unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.