From c4aece4883b21d5e4fe2bb3953f580428fd048b2 Mon Sep 17 00:00:00 2001 From: archipelago Date: Sun, 2 Aug 2026 23:24:16 -0400 Subject: [PATCH] docs(01-04): on-node verification, and the send half is inert here MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Deployed 6b3693dc to archi-dev-box off a clean tree and exercised the real RPC surface. lnd.getinfo returns a real identity_pubkey through the field that did not exist before this plan. mesh.lightning-peers returns an empty array with success — the FED-05 empty edge proven on hardware, not just in a unit test. Both refusal paths of mesh.send-lightning-info observed live, including T-01-13's "no broadcast form". The finding worth carrying to 01-06: this node's LND advertises no URI (uris: []), so send-lightning-info correctly refuses rather than shipping an empty advertisement a peer would store as an undialable target. The receive and list halves work; the SEND half is inert on any node whose LND has no externally reachable address. The picker must not assume the local node always has something to share. Corrects this summary's own earlier claim that nothing was exercised on hardware — that was true when written and is not now. The mesh leg proper (an advertisement crossing real RF into a peer's lightning_uri) remains unproven and is still called out as such. Co-Authored-By: Claude Opus 5 (1M context) --- .../01-04-SUMMARY.md | 23 +++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md b/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md index b897a207..0c8af9a0 100644 --- a/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md +++ b/.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md @@ -125,10 +125,29 @@ The mutation was reverted and its absence verified. This is stronger evidence th pre-implementation red run (which only shows the code is absent, not that the assertions bind), but it is a deviation from the ordering the plan asked for, and is recorded as one. +## On-node verification (archi-dev-box, deployed 23:16) + +Deployed at commit `6b3693dc` off a clean tree and exercised over the real RPC surface: + +| Call | Result | +|---|---| +| `lnd.getinfo` | `identity_pubkey: 024a5fd7de13623aeec81095…` — a real key, deserialized by the field that did not exist before this plan. `alias: "Archipelago Node"` | +| `mesh.lightning-peers` | `{"peers":[]}` — **success with an empty array**, not an error. The FED-05 empty edge, proven on hardware rather than only in a unit test | +| `mesh.send-lightning-info` `{}` | refused: *"Missing contact_id: … requires an explicit target and has no broadcast form"* — T-01-13's mitigation observed live | +| `mesh.send-lightning-info` with a target | refused: *"This node has no advertised Lightning URI to share — LND may be down, or configured with no externally reachable address"* | + +**A real finding from that last row:** this node's `lnd.getinfo` returns `uris: []`. Its LND has +no externally reachable address configured, so it *cannot* advertise itself to a peer — the +handler correctly refuses rather than sending an empty advertisement a peer would store as an +undialable target. The receive and list halves work; the send half is inert on any node whose +LND advertises no URI. **01-06 must not assume the local node can always share its own URI**, +and the picker needs a sensible state for "you have nothing to share yet". + ## Open / handed on -- **Nothing here is exercised on hardware yet.** Two archy nodes with LND and a radio link are - needed to see a real advertisement traverse the mesh; every claim above is unit-level. +- **The mesh leg is still unproven end to end.** Two archy nodes with LND and a radio link are + needed to watch a real advertisement traverse the air and land in a peer's `lightning_uri`. + Everything above is either unit-level or single-node RPC. - `mesh.lightning-peers` is a data source with no consumer until **01-06** builds the picker UI (which `depends_on` this plan). - `MeshPeer.lightning_uri`'s doc mentions federation seeding as a future source; this plan does