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?
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.
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.
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.
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..
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.