human-friendly IPNS and private files using blockchain

[kashishkhullar]

Proposal for improved IPNS

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:

1. A user first enters a link like ipfs://my-fav-file.txt
2. 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.
3. The smart contract contains a mapping that maps file name hashes to their content hashes which gets returned as a response to the browser.
4. 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:

1. Interecpt the links
2. check its protocol
3. make a call to smart contract
4. 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:

1. Instead of the initial “ipfs://” protocol we can call it “ipfsp://” ( ipfs private ) to tell the browser to request private files.
2. The browser will request a smart contract with the hash of the file name.
3. The smart contract contains another mapping specifically for holding private hashes.
4. 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.
5. 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.

[Stebalien]

I'm hoping we can use ENS (ethereum) for this, actually. We won't even need to modify IPNS. Instead, you'd visit ens://my-name/..., the ENS browser extension would resolve my-name to some /ipns/... path and hand it off to IPFS. IPFS would then resolve /ipns/... to /ipfs/... and return the appropriate file.

The tricky part here is validating responses from the smart contract without having to run a full Ethereum node.

[kashishkhullar]

This proposal is inspired from ENS but certainly we cannot use ENS for this purpose. ENS names are auction based and we cannot modify the existing ENS system to support file names. But a few concepts can be used from ENS such as giving up the domain name.

Indeed, network packets can be intercepted and the attacker could change the file content hash. Encryption could be used here to prevent packet spoofing and instead of a full node we use infura.

[Stebalien]

ENS names are auction based

This is to prevent spam. Otherwise, the registry would fill up with spam names and it would be impossible for legitimate users to register new names.

Indeed, network packets can be intercepted and the attacker could change the file content hash. Encryption could be used here to prevent packet spoofing and instead of a full node we use infura.

I'm worried about validating the chain, not MITM attacks. Relying on something like infura would technically work but it just shifts the trust to a third-party service. This is definitely doable, just tricky.

[kashishkhullar]

The names and their corresponding hashes would be stored in the smart contract, any changes in the smart contract would need a transaction to created and signed by the user. The ethereum network will then validate the transaction and add it to the chain. Network may use it own consensus protocol.

[lidel]

Just found this. FYI I proposed adding /ens backed by EthDNS resolver in ipfs/kubo#6448 (review) (one could run one in LAN or localhost)

[aschmahmann]

Brief comment here is that naming across "insert system here" is covered by the DID Spec that is already gaining traction and has a number of implementations being developed.

Any DID method could be used as a naming system since that's fundamentally what they do. May DIDs are blockchain based, some have human readable names, others (like IPID which is based on IPNS) are neither.

It'd be interesting if there were straightforward ways someone with a particular name resolution scheme in mind (like the OPs scheme, ENS, or any DID method) could write a plugin to IPFS and IPFS companion (for browser extensions) for their scheme's resolution.