Hacker News Reader

Comment by rhn_mk1 | Hacker News Reader

One thing I'm missing (or misunderstanding) about IPFS is updates.

In a centralized system, like HTTP, a site has a single address: something.example.com. Any new entry (e.g. blog post) I create gets its own entry address, but is also referenced from the main site address.

As far as I understand, IPFS contains static copies of documents, so any document that would be the "front" page would have to be copied before updating with new entries, and would receive a new address.

How to let readers know that a new entry is available then? Would there need to be a centralized place referencing all existing entries?

View on HN

One word: IPNS.

It's a DNS-like system, though much slower than DNS due to propagation delays. It points to the latest version (hash) of a document, much like a git branch.

Being slow is kinda a deal breaker for a status page, isn’t it? The whole point is to notify your customers of an issue, and you need to do that fast. Most issues are only going to last a few minutes anyway, so any delay in update makes the whole thing pretty moot.

There's a PubSub implementation for IPFS that can provide support for dynamic content in this case. I'm pretty sure there is another way to provide fast updates through some indirection mechanism though.

https://ipfs.io/blog/25-pubsub/

Yup, I agree that IPFS is not the best choice.

The slowness of IPNS is something we're actively working on. Currently we have fixed so resolutions are faster after the first lookup, by using the libp2p feature pubsub. It being faster/slower than DNS depends on your case, but if you're close to the next node, it'll probably be faster. If you're offline, DNS won't work at all :) We also have more fixes for IPNS in general that will come soon.

So, depends on your use case in the end.

Disclaimer: I work for Protocol Labs on IPFS

Now if my service is screwed up enough that I can't host my own status page or easily find another service to host my status page - like all of Amazon's infrastructure or the entire east coast fiber network or something like that is down - I can see where IPNS would be useful for hosting. But since standard DNS is already distributed, why can't I continue using that to do name resolution? Why does IPFS need its own reimplementation of DNS?

(I ask this as someone very unfamiliar with IPFS, so please forgive if this is a stupid question.)

First, thanks for your work on IPFS.

I've been trying to get into IPFS recently. One thing I can't wrap my head around is that IPNS only seems to persist for about 12 hours and then stops working.

It seems to defeat the purpose of a truely distributed name system, as my computer that needs to keep republishing the name becomes a critical part of the system?

Am I missing something or are there plans to resolve this in the future?

How slow are we talking? Hours, days? Or seconds, minutes?

For IPNS, my experience says it could take up to 30 seconds to publish and up to 10s to resolve.

Not a network person by any means, but I think that this points out to what I think is the fatal flaw of IPFS: the apparent "one-wayness" of addresses to content.

Yes, I know that is supposed to be its main feature, but (again, naïvely speaking) it seems to induce a huge, possibly even intractable overhead... Think of, say, programming in C without being allowed to ever rewrite memory contents, or change what a pointer points to!

Again, not an expert; and I'm sure with all the money they raised, people with actual technical expertise in network protocols are hard at work on this and can vouch for the design... But I'm curious anyway how this is not an obvious dealbrealer, given the extreme latency requirements in networking..

Reply on news.ycombinator.com