Bittorrent transport layer, peer-to-peer is not encrypted, neither was IPFS last time I checked. Is it now? Has that changed?

There is nothing stopping Bittorrent clients from agreeing on "this dht will be global", and similary, what stops IPFS clients/peers from forming a different DHT? Nothing as far as I know, not like scuttlebutt which has a transport-layer network-wide key.

What about trackers, bittorrent can but does not work well without trackers, so its not really according to me, decentralized, since some peer is more equal than another peer.

IPFS is meh, datproject is where its at.

IPFS has perhaps 2,000 times the resources ($) of dat. (Raised via the filecoin sale.) Surely that must count for a little.

Considering how much resources, github starts, and fanbois IPFS has, and yet the network layer is still shit, bandwidth not utilized to fullest.

Instead of just reusing bittorrents piece-per-peer-exchange-protocol (that greedy not perfect algorithm, forgot its name) - which can saturate even high end links, they invented bitswap, full with bugs, then decided lets make filecoin instead, like a bartering engine of exchanging pieces.

datproject also can saturate my 250mbit connection.

Thanks for posting. Never heard of DAT before but it looks to be exactly the BitTorrent alternative I've been looking for

Check out hyperdb and hyperdrive (implementations of the core replicable data structures used in dat)!

One more note: dat's implementation is quite modular, the hyper* libraries are designed to be replicated in a network-agnostic way.

(Theoretically you can do this with IPFS too, but I love how dat is implemented!)

I'm trying to get a foothold in this space (this space being whatever the area of camlistore/perkeep - ipfs - dat - etc.

I've also been excited that Dat seems to be investing a Rust implementation that would presumably make Dat accessible from any language that can interoperate with C/Rust.

Yeah, I'm keeping an eye on the rust implementation of hyperdb!

It might make it count for less, considering the liability it now has to make investors whole

It was an ICO, there are no such liabilities.

It should, but it might end up not.

BitTorrent has Infohashes which allow you to download a torrent merely by entering the hash (not to be confused with magnet links, which may also be just pointing towards the infohash)

True, but one big caveat with BitTorrent is that if you change 1 byte in the whole (often multi-file) thing the info-hash will be different and you'll end up in a new DHT entry all by yourself. With IPFS you'd still share all the other blocks of content with the whole network, only the modified block will be “yours alone”.

Where this happens to be particularly annoying with BitTorrent are aggregate Torrents: You have a bunch of separate files available for download (think TV series or books) each forming its own DHT node. Then somebody decides to create an aggregate torrent (such as libgen's “1000 books” torrents) and offers that for convenience or efficiency reasons. Will the clients that previously downloaded the individual files share them with this new torrent? No! Because the new Torrent “is different” even if each of it's files are byte-by-byte identical.

Could BitTorrent be upgraded to allow for this? Probably, but it'd be radical paradigm-shift requiring a redesign of everything (“BitTorrent 2.0”). So why not start from scratch with a new protocol entirely?

There are actually several protocol updates in the works (and some fundamental work like pubsub has been finished) to enable torrents that can be upgraded, it doesn't require a radical paradigm-shift at all.

A protocol that does what torrent does but better would be dat://, IPFS is terrible at being BitTorrent but better.