Example ipfs-kad is broken

[FedericoPonzi]

Command:
cargo run --example ipfs-kad
Expected behaviour:
"Query finished with closest peers: ..."
Actual behaviour:

Searching for the closest peers to PeerId("QmZy9TwDKSZiMDPUeDnsNvMKfX6GFsCHJqmmLQs91ecyEe")
thread 'tokio-runtime-worker-2' panicked at 'Query finished with no closest peers.', examples/ipfs-kad.rs:104:33

I've also tried to replace the ip address / peer id with others from ipfs bootstrap but still getting the same error.

[tomaka]

The last time I've checked (a few months ago), there were two ongoing issues:

• Most of the IPFS bootnode addresses are not responsive.
• All the responsive bootnodes only support RSA with 1024bits key.

Unfortunately, the Rust library for RSA that we use (ring) doesn't support 1024bits keys anymore, as they are considered insecure. We therefore can't connect to any node.

[koivunej]

An almost offtopic update related to this but likely interest of anyone looking into ipfs compatilibity:

TL;DR: Don't try with ed25519 keys, use rsa (for now).

With https://github.com/dvc94ch/rust-ipfs/pull/37 I managed to transfer a single block from a local go-ipfs node to local rust-ipfs (small steps) and turned out the major incompatibility is with using ed25519 keys, which turn into different peerids by different libp2p impls. If this is worked around for secio the nodes will still use their incompatible versions of peerids for dht which simply does not work (this part has not been confirmed other than that "it does not work").

On the linked PRs commits and changes there are more links on the compatibility if you are interested.

[tomaka]

which turn into different peerids by different libp2p impls

This might be related to peer ids inlining. See #1230 for context.

[koivunej]

This might be related to peer ids inlining. See #1230 for context.

Yes. Had not noticed the PR. Also for more context libp2p/specs#138 ... Couldn't find an issue related to this in go-libp2p but the relevant code: https://github.com/libp2p/go-libp2p-core/blob/dc718fa4dab1866476fd9f379718fdd619455a4f/peer/peer.go#L23-L34

[FlorianFranzen]

As far as I understand the inlining is implemented according to spec since #1413, but I still do not seem to be able to query the IPFS DHT from Rust using ed25519 keys.

[romanb]

Could someone elaborate what is still broken with the ipfs-kad example w.r.t. the current master branch? It seems to "work" for me in the sense that it usually yields peers. It may sometimes happen that the response from the very first peer is too large for libp2p-kad, which currently has a 4kb limit on payloads, in which case no peers are found, and there are typically plenty of failed connection attempts to various nodes, which is to be expected. You can get more details on what is happening if you run the example as follows:

RUST_LOG=libp2p_kad=trace cargo run --example ipfs-kad

[tomaka]

As a note, all the IPFS bootstrap nodes are deprecated except the ones that use the /dnsaddr multiaddress format.
#1450 would eventually make it possible to reach them as well.

[tomaka]

For note-keeping, I can see two kind of suspicious errors on the protocol when querying IPFS:

[2020-03-09T13:31:51Z DEBUG libp2p_kad::behaviour] Request to PeerId("QmUd6zHcbkbcs7SMxwLs48qZVX3vpcM8errYS7xEczwRMA") in query QueryId(0) failed with Io(Custom { kind: PermissionDenied, error: "len > max" })

And

[2020-03-09T13:32:10Z TRACE libp2p_kad::handler] Inbound substream: EOF

The first one is what Roman mentioned, and increasing the maximum allowed packet size removes the errors.

[romanb]

There shouldn't be any remaining issues with the libp2p-kad example. In any case the original issue mentioned by the author of the ticket should no longer be present. If someone perceives what seems to be open issues with the ipfs-kad example, please open new issues.