Hacker News Reader

Comment by fergie | Hacker News Reader

DAT is run by influential hobbyists of independent means, with occasional funding from non-profit organisations.

IPFS is essentially run by a very well funded (300musd) private company.

For this reason alone I think DAT is the more likely to succeed. It seems hard to reconcile the longevity of a truly distributed protocol with the need of a private company to retain control.

View on HN

> IPFS is essentially run by a very well funded (300musd) private company.

That is news to me - I've thought they were a scrappy startup. The issues mentioned in the post like glitches in the docs are excusable for a project that relies on volunteers who prefer writing code to polishing docs, but if you have $300M in funding then wtf? Just, you know, hire good project management and docs people.

My understanding was that most of the team focus has shifted over to the filecoin project in the last year or two, and they aren't dedicating as many resources to ipfs. That said, I agree that this is pretty deplorable.

Several of the key members have shifted focus but there's still a core IPFS team. But we're still spread quite thin.

We're still paying down years of documentation debt but there has been quite a bit of progress:

* Expanded https://docs.ipfs.io/ with a concepts section. * Tutorials https://proto.school/#/ * A ton of work on libp2p specs (https://github.com/libp2p/specs/commits/master) along with a full time documentation writer.

My bet is both likely to fail. NIH syndrome is strong with both cases.

For efficient file transfer protocol between peers, Bittorrent protocol have multiple independent implementations that is working right now. They should build on top of that. Instead, both DAT and IPFS try to implement their own protocol with dubious additional features. For IPFS, it even relies on traditional DNS. What are they thinking?

IPFS doesn't rely on DNS. Most Dat deployments do, however.

Except that, from the article, the only way to really use IPFS for pretty names is to use DNSlink and not IPNS. Because IPNS is unusably slow.

So IPFS might not theoretically rely on DNS, but it seems that it does practically rely on DNS if you actually want to use it.

If you want to use it with DNS names, yes.

I have a hunch that IPNS is just broken in its implementation (manifesting as "unusably slow") but I haven't yet had the spare time to investigate this theory..

This strikes me as a little disingenuous. Neither IPFS nor DAT are inherently dependent on DNS. If you're referring to HTTP the gateways that lots of people use with both IPFS and DAT in order to host static sites, arguably that's because support for UDP and other useful p2p tools in the browser is experimental! But people still find both IPFS and DAT useful for hosting static files. (libdweb is really exciting by the way: https://github.com/mozilla/libdweb)

From what I can tell, most "serious deployments" of DAT and IPFS are made by people directly using the loose underlying collections of libraries that implement each of them. These people often end up putting together application specific transport and discovery layers that work for their specific application.

> NIH syndrome is strong with both cases.

Seriously. IPFS decided the standard URL format wasn't good enough so invented something worse, which was pretty funny/sad. I never saw reasons for it that made any sense.

See:

https://github.com/ipfs/ipfs/issues/227

[EDIT] here's the original, deeply "LOLWUT?" justification for it, quoted in this comment on another issue. Other justifications were given but this was the motivation. Oh man. Wow.

https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-139...

[EDIT] farther down, same author as the quoted text in the above comment: "wish unix:// wasn't taken by unix sockets." Oh FFS, guys. Hahaha.

Their scheme as described in #227 would make sense, if they were designing IPFS as a service for Plan 9.

IPFS also needlessly rolled their own TLS replacement:

https://github.com/ipfs/specs/issues/29

> I would add that if TLS can be used without all the X.509 nonsense, and with our own choice of pubkeys, including using different signing public keys (not the DHE keys) in the same conn, then we can consider breaking our "not TLS pls" stance.

TLS fit their requirements all along, they just… decided to reinvent it instead of reading about how to use it.

afaik several of the Dat folks worked on Bittorrent implementations beforehand so it's possible they were thinking...something?

Reply on news.ycombinator.com