(16) I would not prescribe the usage of ENRs due to its limitations (previously stated).
I would just state what information is needed per node, and leave it to the consuming protocol to specify how this information is store.
I am not convinced the full codec string for libp2p-mix is needed (if it’s a libp2p protocol). One would probably just need to know it’s a mix node. See (17) for why. In the case of Waku, We would probably just need to add a byte for mix in the waku2 key.
(17) discovered does not mean reachable. From experience with Waku, 80% (@prem to confirm) of nodes found via Waku Peer Exchange are not reachable. And those are filtered out from Discv5.
Discv5 is inadequate due to the lack of Time-To-Live associated to discoverable nodes. This is not a problem in the case of Ethereum, Or Tor, as most nodes are run on VPS or other servers.
This has been shown to be a limitation due to short lived nodes coming from Status Desktop (and tests).
We have done work around it so far because the cost is low (failed attempted connection). Not even sure it’s “low” as we have not measured the cost on battery usage.
In the practical context of Waku/Status app, expecting to find 5 nodes discovered on the layer to form a successful path is… laughable. More PC, it’s the biggest challenge I see here. Fixing the TTL on discv5 (or swapping to another discovery mechanism that better handle short-lived nodes) is likely to become a priority to use libp2p-mix.
Related question: Analysis of Failures in Mix Networks - #2 by fryorcraken
Alternative would be for the sender to have had a recent connection to all nodes in the path, to increase likelihood of success. But this seems to increase risk re de-anonymyzation (just a guess)
Tor Android has a “kindness” mode, to become a “Snowflake” proxy for other Tor users. Would be good to understand how they do discovery for this feature.