Would love to get constructive criticism! The content is immutable, but there is always IPNS (which doesn’t seem to work lately ). If it does work the blog is here /ipns/QmRf4ERGvYpVo6HRa2VueZT8pWi8YvyLS3rW6ad2y83tdN
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.
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.
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.
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
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.
> 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:
it was cached (60s)
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.
). If it does work the blog is here 