4 ms·

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 (

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.
- hobofan 9y ago
  > Because you're gambling the entire IPFS project on it. One of the reasons I like the IPFS project so much is that they produce a lot of good side products (multiformats, libp2p) that can help anyone build an IPFS-like system. So I wouldn't see it that bleak. Even if that choice of NURIs is a fatal flaw as you claim, it is still a very surface-level problem that could be fixed in a fork of it.

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.

hobofan 9y ago
> Because you're gambling the entire IPFS project on it. One of the reasons I like the IPFS project so much is that they produce a lot of good side products (multiformats, libp2p) that can help anyone build an IPFS-like system. So I wouldn't see it that bleak. Even if that choice of NURIs is a fatal flaw as you claim, it is still a very surface-level problem that could be fixed in a fork of it.