IPFS does not support true human-friendly domain names as we currently use such as www.github.com. IPNS implementation has come close to such domain names but yet I cannot just open my browser and type the link with a hash or a long string of names. I would like to propose a solution that might help in solving this problem and create truly human-friendly names with the help of smart contracts in the blockchain.
Motivation
Blockchain has been used in this proposal since it is decentralized and has no downtime.
Working of IPNS using blockchain:
Following presents the working of this proposal:
A user first enters a link like ipfs://my-fav-file.txt
The browser reads “ipfs://” initial protocol and sends the request to a smart contract with the hash of the file name present in the link as a parameter.
The smart contract contains a mapping that maps file name hashes to their content hashes which gets returned as a response to the browser.
The browser receives the response and redirects the user to the required file using the received hash.
Browser extension
If it is required, this functionality can be added to existing browsers by creating an extension. The extension will:
Interecpt the links
check its protocol
make a call to smart contract
redirect users
Private files on IPNS
A file is private as long as we don’t know the content address and if it is encrypted. To prevent users from accessing the content address of the private file following can be implemented:
working Private files on IPNS:
Instead of the initial “ipfs://” protocol we can call it “ipfsp://” ( ipfs private ) to tell the browser to request private files.
The browser will request a smart contract with the hash of the file name.
The smart contract contains another mapping specifically for holding private hashes.
For a file-name hash, this mapping will return a digital signature which actually is the content hash encrypted using the public key of the creator.
The browser will receive the digital signature, the user will then decrypt it with his/her private key, hence providing us the content address of the file which we can now access.
Mutable addressing
Change in the content of the file changes the link to the file. Using the above-described method, one can update the mapping in the smart contract by providing legitimate proof of ownership and update the new link for the given file name. Since a name will map to a single link, multiple names can be given to a different version of the same file which will be recorded in the smart contract separat HEnceely.
Conclusion
The current system is not yet developed/tested and is a concept. If created, our output would be a human-friendly naming system in which we access files on ipfs via their name. eg: ipfs://my-cat-video.mp4, ipfs://my-cat-video-v2.mp4, ipfs://my-cat-video-v3.mp4 etc.
How is this an improvement over IPNS with DNS? For example (using dnslink), /ipns/blog.ipfs.io/61-ipfs-weekly-23/.
Which blockchain?
How would human-friendly file names be allocated? Is it on a first-come-first-serve basis? With everything in the same namespace, wouldn’t this result in people trying to come up with unique names to the point that the names are no longer human-friendly?
Also, why should these non-multihash human-friendly names be in the IPFS namespace rather than something new like hfns:// (for example, for human-friendly naming system)? Unless they’re put in another namespace, what’s to stop someone from creating a filename that is equivalent to a valid multihash that points to a totally different piece of content?
I’m not completely sure how DNSlink works but is it not centralised.
The one which offers maximum decentralisation and capability of smart contracts
Yes, you are right. People have to come up with unique names just like a normal domain name that we use. People come up unique domain names even if we have billions of website. Aren’t their name human friendly?
I didn’t know what multihash was, but using multihash doesn’t seems difficult. Either this would replace the existing system or be a seperate one. This is just a proposal.
The same name cannot be saved in the hash table again. An if condition would work here.
Unless I misunderstand, your proposal makes this much more of a problem than with domain names since it’s addressing every single human friendly file name with its own contract. Current state is that someone chooses a unique domain name that makes sense, and within that domain they can choose almost whatever name they want for their files (example.com/whitepaper.pdf) regardless of whether someone else has a file with the same name at their domain (exampletwo.com/whitepaper.pdf).
The aim of the proposal is just to map human-friendly names to file content hashes. And this mapping is stored in a specific smart contract that is deployed on a blockchain. So that people can easily manage their file names instead of file hashes.
But can we read them? We can’t remember hashes nor manage them without storing them in a data file.
It’s not that complicated to have unique filenames.
myfilename.txt could a name representing a hash. If somebody else wants to have the same name, they can just add some uniqueness
for example: myfilename.txt_
Emails are obviously unique.
This is sort of a tangential discussion to your original post, but I’d argue that human-readable names are overrated.
Take for example the image with the URL below, which has been viewed at least 38 thousand times in roughly a 4 hour period (so far) despite not having a human-friendly name.
https://i.redd.it/3eykbytuil621.jpg
The reason why is that it was linked to from somewhere else: here. Most users are not typing in URLs or filenames manually. They’re clicking on links, where it doesn’t matter whether the filename is one human-friendly word or a machine-generated hash.
My argument is not for clicking of links but to allow users to type in the name and access the files.
Most users don’t type in URL in their because we have google search working for us, we just type the name and we get a link to click on and what if we know the name but not have a link to it.
And also links should also be on a website, does that not involve typing the url and visiting the website.
It does, but I don’t see how your proposal would handle websites unless existing smart contracts can be updated to point to a new multihash. For instance, if I create a smart contract for myspace.com (since I don’t see any restrictions on what I’m allowed to create), I don’t want to have to create a new website name every time I update it.
How so? Currently there is no blockchain dependency for IPFS but this proposal would add one in addition to ambiguity as to what is referred to in an IPFS path.
Your original post refers to using ipfs:// or /ipfs/, but I think you might have meant ipns:// or /ipns/. /ipfs/ paths are immutable whereas /ipns/ paths are not. For this reason, I’m not sure which one you meant in the original post.
It creates ambiguity for /ipfs/ or /ipns/ (depending on what you meant in your first post) paths by allowing both multihashes and “human-friendly” filenames (for example, /ipfs/my-file-v32-randomStringToMakeThisUnique.pdf would be valid under your proposal)
A dependency on an unspecified blockchain would now be required for all /ipfs/ or /ipns/ path resolutions
There’s no authentication mechanism for what filenames get entered into a smart contract, so unsuspecting users might be tricked into trusting something like /ipns/google.com/givemeyourlogins.html
I don’t think that this proposal has anything to do with the no of times the link will be shared. A link will be shared a irrespective of the fact if it is readable or not.
You won’t create a seperate smart contract for every file. You save the file name hash in an existing smart contract. Hence we can update the new modified content hash which will be present in the smart contract.
It won’t be a dependency but would a seperate layer to resolve file name to its content hash. So things would work even if user choose to use ipfs without this system.
Yes there might be errors (using word ipfs or IPNS) in the proposal and it’s a draft so pardon me.
Multihashes and friendly names can be differentiated by a simple of condition. (Split the link, check if it has “Qm” then hash otherwise it’s a file name).
Well then ethereum it is. And no not all paths, if it’s a file content hash then there is no requirement to call the smart contract.
If phishing is your concern then it exists in centralised system as well. But I can read the link and understand that it is asking for logins, it it were just a hash then I wouldn’t recognise it and simply provide my login to the bad guys.
Perhaps by using an advanced datastructure and not a simple dictionary we can reserve a some names.
Example:
Reserve google.com so that links such as google.com/login , cannot be used by people other than the owner of google.com domain name.