6 ms·

Wasn't dat originally going to be a part of ipfs or was it the browser? What are the reasons for dat vs ipfs?

hobofan 9y ago
Contrary to IPFS dat is more focused on what can be achieved right now while sacrificing true decentralisation, and is more opinonated with providing in its use case with providing things like versioning.
- tbv 9y ago
  What do you think it sacrifices? IPFS is more focused on static blob addressing while Dat focuses on data sources, and in that sense, there’s a single authority over a dataset. But I see that as a positive, since mutability is pretty valuable. TBH, I'm not sure how a site can work without mutability.
  - GhotiFish 9y ago
    a dynamic site can't work without mutability, ipfs can't deal with mutability, so ipfs comes with ipns, which allows you to statically reference content that might change.
    - tbv 9y ago
      Yeah, IPFS + IPNS is effectively on par with Dat archive mutability, but mutability being built-in to Dat + its verifiable history log is particularly well-suited to building peer-to-peer websites
    - vertex-four 9y ago
      Of course, the design of IPNS makes it impossible to prove that you've got the latest version of a name's value, and makes it relatively easy to attack. I don't know if Dat has the same issue, I haven't looked at it.
      - lgierth 9y ago
        It's not impossible by design, it's simply a feature that hasn't been implemented so far. IPFS is by design pluggable on all layers and thus theoretically capable of a ton of stuff.
        vertex-four 9y ago
        So IPFS is, according to you, not defined as its protocol, but instead as its API? So I could build an IPFS implementation that just grabs stuff from my (centralised) web server and say I'm using IPFS? Either nonsense, or useless - the goal here, I thought, was to build a global decentralised filesystem that looks the same from everyone's perspective. All DHTs suffer from this issue. It's just particularly likely that IPNS's use of a DHT will lead to attacks. Making it not susceptible to this would require a redesign of IPNS's protocol.
pfraze 9y ago
They're pretty similar. Beaker supported both once, which may be what you're thinking of. This is what guided our decision: https://beakerbrowser.com/docs/inside-beaker/other-technologies.html#why-dat-instead-of-ipfs https://beakerbrowser.com/docs/inside-beaker/other-technolog... The two features I list above, the append-only histories and secret-sharing, are unique to Dat. And, for us, the URL spec was a big deal.
- lgierth 9y ago
  Actually there's been some movement regarding URLs :) You can check out the reasoning and plan here: [1] IPFS still has the long-term goal of path addressing (NURI), we just hadn't yet completely figured out what the upgrade path should look like. The discussion linked above is turning into a spec and into actions, i.e. IPFS will be trying to get as much as possible of Electron's protocol API [2] into WebExtensions, [3] and make us of that in the browser addons. [4] [1] https://github.com/ipfs/specs/pull/152#issuecomment-284628862 https://github.com/ipfs/specs/pull/152#issuecomment-28462886... [2] https://electron.atom.io/docs/api/protocol/ https://electron.atom.io/docs/api/protocol/ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1271553 https://bugzilla.mozilla.org/show_bug.cgi?id=1271553 [4] https://github.com/ipfs/in-web-browsers https://github.com/ipfs/in-web-browsers
  - pfraze 9y ago
    So from what I can tell, the reason y'all keep pushing for NURIs has to do with the focus on hash-addressing, right? You're trying to get away from the concept of domains, which does make sense: a content-addressed folder or blob can live independently of a domain, because it's immutable and self-verifying, so why have domains at all. Here's why I think you're shooting yourself in the foot with the NURIs, though. 1) You're focusing on syntax. The "there is no domain" premise works just as fine with your stage two of `ipfs://{hash}`, so dismantling domains doesnt really justify the NURI change. The path syntax, of `/ipfs/{hash}`, contains functionally the same information. 2) If you still need IPNS, then you still need a concept of domains, so the "there is no domain" premise isn't really accurate. There's the concept of nestability in NURIs that is supposed to increase protocol composition, but I think you're overgeneralizing, at the cost of breaking backwards compatibility. When we looked at using IPFS in Beaker, the NURI was a major problem for us, because we're limited to what Electron/Chrome provides. It's not just API surface either: there's a lot of code in Chromium that makes assumptions around the standard URL syntax. Are you really so sure that nestable references are worth the headache? Because you're gambling the entire IPFS project on it.

