Join GitHub today
How does Resolution and Routing work with IPFS? #48
If the content that I request is on a device (say a tablet) 2 or 3 devices (i.e. hops) away from me, will IPFS, flood forward my request to neighboring devices until it finds the content? Once found, will it establish a connection through the neighboring devices long enough to download the content?
I recently wrote out a full description of content resolution and routing. here it is.
This assumes knowledge at the level of this talk: https://www.youtube.com/watch?v=HUVmypx9HGI
How Routing and Resolution works in IPFS
The abstract is this:
In short, today we use a global DHT and DNS to resolve routing records. But this is well layered and users can choose among suitable protocols.
What Paths (URIs) Look Like
Paths (URIs) in IPFS look like unix paths beginning with "/ipfs/..." or "/ipns/...". The canonical path is not a web-style scheme ("ipfs://") because
IPFS paths are either mutable or immutable. these links are resolvable through IPFS, and we can use an HTTP gateway we provide at https://ipfs.io to do it for us. So, these are only HTTP to our gateways so you can see them, but it's IPFS doing the work underneath!
Immutable Paths (URIs)
This is a fantastic article and the video did shed a lot of light on merkledag. I have a semi-related question though. Last year someone was talking to me about a new residential indoor wireless spec that focused on long range (a few miles) over bandwidth and had an P2P component. So a community with a few of these wifi hotspots could route internet access through one or two shared connections. If an access point goes down, the other access points could route around it. I've been looking for the technology for a year and I have no clue what it is. He said it was still a spec and a long way from being ready for commercial use but I want to find it anyway so I can keep tabs on the tech. I'm sure some of what he was telling me was pie in the sky but a new wireless protocol with long range P2P capabilities would be a good fit for IPFS.
@jbenet in the description you give above could you expand a little on:
From the ifs spec I understood that nodes have an identity based on a public/private key pair that is used to sign IPNS mutable records.
But the above suggests that a Node may have control over 'other' public/private key pairs that can be used to sign and publish IPNS mutable records.
Is this a feature? and could it be used to create virtual or offline peers that generate content but do not actively participate in the IPNS routing or block exchange?
Regarding IPNS, does a daemon on a peer need to be running for other peers to resolve the name of this peer?
I published some content via ipns name publish, resolved it via the public ipfs gateway (gateway.ipfs.io/ipns/....), and the published content was displayed. Then I shut down my PC (where the daemon was running) and tried resolving it again later. Got an error message "Path Resolve error: could not resolve name.".
referenced this issue
Sep 27, 2016
This issue was moved to https://discuss.ipfs.io/t/how-does-resolution-and-routing-work-with-ipfs/365