Integrate with IPFS (IPNS) to solve problem of moving peers (dynamic IP addresses)

[pruflyos]

Let's imagine you want to connect to nodes which don't have a static IP address, but are moving or only get dynamic IP addresses assigned which change over time. Especially, what if none of the peers in the meshnet has a static IP address?

Problem: cjdroute.conf doesn't seem to allow to specify hostnames for peers which are resolved via DNS. The "connectTo": {...} sections of the config only allow IPv4 and IPv6 addresses to be specified. Even if hostnames were allowed in the config, you would have to rely on a centralized DynDNS service the peer uses whenever it's public IP address changes.

Here's an idea how this may be solved using IPFS/IPNS

Both, cjdns and ipfs, use Ed25519 keys. So theoretically the same key that is used to derive and secure the cjdns ip6 address, could be used as an ipfs key that controls (and can update) IPNS records. So whenever the public IP address of a peer changes, the peer just needs to add a new record to IPFS and update the IPNS link:

$ echo -n "217.182.195.23" | ipfs add -q
QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk

$ ipfs name publish --key=cjdns /ipfs/QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk
Published to QmfC3rb8kzDj4JHzZghBi2NVHpNAEpu9ACeFChRqB56Rmt: /ipfs/QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk

Now, whenever cjdroute can't connect to a peer that supports this mechanism, it could query IPFS to see if the peer's IP address changed and if so, try again:

$ ipfs name resolve QmfC3rb8kzDj4JHzZghBi2NVHpNAEpu9ACeFChRqB56Rmt
/ipfs/QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk

$ ipfs cat /ipfs/QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk
217.182.195.23

Further thoughts

• The fact that cjdns and ipfs both use Ed25519 keys is not a necessity. It would just ease the configuration, if the IPNS name (public key) can be derived from the cjdns peer's public key automatically without additional configuration. However, you could also use a different keypair for IPFS and allow the IPNS name to be configured for a peer in cjdroute.conf.

• Of course this mechanism would be optional and only available if ipfs is locally installed and running as daemon in addition to cjdns.

• The ipfs record (current public IP address) could be (symmetrically) encrypted before pushing the data into IPFS for privacy reasons, e.g. using a hash of the cjdns 0xfc address. This way, the peer who's querying IPFS for the record is still able to decrypt it (because it knows the cjdns address of the peer it wants to connect to), but other IPFS node operators who are just forwarding/serving the record can't harvest and decrypt it and link the IP address to a running cjdns instance.

• To protect against some sort of DoS attack, where a peer maliciously points it's IPNS record to a very huge file, the peer who wants to establish the connection could check the file size (bytes) of the data record first, before actually fetching it: $ ipfs block stat QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk Key: QmXgqbh3FbaW5L6Wdq1b4UCPSurHA499yDTSvMbGrGbHQk Size: 22

[progval]

Note: cjdroute used to support hostnames, but it was removed.

[Macil]

Small tip: you can do ipfs cat /ipns/QmfC3rb8kzDj4JHzZghBi2NVHpNAEpu9ACeFChRqB56Rmt. You don't have to resolve ipns entries in a separate step.

[pruflyos]

@ProgVal Do you know why support for hostnames was removed?

[pruflyos]

@AgentME Check the last item in "Further thoughts" of the original post I just added. You might want to resolve first and check the size of the target before blindly fetching it!?

[Kubuxu]

@pruflyos because it was misleading, it was resolving the hostname when starting cjdns node (when the configuration was being applied) and people were complaining that it should resolve it before every connection attempt.

[JhonnyJason]

Any update on this or hints which research I need to do it myself?