I queried the Alexa Internet Top 1 Million websites list to discover DNSLink entries in an attempt to discover how many websites [attempt to] distribute over IPFS.
I was only able to resolve and load 29 % of the domains that had setup DNSLink. Does anyone have any insight into why websites don’t seem to be able to keep up their IPNS and IPFS presence?
Because they don’t know Eternum
Do you have a breakdown by dnslink type (/ipns/ vs /ipfs/)?
As mentioned in the article, Eternum can’t really help with IPNS.
Yes, see the above link for details and source material.
The majority of dnslink entries you found are for /ipns/ addresses, which doesn’t surprise me at all that they won’t resolve due to the requirement of having the publishing node remain online. I think there’s a reason that Protocol Labs’ websites all currently point to /ipfs/ paths (at least, indirectly) rather than /ipns/ ones. And I think that reason is that IPNS currently has some issues specific to IPNS. IPFS in general is self-admittedly still under heavy development and not production-ready (according to their github repo) which also doesn’t lend itself to widespread production use at this point.
If we look at the /ipfs/ paths (or /ipns/ paths that point to another domain which points to an /ipfs/ path) the success rate is 50% (possibly a bit lower if we consider that even if the parent hash is available the entire site might not be). I’d tend to attribute the low success rate even for these paths to people using IPFS as something to play around with or test with rather than something that’s their primary deployment platform – and so don’t bother to make sure it’s available. The other factor is that people accessing these sites are likely not using IPFS at all to access the sites which doesn’t help with availability. Browsers don’t ship with IPFS support so the number of people actually using the dnslinks to resolve and cache the site as they browse is probably very low.
resolves, alexa rank, domain, dnslink records
yes, #17495, ipfs.io, "/ipns/website.ipfs.io"
no, #55588, avsim.su, "/ipfs/Qmc2UTyFv4qD4LDRAAoMnSRiQMNy63t5wUgq9Y83YmUJuJ"
yes, #235414, _dnslink.dallasmakerspace.org, "/ipfs/QmcgHMhAzAqZpQUnarDhqA8XhAbYuHuixkUH2r5T8S9YtP/"
yes, #379024, _dnslink.filecoin.io, "/ipns/website.filecoin.io"
no, #409990, originprotocol.com, "/ipfs/QmcFM7wh7KwEsRZWFG5dyV1kmbBgUSZwiYeSScPErKysVS"
no, #758417, peej.co.uk, "/ipfs/QmaBEAir6UE8JHb2wk2EgQeK2gbcJ4JChRbC9k8n13M4sx"
This is great research, thanks for sharing
I have a project called Temporal (https://github.com/RTradeLtd/Temporal) and it can definitely help with IPNS, amongst other issues with IPFS.
If you want to try the web interface, which has pinning, key management, file uploads, IPNS record management , and more check out the following link.There really isn’t anything else like it right now, and its 100% free to use until December 31st 2018:
I’m also working on an experimental project called TNS (Temporal Name Server) which is an attempt at speeding up IPNS name resolution:
Temporal currently has support for publishing DNSLink entries to Route53, other DNS providers can trivially be added. Furthermore, there is fine-tuned control of IPNS record publishing. You can publish records using either RSA or ED25519 keys, and have control over the lifetime, and ttl. All through our web interface which is incredibly easy to use. Should you wish to just use an API instead, our web interface is simply a “GUI wrapper” around an API which is accessible as well.
The biggest comparison right now for Temporal would be eternum. While pinning services themselves wouldn’t help to alleviate some of the issues in the article. I’m fairly positive that Temporal is an extremely adequate solution. Key management like you point out is definitely something that requires the end-user to relinquish (at-least temporarily), however there is no difference between this, and say, having an account registered with go daddy, or Route53.