4 ms·

I should have added "human readable short persistent url". Like foo.com/xy/github where xy is an identifier as short as possible to avoid collision. And with i

by kuon 8y ago

I should have added "human readable short persistent url". Like foo.com/xy/github where xy is an identifier as short as possible to avoid collision. And with ipfs you are dependent on the ipfs own domain. To remove domain dependency it would have to be something not based on current DNS system.

diggan 8y ago
> And with ipfs you are dependent on the ipfs own domain No, you might have gotten something wrong here. We (I work at Protocol Labs, I'm part of the development team working on IPFS) are hosting a public gateway you _can_ use but in no way have to use. You can either use your own local gateway, another gateway via IP or accessing the other peers gateways if that's accessible. Nothing is tied to the "ipfs.io" domain.
- kuon 8y ago
  Yes I understand how ipfs works. But I mean, now we don't have the ability to print an URL that is not dependent on a domain name ipfs or any other. That's why DNS would require an alternative for true persistent and decentralized identifiers that are human readable.
  - wolfgang42 8y ago
    Well, of course you can't have a URL without a domain name; part of the spec for URLs is that they have a host part! But, IPFS does not depend on the domain name system to keep your data accessible. You can install IPFS Companion to remove the dependency on the DNS system and ipfs.io gateway, replacing it with your own local gateway (so even if the IPFS Foundation goes away they will still work for anyone who has this set up). Or, you can look at the URL to find the hash and perform the lookup manually. There are also some discussions about making a new URI scheme, though I don't believe they've settled on anything yet. As I've said in my other comment, I don't think that decentralized and human-readable are mutually compatible; if there is no central authority then how can it be decided when two people want the same name? If by first-come-first-serve, what prevents someone from squatting on all the good names? Namecoin for example solves this by requiring periodic renewal, but then you have the same problem that DNS has of link rot as names expire.
    - kuon 8y ago
      Yeah, having an IPFS like system handled at the browser level (in the address bar) would solve the name resolving bit without DNS. We could imagine something like this, the full URL is: QmaG4FuMqEBnQNn3C8XJ5bpW8kLs7zq2ZXgHptJHbKDDVx/github/example.jpg but could be written like so Qx/github/example.jpg And if there are duplicates, all duplicates are displayed in a list, with metadata (like creator, ssl info to help verify the creator...) and you select the one you want.
wolfgang42 8y ago
I'm not sure how well "short" and "decentralized" go together. The problem is that there's no good way to prevent someone from creating as many short identifiers as possible and taking them up forever. Distributed, maybe, if you have a central issuing authority who publishes a complete list that others can mirror and archive. I think this is what a DOI is supposed to be. IPFS.io itself is an IPFS gateway, but you can resolve /ipfs/ paths without it if you run your own IPFS daemon; in fact this seems to be the end goal of the IPFS foundation, with ipfs.io being an stopgap measure since most people aren't running an IPFS daemon yet. The easiest way is to get this is to install the IPFS Companion browser plugin, which takes over resolution of ipfs.io and replaces it with a local gateway on your computer.

by kuon 8y ago

diggan 8y ago

> And with ipfs you are dependent on the ipfs own domain No, you might have gotten something wrong here. We (I work at Protocol Labs, I'm part of the development team working on IPFS) are hosting a public gateway you _can_ use but in no way have to use. You can either use your own local gateway, another gateway via IP or accessing the other peers gateways if that's accessible. Nothing is tied to the "ipfs.io" domain.

kuon 8y ago
Yes I understand how ipfs works. But I mean, now we don't have the ability to print an URL that is not dependent on a domain name ipfs or any other. That's why DNS would require an alternative for true persistent and decentralized identifiers that are human readable.
- wolfgang42 8y ago
  Well, of course you can't have a URL without a domain name; part of the spec for URLs is that they have a host part! But, IPFS does not depend on the domain name system to keep your data accessible. You can install IPFS Companion to remove the dependency on the DNS system and ipfs.io gateway, replacing it with your own local gateway (so even if the IPFS Foundation goes away they will still work for anyone who has this set up). Or, you can look at the URL to find the hash and perform the lookup manually. There are also some discussions about making a new URI scheme, though I don't believe they've settled on anything yet. As I've said in my other comment, I don't think that decentralized and human-readable are mutually compatible; if there is no central authority then how can it be decided when two people want the same name? If by first-come-first-serve, what prevents someone from squatting on all the good names? Namecoin for example solves this by requiring periodic renewal, but then you have the same problem that DNS has of link rot as names expire.
  - kuon 8y ago
    Yeah, having an IPFS like system handled at the browser level (in the address bar) would solve the name resolving bit without DNS. We could imagine something like this, the full URL is: QmaG4FuMqEBnQNn3C8XJ5bpW8kLs7zq2ZXgHptJHbKDDVx/github/example.jpg but could be written like so Qx/github/example.jpg And if there are duplicates, all duplicates are displayed in a list, with metadata (like creator, ssl info to help verify the creator...) and you select the one you want.

wolfgang42 8y ago

I'm not sure how well "short" and "decentralized" go together. The problem is that there's no good way to prevent someone from creating as many short identifiers as possible and taking them up forever. Distributed, maybe, if you have a central issuing authority who publishes a complete list that others can mirror and archive. I think this is what a DOI is supposed to be. IPFS.io itself is an IPFS gateway, but you can resolve /ipfs/ paths without it if you run your own IPFS daemon; in fact this seems to be the end goal of the IPFS foundation, with ipfs.io being an stopgap measure since most people aren't running an IPFS daemon yet. The easiest way is to get this is to install the IPFS Companion browser plugin, which takes over resolution of ipfs.io and replaces it with a local gateway on your computer.