lfg2025/archy
1
0
Fork 0
Code Issues 24 Pull Requests 4 Actions Packages Projects Releases 71 Wiki Activity

docs(01-04): on-node verification, and the send half is inert here

Browse Source 
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) <noreply@anthropic.com>
This commit is contained in:
archipelago
2026-08-02 23:24:16 -04:00
co-authored by Claude Opus 5
parent 6b3693dcc8
commit c4aece4883
1 changed files with 21 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/phases/01-federation-mesh-hardening/01-04-SUMMARY.md
+21 -2
View File
@@ -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