[RETRACTED][RFC] Use DNSLink and a blockchain for a "mutable persistent IPFS"

– 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” :slight_smile:

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 https://kevacoin.org/documentation.html, 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.

  1. DNSLink needs to be made smarter to understand this logic. This seems to be a rather simple code adjustment.
  2. 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.
  3. Point 2 is also true for gateways.
  4. 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.

@markg85 just a heads up that you can basically do this without any changes to go-ipfs at all.

For example, ENS accomplishes a similar goal and is usable within go-ipfs and the only “custom” thing that was added was a convenience mapping of .eth -> .eth.link. As long as there exists somewhere (e.g. on your local machine, or on the public internet) some DNS resolver that takes .kevacoin domains and resolves them via blockchain you can just present DNSLink records and everything just works. (e.g. /ipns/IANA-DNSLink.tld -> /ipns/mywallet.kevacoin -> /ipfs/bafy…).

As a general note on this idea, the other projects I’m aware of that are using blockchains for mutable links have coupled them with a unique and human-readable/choosable naming system (e.g. ENS, Unstoppable Domains, etc.) since if you’re stuck using some consensus based system (as opposed to IPNS which is not consensus based) then you might as well get unique and choosable names out of it (e.g. myname.eth or myname.crypto). It seems like this proposal uses a blockchain, but doesn’t get as much out of it as it could.

In case it’s interesting, there’s some info in this discussion talking more about the tradeoffs between unique names, choosable names, and non-consensus names. Zooko's triangle, why not use the DHT?

We might have a small misunderstanding here.
There is no such thing as “a kevacoin domain”.
Kevacoin is a distributed key-value database, not a domain provider or with functionality that makes it comparable to it. Ens is totally different!

This too must be a misunderstanding. Sorry if i explained poorly!

And this too, in fact your whole post, really is just irrelevant. Please do explain what i said that made you apparently think i was going for human readable names? It’s just not the case. I’m going for the IPNS concept but without IPNS. IPNS, as you know, is not about human readable names. It makes it possible, yes. But it’s not on it’s own.

The idea is not to make readable domains/names. That’s a whole different subject and just not the goal of this post.

The idea is to have DNSLink gain the knowledge to handle dnslink=/kevacoin/NfjHmcWxHndbfMRG7FeXWtmBEaRp896wBC
Internally, DNSLink recognizes (by “/kevacoin/”) that it’s a kevacoin namespace and then uses kevacoin to get the json data that is in the “NhsT6RyfijD5uoPhwHQbvDz2tbwSSfRoRd” namespace.

So it executes: kevacoin-cli keva_get NhsT6RyfijD5uoPhwHQbvDz2tbwSSfRoRd "ipfs"

That data behind “NhsT6RyfijD5uoPhwHQbvDz2tbwSSfRoRd” is:

  {
    "key": "ipfs",
    "value": "QmaCaMZxp824Sm5MU8vi1N6D6nwRcFExjVA9davUvW7Dg3",
    "txid": "dfec3b01b1692f1f36144eb50d2c5e1da4aa1d90924261cc23d6dd2ef71f7880",
    "vout": 0,
    "height": 142209
  }

and from that the value where the key equals “ipfs” is then returned.
So QmaCaMZxp824Sm5MU8vi1N6D6nwRcFExjVA9davUvW7Dg3 is returned.

That is then returned to IPFS to handle that hash and present it back to the user.
So it has nothing to do with making it human readable. It has everything to do with making “hash link” to IPFS data where that hash link (the NhsT6RyfijD5uoPhwHQbvDz2tbwSSfRoRd) remains the same when the underlying IPFS hash in that json blob changes. Thus in effect a IPNS concept, just without IPNS.

Why not? If the user has to have a kevacoin client installed anyway then why not make a local DNS resolver that happens to resolves *.kevacoin on the client’s machine. Fulfilling this local API of returning DNS TXT records will make this work with DNSLink without any further modifications. I’m not saying you have to run some publicly accessible DNS resolver for Kevacoin (although you could), just that having a local resolver would make implementing this very straightforward.

Nothing. The point I was trying to make is that in designing a naming systems you get to choose 2/3 of unique, choosable, non-consensus. Your system gets 1/3 (unique names) unlike the 2/3 that IPNS (unique + non-consensus) or ENS (unique + choosable) do. There’s nothing inherently wrong with only using 1/3, but there’s some wasted potential.

The date should be 17-08, we are only in august!

changed (adding this just because a post must be 20 characters…)