Den 4 apr. 2016 19:23 skrev "Sean Leonard" <<a href="mailto:dev%2Bietf@seantek.com">dev+ietf@seantek.com</a>>: > > I think it’s called a URI. > > Any “universal” address is going to have to have embedded info about the protocol or system that it is addressing. See URI. People see URL:s and think websites, they see email addresses and think people. OpenID essentially died. So did Mozilla's Personas. A bunch of RDF based protocols too. And many many more. They all shared the URI. It was *something extra* people has to remember and share besides their email. If we're going with an URI, what do we put in the protocol field? Do we go for a magnet link type address where you encode an URL in the URI if you're using a server, and otherwise specify a protocol and public key, etc? Next question, the more serious one; who'll even try to share that URI? Who's gonna read it over the phone? Exactly nobody. It will be forgotten. Or do we go with HTTP + special HTML tags on websites like OpenID did and go for standard URL:s? Besides the tendency of HTML tags to get broken in website redesigns, the total lack of an enforceable standard for how transparency logs could be implemented (how will you even know where these tags can be found on arbitary domains, since few will accept using your page naming conventions?), HTML parsers tend to have bugs. Also, that situation would also practically by default lead to developers forgetting about other lookup/connectivity protocols, like Namecoin and I2P, where their addresses won't even be recognized. That's why I stick to email addresses here. We can actually enforce a secure way to implement the lookups if we use them.