– SEE BELOW, this suggestion is RETRACTED –
Hi,
It looks like i’m not the first one with this idea.
Others came before me:
and
Yet i still persist in posting my idea as i think i found a way that is not very intrusive and conceptually easy to grasp.
But first: Why?
Since IPFS 0.5.0 the IPNS world definitely improved a lot!
It feels much faster! And if one were to enable the pubsub addition it is nearly instantaneous for updates.
Still, it has it’s issues. If you for example just develop a site and play with it a bit (your own personal playground) then you very likely have no other people visiting your site. Thus no other nodes to keep your IPNS → IPFS mapping alive. Thus you are still the only one serving that mapping. In my personal case, i do have my files hosted on pinata and on a private (but always online) node. Yet the ipfs name publish
command is done by me on my local node which is not online much of the time. Thus i end up with the situation that my data is perfectly accessible in IPFS but times out with IPNS as there is no node online that knows the IPNS hash.
This RFC aims to provide a solution to fix this situation once and for all.
What we need is a persistent database that can either tell us the IPNS → IPFS mapping or that can just tell us the IPFS hash directly and skip IPNS alltogether.
In this solution IPNS is completely discarded yet it’s functionality is preserved but through blockchain technology and DNSLink combined. Note that this functionality is the part where you could call: <gateway>ipns/some.site.com
How?
We need a ledger to record where some.site.com
would map to in terms of the IPFS hash. In theory, every blockchain that allows to set some arbitrary values could be used to store an IPFS hash. DNSLink is where the magic happens.
Say you have a wallet specifically for some.site.com
you’d then use dnslink as follows:
dnslink=/<blockchain>/<wallet_address>
And modify DNSLink to understand that logic and return the appropiate IPFS hash.
But not all blockchains are the same. Some allow adding a little bit of arbitrary data, those can potentially be used. Yet most blockchains don’t allow you to get a list of transaction. And even if they do, a regular wallet of say bitcoin isn’t suitable for this task as anyone can send you anything. Including a new IPFS hash for your super important site. Making that secure would be quite tricky.
What we really need is a decentralized key-value store where only “the owner” of that “wallet” can write or where there is some mechanism of access control to know that an owner made a transaction that can change an IPFS address.
For these requirements, there are a few possible candidates.
- Namecoin
- Bluzelle
- Kevacoin
Namecoin
While super interesting, they might provide way too much. It would be very interesting to mix and match IPFS with namecoin (with also it’s decentralized DNS) to create a truly unbreakable internet. It’s way outside the scope of the problem i’m trying to solve though. For that reason, i’m not going to consider this one for this particular problem.
Bluzelle and Kevacoin
Both would be perfect candidates! Both allow key-value storage and both allow easy retrieval of that data. Right now i’m merely going to focus on Kevacoin for no particular reason other then “i need to pick one”
DNSLink with Kevacoin
Kevacoin (where keva stands for key-value) has an interesting concept for making key-value entries. You basically have a wallet and within that wallet can create a namespace (generated, you can’t pick a name). Within each namespace you can then set a key and value. You can update it or even delete it. It’s all recorded on their blockchain. The immutable part is the namespace which remains as-is with each change to the content within that namespace. Thus here, in effect, you have a mapping from Kevacoin namespace
to IPFS hash
. An example of such a data blob looks like this (for reference, see Open source key-value database on blockchain, the keva_filter
is where this example comes from):
{
"name": "key",
"value": "value",
"txid": "<transaction hash>",
"vout": 0,
"address": "address",
"height": 650
}
For DNSLink i’d like to propose to use a structure like:
dnslink=/kevacoin/NfjHmcWxHndbfMRG7FeXWtmBEaRp896wBC
where NfjHmcWxHndbfMRG7FeXWtmBEaRp896wBC
is the namespace in which a key-value is stored.
I’d then put ipfs
as key and the actual hash as value
In terms of kevacoin API, that would be a call like this to store it:
kevacoin-cli keva_put NfjHmcWxHndbfMRG7FeXWtmBEaRp896wBC "ipfs" "bafybeiayvrj27f65vbecspbnuavehcb3znvnt2strop2rfbczupudoizya"
Note that these actions that put something on the blockchain are not immediate (they could take a couple minutes) and they cost money. In terms of money we’re talking about a fraction of a cent, so that can’t possible be an issue. In terms of time we’re talking about ~4 minutes before it has been verified by a few nodes. So changes definitely aren’t immediate. Personally i think you could compare it to changing the DNS settings on your site. It could take a few minutes up till 2 whole days, so kevacoin then is still super fast with 4 minutes.
To retrieve the value, you’d execute the following:
kevacoin-cli keva_get NfjHmcWxHndbfMRG7FeXWtmBEaRp896wBC "ipfs"
Which would then return: bafybeiayvrj27f65vbecspbnuavehcb3znvnt2strop2rfbczupudoizya
. Which would then be handed back to IPFS as: /ipfs/bafybeiayvrj27f65vbecspbnuavehcb3znvnt2strop2rfbczupudoizya
To implement all of the above, not a terrible lot is needed.
- DNSLink needs to be made smarter to understand this logic. This seems to be a rather simple code adjustment.
- The node that will execute this kevacoin based lookup does need the kevacoin client/wallet installed (and running). That adds ~20GB for the user or the server instance that’s running it.
- Point 2 is also true for gateways.
- It might be best to make this optional but then DNSLink needs to somehow check that kevacoin is there and not try to use it when it’s not there.
Last but not least, improve IPNS with this blockchain
Combining DNSLink with this blockchain is only one possible improvement.
You could, using the multi formats protocol extent IPNS functionality to be using the blockchain for every single ipfs name publish <hash>
command. It should definitely be opt-in! But if someone runs a local kevacoin client already then hooking into it is easy and beneficial for the IPNS user experience. You could even use the public kevacoin explorer to get the data in case the client API isn’t available. The downside here it using a centralized point of entry… Still, it would make it possible to always use this blockchain for retrieval when a multi formats protocol is used that indicates kevacoin should be used to determine the IPFS hash.
To amend the above last part. I meant to “also” use kevacoin to do the looksup from IPNS
to IPFS
. he current systems (with and without pubsub) with IPNS should remain as is. It’d just be another source to get the mappings from.
I’m really curious to know your (IPFS community) thoughts about this!
Cheers,
Mark
RETRACTED (17-08-2020)
I retract this RFC.
The suggested way of implementing this seems to be super persistent on going the custom DNS route. I don’t want to do that nor was that my intention. I won’t be doing this. I’m leaving all the above content for reference in case someone else likes the idea and wants to proceed here.