I may be missing something, but name resolution has been touted as one of the more legitimate and sensible uses for blockchain for a very long time. Could you clarify what your issues with it in IPFS context are?
Someone is always going to want a short, unique, and memorable name. And when two people share the same name (McDonald, Nissan, etc) there needs to be a way to disambiguate them.
If people die and are unable to release a desirable name, that just makes the whole system less desirable.
I know one of the canonical hard problems in Computer Science is "naming things" and this is a prime example!
This is the core flaw of most of these systems: people hype them up selling the idea that it’ll become huge later, but without some link to real value or authority there’s no reason to favor one implementation over another or doing nothing at all.
This comes up a lot in the case of IPFS because the core problem is that most people won’t host anything on the internet. It’s expensive and legally risky, which forces you to vet who you host and then you have a less revolutionary pitch which has to be based on cost, performance, etc. and that’s a tough market.
Blockchain enthusiasts have a history of talking out of their ass and being susceptible to the lies of others.
But for any other usage, it cannot work, blockchain are useless. Someone or something somewhere has to make sure either that what's written on the blockchain corresponds to the real world, or to make the real worlds corresponds to what's written on the blockchain. Either way you need to have a kind of central authority, or at least trusted third parties. And that means you don't actually need a blockchain in the first place. We have better, more secured, more efficient, less costly alternatives to using a blockchain.
Back to name resolutions.
Virtually no one is going to actually host locally the blockchain where all names are stored. That would be way too big and could only get bigger and bigger, as a blockchain stores transactions (i.e., diffs) rather than current state. So in practice people and their devices would ask resolvers, just like they currently do with DNS. These resolvers would need to keep a database of the state of all names up-to-date because querying a blockchain is way too inefficient, running such a resolvers would be a lot more costly than running a DNS servers so there would be less of them. Here we just lost decentralization which was the point of the system. But that's just a technical problem. There is more: what if someone gets a name and we as a society (i.e., justice, whatever) decides that they should not be in control of it? Either we are able to enforce this decision and it means the system is not actually decentralized (so, we don't need a blockchain), or we can't, and that's a problem. What if a private key is lost, the associated names are gone forever? What if your private key is leaked by mistake and someone hostile take control of your name?
Using a blockchain for names resolution doesn't actually work, not for a human society.
You lost me here. Couldn't the local user ('s process) reference the same block chain instead of another trusted party?
This can be hundreds of gigabytes if not more at scale.
This is where the central authority comes in play, in the name of storage and performance efficiency.
Even crypto wallet apps use third party central servers to query your wallet totals. Because you aren't fitting the download of the block chain on your phone.
The value of the blockchain (in the context of name resolution) would (should) be limited to enabling trustless-ness of the response. I can cryptographically authenticate the origin of the response. If you don't trust that source, zk proofs would enable the user to validate the response is part of the latest version of the blockchain's state without looking at all of the history.
I think the cost of carrying the whole history is a red herring.
But then you have to trust the intermediaries. You can verify their claim, but doing so is so costly it's what made you turn to intermediaries in the first place.
> I can cryptographically authenticate the origin of the response.
A blockchain is not needed for that, certificates can do that.
> zk proofs (…) the latest version of the blockchain's state (…) cost of carrying the whole history
Knowing enough information about the latest version of a blockchain's state to validate responses would require either that you trust the third party which would provide the hash of the last block to you, or that you follow, blocks after blocks, what's added to to ledger, verifying each block's integrity and all. I'm not saying that's not doable, but that it either requires some boot-up time or to be online all the time; i.e., it more or less amounts to running a node which is what we seem to agree is not something most people / end devices will do.
You don't need to trust a third party and do not need to be online all the time for that.
Not everyone needs to run a node, and not everyone could, but it is totally feasible for an individual to run their own if they decide they can't trust anyone else for whatever reason. Especially if you were running a node specifically for the purpose of name resolution you could discard the vast, vast majority of data on the Ethereum blockchain (for example).
> what if someone gets a name and we as a society (i.e., justice, whatever) decides that they should not be in control of it? [...] and that's a problem.
No, that is a feature of a decentralized system. Individual node operators would be able to decide whether or not to serve particular records, but censorship resistance is one of the core features of blockchains in the first place.
> What if a private key is lost, the associated names are gone forever?
The association wouldn't be gone, it would just be unchangeable until it eventually expires. This is a known tradeoff if you are choosing ENS over traditional domain name registration.
> What if your private key is leaked by mistake and someone hostile take control of your name?
As opposed to today where someone hostile, like for instance the Afghani government (The Taliban), can seize your domain for any reason or no reason at all?
---
I think we just have a fundamental disagreement about what types of features and use cases a name resolution system should have. That's completely fine, you're entitled to your own believes. You can use the system that most closely resembles your beliefs, and I'll use the one that most closely resembles mine. Fortunately for us different name resolution system can peacefully coexist due to the nature of name mappings. At least for now, none that I know of collide in namespace.
Exactly, take a look at Sci Hub or The Pirate Bay continuously needing to change domain names due to seizures, for example. I'd want them to be able to actually own their domain names, either via blockchain or private key (e.g. Tor).
In fact Sci Hub tried HNS for some time but seems to have dropped out of it.
That's a feature.
Given typical abusive IP laws around the world, I'd say that it is.