Hacker News Reader

Comment by _8j50 | Hacker News Reader

Ipfs.io can solve this easily.

Ipfs requires a DNS server to bootstrap the P2P network, not a good idea.

Plus, Ipfs isn't that good when it comes to authentic data, if it's signed, there is only one key, so it's centralized again.

The implementation could easily change to not require DNS. You only need to find a single live node to bootstrap, so hardcoding a bunch of high-quality nodes works perfectly fine.

Also you don't need the "Where is IPFS?" DNS query to be anonymous in the first place.

Then you still need to trust the initial node to not provide you with a poisoned peer list (ie, a list of peers that are wholely isolated from the proper IPFS network and provide bogus DNS answers).

And you need to bootstrap without DNS if you plan to actually replace DNS, not live beside it.

Anything in the world could theoretically be poisoned. There's no point in worrying about attacks above a certain level of difficulty. If you can check in with a certain number of builtin peers, that's about as solid as we can make things.

> And you need to bootstrap without DNS if you plan to actually replace DNS, not live beside it.

Whatever. DNS itself is never going to shut down, so 100% replacement even for bootstrapping isn't a real concern. And if starting with 13 fixed IP addresses is good enough for DNS, then it should be good enough for IPFS.

Bootstrapping without DNS or bootstrap nodes is possible, if hard, but still leaves some open questions.

Not everything in the world can be poisoned if you design carefully enough, but IPFS isn't a design I'd pick for building the foundation of an internet.

You have to keep in mind ipfs is content-addressed. Instead of resolving names you can resolve certificates by their content addressed thumbprint.

1) boostrap 2) find the cert thumbprint for site.com 3) find the cert by the thumbprint and connect to one if IP SAN records

How do you securely get the cert thumbprint?

You don't need to,even if you get a malicious thumbprint,the associated cert still needs to be signed by a trusted CA. CA list for TLDs will be distributed with the resolver software just like browsers ship with such a list (or rely on your browser/client preferred list)

There are capabilities to use the existing DNS system (or an EthDNS system in the works) for human readable names with IPFS, but you can also use other channels like pubsub to resolve mutable content like IPNS names quickly - so IPFS doesn't actually require DNS at all. Multiwriter IPNS records are also a work in progress, though I disagree with your characterization that somehow only allowing one key to edit a particular signed record somehow makes the network itself centralized...

This isn'T about the IPFS Application Layer but the Link layer.

Bootstrapping a P2P system efficiently requires known P2P nodes and those will require DNS unless you want to shell out for a static IP permanently (and hope nobody poisons ARP!)

What's the economic incentive structure to continue serving all the data in a performant manner?

Reply on news.ycombinator.com