Understanding the IPFS White Paper part 1

Not exactly a tutorial, but a journal of my quest to learn more about the blockchain and friends.

http://decentralized.blog/understanding-the-ipfs-white-paper-part-1.html or the IPFS version http://decentralized.blog:8080/ipfs/QmdWqYCc8qanDjj8GvmYazyXynE4KpUyFxKegAcjJuwrmn/understanding-the-ipfs-white-paper-part-1.html

Would love to get constructive criticism! The content is immutable, but there is always IPNS (which doesn’t seem to work lately :grinning:). If it does work the blog is here /ipns/QmRf4ERGvYpVo6HRa2VueZT8pWi8YvyLS3rW6ad2y83tdN

6 Likes

Is the node that you’re publishing the IPNS hash from kept online consistently? Based on this issue in the go-ipfs repo, my understanding is that IPNS is not nearly as distributed as IPFS content in that almost all IPNS queries have to reach out to the origin node. If the node is not online it might account for IPNS seemingly not working.

FWIW the IPNS address loaded for me as of writing this post, though it was slower than the IPFS address.

1 Like

I can confirm (at least for an IPNS address I just tested) that it still loads via the gateway, even if my node is not online. I think the ipns resolve error happens when the originating node has been offline too long or hasn’t been online long enough to republish to the IPNS, which to my knowledge happens after 24 hours at the latest. (?) Okay, if a gateway node doesn’t have all the files pertaining to a current IPNS state, then even republishing won’t help much, so I assume that the content itself needs to be distributed on the IPFS in some form as well. Then it should work.

1 Like

From reading various discussions on GitHub it sounds like nodes that have resolved the IPNS address will cache them for a while (not clear how long) and still resolve successfully – assuming the IPFS hash it points to is available.

Apologies for the sidetrack from the OP. I think the blog post content is a great introduction to IPFS and decentralized concepts in general.

1 Like

Thanks! :slight_smile:

BTW my node is not always online; it uses too much memory for my VPS. I’m upgrading now to see if that helps to keep the node running.

Some debug info, when asking the DHT directly I get a response fairly fast (a couple of seconds):

$ ipfs dht get -v /ipns/QmRf4ERGvYpVo6HRa2VueZT8pWi8YvyLS3rW6ad2y83tdN

13:10:16.982: adding peer to query: <peer.ID Rs6NGK>
13:10:16.992: adding peer to query: <peer.ID UAiZHA>
13:10:17.225: dialing peer: <peer.ID Rs6NGK>
13:10:17.225: error: dial backoff
13:10:17.235: dialing peer: <peer.ID UAiZHA>
13:10:17.425: error: dial attempt failed: failed to dial <peer.ID UAiZHA> (default failure)
13:10:17.553: got value: ’
4/ipfs/QmdWqYCc8qanDjj8GvmYazyXynE4KpUyFxKegAcjJuwrmn # + some binary data

When doing this, it never responds (keeps on hanging):

ipfs name resolve QmRf4ERGvYpVo6HRa2VueZT8pWi8YvyLS3rW6ad2y83tdN

Not sure if that helps to understand what is going on?

Try doing this instead. Your command also hangs for me, but the one below does not. It seems that either the command documentation for ipfs name resolve or the functionality is incorrect since it shows both versions (with and without the /ipns/ prefix) working.

ipfs name resolve /ipns/QmRf4ERGvYpVo6HRa2VueZT8pWi8YvyLS3rW6ad2y83tdN

@leerspace that looks like a bug to me. If you can provide a instructions for recreating the error, please post a bug report at https://github.com/ipfs/go-ipfs/issues

FWIW both versions of the command work for me with the IPNS hash you referenced, though the version with /ipns/ included in the address resolved faster.

Make sure you published first.
It works for me:

> ipfs name publish QmXgBq2xJKMqVo8jZdziyudNmnbiwjbpAycy5RbfDBoJRM 
Published to QmVeAk2VoByW8mRXfqjorEGzxmRyY6KaPPgELRcUGuKsSM: /ipfs/QmXgBq2xJKMqVo8jZdziyudNmnbiwjbpAycy5RbfDBoJRM

> ipfs name resolve QmVeAk2VoByW8mRXfqjorEGzxmRyY6KaPPgELRcUGuKsSM
/ipfs/QmXgBq2xJKMqVo8jZdziyudNmnbiwjbpAycy5RbfDBoJRM

@flyingzumwalt second version resolved for you faster for either for those reasons:

  1. it was cached (60s)
  2. it wasn’t cached but you were already connected (because you resolved it) to the peers containing the data you need in their DHT

@flyingzumwalt @Kubuxu My bad. I just tried the first version again, letting it run as long as it wanted before canceling the command and it eventually resolved.

I did publish it of course.

BTW your IPNS resolves for me, but it takes about 30-40 seconds (the first time).

We are working on making IPNS faster.

5 Likes

Let me know if I can help somehow (ad hoc testing of new releases e.g.)

someone said that the ipns peer needs a reload in every 12 hours.

Great!
Sorry for going off-topic, but can you please share the issue / PR so we can contribute? thx

Check section IPNS Improvements in go-ipfs 0.4.14 (Note: documentation may be missing until this is closed)

This was great! Keep them coming.