I'll try to respond to this without writing a book ;-) It's hard because I think you are missing the point that the things you want are possible without the solution that is presented here. The other solutions are also simpler.
There are 2 scenarios. In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
For example, if I am a store, I want to make sure that my repeat customer is actually the repeat customer. If I am talking on HN, I want to make sure that the jude- that I am talking to today is the same jude- that I talked to yesterday. I really don't care who that person is. I may also care that jude- is the same jude- (or some other name) on another system. Or perhaps I want to be alerted when that person is confusingly different.
All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
The other scenario is when I want to contact a specific entity and I don't trust any intermediary to give me the correct information. DNS is perhaps a decent example. I want to contact a IBM's web server and I don't know where they are. I don't necessarily trust the providers.
Now, I think you will agree that in the general case this is impossible. The best I can do is go there once without trusting it and then build up a relationship with that entity to the point that I trust it is the real IBM.
Unfortunately, the current tools do not even allow us to do that easily. However, you could imagine a system where if IBM wanted to change their DNS, they would have to sign the change and if I was a repeat user of their site, I would have their public key to verify the change. This part of the scenario is just like the pseudonymous one.
There isn't much we can do to actually verify that the DNS entry for IBM actually leads to IBM if we don't trust the DNS system, but we can at least monitor if the DNS entry has changed. That way if millions of people are happy and not complaining, we have some confidence that it is the real IBM.
This public ledger is useful (as I pointed out in my edit) if a key gets revoked (so if you meet the imposter after the key has been revoked, you can discover it). It is similarly useful if something has changed before you had a chance to contact it and get it's public key (essentially same scenario as key revocation).
However, even this scenario has simpler implementations than the one suggested.
Finally, you suggest that having a globally unique name is useful because it could be meaningful. What shall we call the 3 teachers who work in the same school and live in the same town and have the same name? Shall we call them Tarou Sukuki 1, 2 and 3?
There is a reason why IPV6 is so huge. We need a lot of addresses. We will not be able to make them all meaningful. You need a map, but that map will necessarily have to be of the 1->N and context based.
> In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
> All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
Who signs and distributes the key, and why do you trust them to do so? This sounds a lot like the CA model, which I am trying to avoid using.
Even if you went without a CA and relied on TOFU semantics, using the blockchain to distribute your public key is still a better choice than sending it over the wire to each requester because (1) when creating my name/pubkey pair, I will notice very quickly if the (jude-, pubkey) record in the blockchain is wrong, and immediately claim a different username; (2) once (jude-, pubkey) is published in the blockchain, it is extremely hard to change, so our adversary can't send you a different public key if you're on the same blockchain as me; (3) it is extremely hard for an adversary to make a separate plausible blockchain with the wrong (jude-, pubkey) transaction, since that would require a tremendous amount of CPU time to calculate all the necessary partial double-SHA256 preimages in order to re-write the transaction history back to the block where I registered (jude-, pubkey).
> I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
I think this is a different problem than what I was trying to solve. It sounds like you want to have a high degree of confidence that the DNS name "ibm.com" points to web servers belonging to the actual IBM, and not a squatter or phisher. If so, then I agree that a blockchain will not help you there. The problem I've been trying to solve is using my out-of-band knowledge that "ibm.com" is the name for IBM's servers to obtain IBM's public key, without having to trust DNS, a CA, or some other centralized entity. I apologize that this was not clear earlier.
> Shall we call them Tarou Sukuki 1, 2 and 3?
Why not let them choose their own globally-unique names, and use a first-to-claim policy to resolve collisions?
There are 2 scenarios. In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
For example, if I am a store, I want to make sure that my repeat customer is actually the repeat customer. If I am talking on HN, I want to make sure that the jude- that I am talking to today is the same jude- that I talked to yesterday. I really don't care who that person is. I may also care that jude- is the same jude- (or some other name) on another system. Or perhaps I want to be alerted when that person is confusingly different.
All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
The other scenario is when I want to contact a specific entity and I don't trust any intermediary to give me the correct information. DNS is perhaps a decent example. I want to contact a IBM's web server and I don't know where they are. I don't necessarily trust the providers.
Now, I think you will agree that in the general case this is impossible. The best I can do is go there once without trusting it and then build up a relationship with that entity to the point that I trust it is the real IBM.
Unfortunately, the current tools do not even allow us to do that easily. However, you could imagine a system where if IBM wanted to change their DNS, they would have to sign the change and if I was a repeat user of their site, I would have their public key to verify the change. This part of the scenario is just like the pseudonymous one.
There isn't much we can do to actually verify that the DNS entry for IBM actually leads to IBM if we don't trust the DNS system, but we can at least monitor if the DNS entry has changed. That way if millions of people are happy and not complaining, we have some confidence that it is the real IBM.
This public ledger is useful (as I pointed out in my edit) if a key gets revoked (so if you meet the imposter after the key has been revoked, you can discover it). It is similarly useful if something has changed before you had a chance to contact it and get it's public key (essentially same scenario as key revocation).
However, even this scenario has simpler implementations than the one suggested.
Finally, you suggest that having a globally unique name is useful because it could be meaningful. What shall we call the 3 teachers who work in the same school and live in the same town and have the same name? Shall we call them Tarou Sukuki 1, 2 and 3?
There is a reason why IPV6 is so huge. We need a lot of addresses. We will not be able to make them all meaningful. You need a map, but that map will necessarily have to be of the 1->N and context based.