Contrary to IPFS dat is more focused on what can be achieved right now while sacrificing true decentralisation, and is more opinonated with providing in its use case with providing things like versioning.

tbv 9y ago
What do you think it sacrifices? IPFS is more focused on static blob addressing while Dat focuses on data sources, and in that sense, there’s a single authority over a dataset. But I see that as a positive, since mutability is pretty valuable. TBH, I'm not sure how a site can work without mutability.
- GhotiFish 9y ago
  a dynamic site can't work without mutability, ipfs can't deal with mutability, so ipfs comes with ipns, which allows you to statically reference content that might change.
  - tbv 9y ago
    Yeah, IPFS + IPNS is effectively on par with Dat archive mutability, but mutability being built-in to Dat + its verifiable history log is particularly well-suited to building peer-to-peer websites
  - vertex-four 9y ago
    Of course, the design of IPNS makes it impossible to prove that you've got the latest version of a name's value, and makes it relatively easy to attack. I don't know if Dat has the same issue, I haven't looked at it.
    - lgierth 9y ago
      It's not impossible by design, it's simply a feature that hasn't been implemented so far. IPFS is by design pluggable on all layers and thus theoretically capable of a ton of stuff.
      - vertex-four 9y ago
        So IPFS is, according to you, not defined as its protocol, but instead as its API? So I could build an IPFS implementation that just grabs stuff from my (centralised) web server and say I'm using IPFS? Either nonsense, or useless - the goal here, I thought, was to build a global decentralised filesystem that looks the same from everyone's perspective. All DHTs suffer from this issue. It's just particularly likely that IPNS's use of a DHT will lead to attacks. Making it not susceptible to this would require a redesign of IPNS's protocol.

pfraze 9y ago

They're pretty similar. Beaker supported both once, which may be what you're thinking of. This is what guided our decision: https://beakerbrowser.com/docs/inside-beaker/other-technologies.html#why-dat-instead-of-ipfs https://beakerbrowser.com/docs/inside-beaker/other-technolog... The two features I list above, the append-only histories and secret-sharing, are unique to Dat. And, for us, the URL spec was a big deal.

lgierth 9y ago
Actually there's been some movement regarding URLs :) You can check out the reasoning and plan here: [1] IPFS still has the long-term goal of path addressing (NURI), we just hadn't yet completely figured out what the upgrade path should look like. The discussion linked above is turning into a spec and into actions, i.e. IPFS will be trying to get as much as possible of Electron's protocol API [2] into WebExtensions, [3] and make us of that in the browser addons. [4] [1] https://github.com/ipfs/specs/pull/152#issuecomment-284628862 https://github.com/ipfs/specs/pull/152#issuecomment-28462886... [2] https://electron.atom.io/docs/api/protocol/ https://electron.atom.io/docs/api/protocol/ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1271553 https://bugzilla.mozilla.org/show_bug.cgi?id=1271553 [4] https://github.com/ipfs/in-web-browsers https://github.com/ipfs/in-web-browsers
- pfraze 9y ago
  So from what I can tell, the reason y'all keep pushing for NURIs has to do with the focus on hash-addressing, right? You're trying to get away from the concept of domains, which does make sense: a content-addressed folder or blob can live independently of a domain, because it's immutable and self-verifying, so why have domains at all. Here's why I think you're shooting yourself in the foot with the NURIs, though. 1) You're focusing on syntax. The "there is no domain" premise works just as fine with your stage two of `ipfs://{hash}`, so dismantling domains doesnt really justify the NURI change. The path syntax, of `/ipfs/{hash}`, contains functionally the same information. 2) If you still need IPNS, then you still need a concept of domains, so the "there is no domain" premise isn't really accurate. There's the concept of nestability in NURIs that is supposed to increase protocol composition, but I think you're overgeneralizing, at the cost of breaking backwards compatibility. When we looked at using IPFS in Beaker, the NURI was a major problem for us, because we're limited to what Electron/Chrome provides. It's not just API surface either: there's a lot of code in Chromium that makes assumptions around the standard URL syntax. Are you really so sure that nestable references are worth the headache? Because you're gambling the entire IPFS project on it.