[unixbane]

The proper way to connect to a service on the internet after the 70s when crypto was invented, is to connect by public key or hash thereof. Instead of a bloated insecure HTTPS stack, your code just connects and checks against the public key which was used as the address (actual implementation details like finding the IP address or routing over an overlay network is done automatically with something like a DHT).

The second piece to this is how the GUI works. Instead of showing long bit strings or hex encoding them in some pointless way, it allows you to assign names to these addresses as you come across them. When you see the address in some other page it will show up with the name you assigned and so you will recognize it.

A key point to this is that HTTPS does not actually cause you to know you are using the right domain name. Aside from the fact that HTTPS is untrustworthy due to the CA model, mybrand.com or mybrand.net or one of the other infinite number of legitimate sounding things could all be the correct domain for some brand, you would never know unless someone previously introduced you to the right domain name. Since you had to get it from somewhere, you may as well have received the public key at that point, which could be encoded in a QR code, or, on the internet, which is the main use case of petnames, trivially included as a link in some web 8.0[1] page or chat where you first heard of the brand.

1. I guess it will take them 6 more tries to get this right.

[ianopolous]

Strong agree. There is a massively undersold feature of IPFS, p2p streams, which do exactly this. We use it extensively in Peergos to sent http requests to a public key. It has stunning UX as well, not having to worry about changing IP addresses etc. This makes it easy to have zero dependency on DNS or the TLS certificate authorities.