Somehow, this is the first time I've heard of IPFS. Seems really awesome! From a total novice standpoint, can someone help me understand:
>With IPFS, every single block of data stored in the system is addressed by a cryptographic hash of its contents, i.e., a long string of letters and numbers that is unique to that block. When you want a piece of data in IPFS, you request it by its hash. So rather than asking the network “get me the content stored at 93.184.216.34,” you ask “get me the content that has a hash value of QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy.”
It seems like you must know the "URL" of the "website" you want to visit (files in IPFS) beforehand? But in the case of IPFS, there's no like, DNS service, so you can't type "www.google.com." Basically, it'd be like if to navigate the modern internet, you'd need to know the IP address of whatever site you visit? Is that true of IPFS? Is there any way around that?
It seems like a strong limitation, unless someone can make some sort of IPFS search engine that happens to hash out at QN000000000000000000000 or some really memorizable hash... which seems extremely unlikely!
IPFS has a name resolution protocol, called IPNS. Conceptually it works similar to DNS. More advanced discovery protocols are being worked. The thing with IPFS though is that, because the raw identifier (not address) is the hash of the content, multiple nodes can serve the same content.
A key idea to to focus on de-centralization, so for example when you want a particular piece of content you could send a query out asking your known nodes for content with that hash, they then ask others, etc., propagating the request like gossip. Caching can make this more efficient. IPNS allows you to register your node as a provider of named content that has a given name. The biggest benefits of this are (1) that you can update the content (giving it a new hash) and people can still find it by name, and (2) most mere mortals can't remember hashes but names are much easier to remember.
IPNS is a poor answer/solution to the original comment.
Don't get me wrong, I love IPFS (it is a perfect match with our tech) but IPNS is a nice sounding solution to the problem, but suffers terrible performance problems from the IPFS requirement of hashing.
Unfortunately, I know this for fact because multiple companies have already moved from IPNS to us to handle the indexing/updating of decentralized data in a mutable context BUT they still use IPFS for files/photos/etc.
So IPFS is great, but you are better off using another system for naming, indexing, searching, etc. and then point to the IPFS hashes. I'm biased (D.Tube - couple million+ monthly visitors, P2P reddit http://notabug.io - thousand daily actives, Internet Archive, etc.) are using GUN (https://github.com/amark/gun) for this instead.
IPFS is a collection of many different protocols put together. So regarding naming, the modularity of IPFS gives way for having multiple different naming-schemas pointing to the same content. And users can verify this, as it's all content-addressed.
So one way to archive human-readable names is having a DNS record pointing to a hash. So the user would still go to `example.com` but underneath, it would be served `/ipfs/QmaSD`. It could also use IPNS (currently build-in naming system for PeerIDs in IPFS) to point to the same content.
Once there are more (or better) naming systems, it'll be easy to add them to IPFS.
But currently, DNS is probably the most used together with IPNS, as most people are used to DNS and it generally works (but not offline, so far from perfect)
Edit: re your own example, with DNS + IPFS it would go something like this: you ask "What the content of the records of example.com?" DNS resolves answers: "This Gateway + This Hash" and you request the hash from that gateway.
I don't know how IPFS handles this currently, but TOR has the same problem (there addresses are basically a hash of the server certificate). The TOR community handles this by widely advertising the addresses of a few entry points. From there you use classic link traversal and bookmarks. In general, bookmarks become extremely important once you can't memorize addresses.
>With IPFS, every single block of data stored in the system is addressed by a cryptographic hash of its contents, i.e., a long string of letters and numbers that is unique to that block. When you want a piece of data in IPFS, you request it by its hash. So rather than asking the network “get me the content stored at 93.184.216.34,” you ask “get me the content that has a hash value of QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy.”
It seems like you must know the "URL" of the "website" you want to visit (files in IPFS) beforehand? But in the case of IPFS, there's no like, DNS service, so you can't type "www.google.com." Basically, it'd be like if to navigate the modern internet, you'd need to know the IP address of whatever site you visit? Is that true of IPFS? Is there any way around that?
It seems like a strong limitation, unless someone can make some sort of IPFS search engine that happens to hash out at QN000000000000000000000 or some really memorizable hash... which seems extremely unlikely!