5 ms·

From Dat's FAQ https://docs.datproject.org/faq https://docs.datproject.org/faq How is Dat different than IPFS? IPFS and Dat share a number of underlying simil

From Dat's FAQ https://docs.datproject.org/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.

amelius 9y ago
> 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 https://github.com/ipfs/faq/issues/83
- pwang 9y 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.
  - sull 9y 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.
- filiwickers 9y 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 https://github.com/datproject/dat-http

amelius 9y ago

> 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 https://github.com/ipfs/faq/issues/83

pwang 9y 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.
- sull 9y 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.
filiwickers 9y 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 https://github.com/datproject/dat-http