You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 29, 2020. It is now read-only.
Hello everyone! Let's assume that future web browsers will support IPFS natively. I have a thought about the way the hash gets referenced. Somewhere I have read that the links will be defined as follows:
ipfs://ipfs/QmXf8
Now that's a lot of redundancy, isn't it? And why is everybody sticking to //? The RFC speaks of [scheme]:[scheme-specific part] only. I propose following simple way:
ipfs:QmXf8...
ipfs:QmXf8.../about
ipns:QmZ7w...
Advantages: Humans like simplifications. Is it http://www.example.com./ or example.com on advertisements? Let's make it de-jure before it becomes de-facto.
Disadvantages: ipfs:// is recognized by people as "Link"/"Internet". → The whole discussion is futile if humans won't get in touch with hashes anyway since we will have to abstract that away.
Advantage: When we have a simple naming system, e.g. "andrew" => "Qm7Ei9...", "ipfs:andrew" or "ipns:andrew" is still much better than "ipfs://ipfs/andrew".
(We won't have it anyway: who's the registrar? A CENTRAL one? Never ever ^^ First come, first served? → What if the user loses his private key?)
Advantage: the broad public can learn: ".com" means that you have to open the browser, bw-pixels means that you have to open "QR-Code-Scanner", "#" means that you have to open a special service in order to read the #hashtag, "ipns:" means you have to open the browser. Simple, isn't it?
What do you think?
The text was updated successfully, but these errors were encountered:
Hello everyone! Let's assume that future web browsers will support IPFS natively. I have a thought about the way the hash gets referenced. Somewhere I have read that the links will be defined as follows:
ipfs://ipfs/QmXf8
Now that's a lot of redundancy, isn't it? And why is everybody sticking to //? The RFC speaks of [scheme]:[scheme-specific part] only. I propose following simple way:
ipfs:QmXf8...
ipfs:QmXf8.../about
ipns:QmZ7w...
Advantages: Humans like simplifications. Is it http://www.example.com./ or example.com on advertisements? Let's make it de-jure before it becomes de-facto.
Disadvantages: ipfs:// is recognized by people as "Link"/"Internet". → The whole discussion is futile if humans won't get in touch with hashes anyway since we will have to abstract that away.
Advantage: When we have a simple naming system, e.g. "andrew" => "Qm7Ei9...", "ipfs:andrew" or "ipns:andrew" is still much better than "ipfs://ipfs/andrew".
(We won't have it anyway: who's the registrar? A CENTRAL one? Never ever ^^ First come, first served? → What if the user loses his private key?)
Advantage: the broad public can learn: ".com" means that you have to open the browser, bw-pixels means that you have to open "QR-Code-Scanner", "#" means that you have to open a special service in order to read the #hashtag, "ipns:" means you have to open the browser. Simple, isn't it?
What do you think?
The text was updated successfully, but these errors were encountered: