@maxnym thanks for coming in. Three things from the Nozy / dialling-half side.
1. Reliability layer (probe / watchdog / open-3)
Glad you called this what it is. On our side it was never “debug until the demo works” it is how a wallet-shaped caller survives silent first-payload loss. @Joaco owns the proxy design; we ran the external client half and published the numbers (Aug 15 load → PR #3; dead vs live midnight windows; GetLightdInfo over :9068, not TCP-only).
We are happy to support turning that into something the SDK can run modules through. Joaco already said yes to writing the layer and bringing wire format as an issue on nymtech/nym first. From Nozy: we will keep producing independent client-half evidence (same gateway class, different machine) so any PR has a second measurement path, not only Joaco’s serving half.
If you want a short design note from the wallet caller’s view just let me know as well.
2. Threading no node with identity … is known up the stream
Yes, please do that. Same class of bug we hit when the far end is gone from topology: SDK already knows (WARN), caller gets silence until its own deadline. A catchable connection error would have saved a night of guessing. The “gateway alive, nobody home at that address” case Joaco split out can stay opaque; the known-identity miss should not next one.
3. Rerun on develop + what we still need from you
Joaco’s [#20] correction (orphan buffer / #7057 — 0/400 on develop vs ~21% on 1.21.5-rc.3) matches a suspicion on our earlier 55–60% per-stream bench. We will rerun the dialling-half load on develop when the serving half we point at is on that pin, and post evidence the same way as Aug 15/20 (metrics + whether first-round / unestablished move).
I had a question about the fast mode pin to get this started.