WIP: discover peers from cjdns #1316
Conversation
| interval = 5 | ||
| } | ||
| return discovery.NewCjdnsService(h, time.Duration(interval)*time.Second) | ||
| } |
There was a problem hiding this comment.
setupDiscoveryOption will need a refactoring. Right now it can only use either MDNS or Cjdns. This is also a bad place for the default interval.
still not 100% sure we want to allow dialing of peers without the key-- this is a step that's dangerous to do normally (it encourages people to put addresses out there without the keys, thus allowing lots of MITM). i'd prefer a cjdns-specific solution where we use the cjdns key for the ipfs node, or to make the cjdns discovery routine actually get the key (by opening a connection to the node, getting the key from the handshake, and closing the connection) -- before real dial happens. (a bit inefficient, but perhaps safer, as in the cjdns specific case, the network transport case gives us security) |
this is great!! |
|
maybe we could add |
Agreed, I just thought I'll make it part of swarm_dial.go in order to avoid duplication. It's probably better to have it duplicated for now, and refactor later once it's definitely what we want. The service is small and contained, so the risk is low.
This would still require changes to both the code that expects an ID, and code that deals with IPv6. I think the other option of having the service fetch the ID before dialing, is less complicated. |
SGTM! |
|
@lgierth quick update here? |
|
Nothing new at the moment, but fetching the PeerID before dialing, is still the approach I wanna use. I'm closing while it's not committed to get worked on. |
|
Oops, I was something thinking that I hadn't committed to this PR this week. Anyhow, no news at the moment. |
License: MIT Signed-off-by: Lars Gierth <larsg@systemli.org>
License: MIT Signed-off-by: Lars Gierth <larsg@systemli.org>
License: MIT Signed-off-by: Lars Gierth <larsg@systemli.org>
|
@lgierth fine with closing this for now? future work towards this end will be done in libp2p |
ghost
closed this
|
Are there any libp2p issues I could watch about this? I am wondering how integrated to Cjdns IPFS is and does that integration also help with other similar projects like Yggdrasil network? I have been using Yggdrasil more than Cjdns lately as they provide Debian and RHEL repositories and the connections are more stable in my experience. The projects are very similar, but Yggdrasil thinks of the network as a tree instead and doesn't require supernodes. I wasn't able to find issues on this repository with the search Yggdrasil. |
There isn't currently any built-in integration. Really, I'm not sure there needs to be any work to integrate the networks given that cjdns adds a virtual interface. That is, you should be able to run This patch just used CJDNS as an additional source of potential IPFS peers. |
Cjdns provides a private and authenticated IPv6 network on top of UDP or Ethernet. We can use its peer list ("peerstats") or routing table ("nodestore") to discover peers and assume IPFS might be running on port 4001.
This PR introduces a discovery service analogous to MDNS, which polls cjdns' admin API and then dials each of the possible peers.
It already discovers peers, but does not yet dial them, since dialing requires the peer ID. A little refactoring of swarm_dial.go will enable dialing without a peer ID. An idea for that will follow in a comment.