undefined | Better HN

0 pointsstaticvar8y ago0 comments

From Dat's FAQ https://docs.datproject.org/faq

How is Dat different than IPFS?

IPFS and Dat share a number of underlying similarities but address different problems. Both deduplicate content-addressed pieces of data and have a mechanism for searching for peers who have a specific piece of data. Both have implementations which work in modern Web browsers, as well as command line tools.

The two systems also have a number of differences. Dat keeps a secure version log of changes to a dataset over time which allows Dat to act as a version control tool. The type of Merkle tree used by Dat lets peers compare which pieces of a specific version of a dataset they each have and efficiently exchange the deltas to complete a full sync. It is not possible to synchronize or version a dataset in this way in IPFS without implementing such functionality yourself, as IPFS provides a CDN and/or filesystem interface but not a synchronization mechanism.

Dat has also prioritized efficiency and speed for the most basic use cases, especially when sharing large datasets. Dat does not make a duplicate of the data on the filesystem, unlike IPFS in which storage is duplicated upon import. Dat's pieces can also be easily decoupled for implementing lower-level object stores. See hypercore and hyperdb for more information.

In order for IPFS to provide guarantees about interoperability, IPFS applications must use only the IPFS network stack. In contrast, Dat is only an application protocol and is agnostic to which network protocols (transports and naming systems) are used.

0 comments

4 comments · 1 top-level

amelius8y ago· 3 in thread

> It is not possible to synchronize or version a dataset in this way in IPFS without implementing such functionality yourself

But why not build version control on top of IPFS?

It has been discussed here: [1]. It seems a matter of correctly working with immutable data structures (which IPFS provides storage for). And it seems a bit silly to rebuild that storage layer from scratch.

[1] https://github.com/ipfs/faq/issues/83

pwang8y ago

From what I've read and seen in the docs, faq, presentations, etc., it appears to me that IPFS really pulls in a lot of stuff about the network layer, because it's trying to be, well, an Interplanetary (distributed) File System.

DAT is fundamentally a portable, self-contained, data repository. Replicating DAT archives across a broad network and whatnot is definitely a problem that needs to be solved, but IMO that should be solved at a different layer, without rolling in all sorts of complecting concerns such as network ports, routing, and payments for storage and whatnot.

sull8y ago

Yes, agreed. Of course overlap among projects is inevitable and it would be nice if there was more effort to coordinate and collaborate as this would allow for potential dev efficiencies (not guaranteed though). In this case, DAT is a practical and pragmatic approach where IPFS is more hinged in the crypto blockchain token space which can be a turn-off and add unnecessary baggage. The DAT and Beaker teams don't want to add that noise and have different philosophies, so it is better for now that these projects are independent and in future can assess and maybe a new project will treat both as prior art and converge the best parts. And around we go.

filiwickers8y ago

Ya, we've thought about that. Dat's storage is pretty flexible and we have a content-addressed storage library. A lot of our users do not want or need to storage data in IPFS though so it adds unnecessary complexity to do that by default.

Someone could built a storage that uses IPFS, similar to our dat-http storage [1].

[1] https://github.com/datproject/dat-http

j / k navigate · click thread line to collapse