3 ms·

There's really no reason not to use email addresses for this use case. Consider, http://username:password@www.example.com/path?query=1#hash http://username:pa

There's really no reason not to use email addresses for this use case. Consider, http://username:password@www.example.com/path?query=1#hash http://username:password@www.example.com/path?query=1#hash Reduced to the parts that would actually matter (because username and path are redundant for this use case, and no one seriously embeds passwords in URLs), scheme://username@www.example.com So it seems that the design challenge is baking the scheme into zero or one glyphs. username@www.example.com Hey, that looks like an email address! A URL is an extended email address, an email address is a URL with default values.

echelon 4y ago
> There's really no reason not to use email addresses for this use case. As elegant as that would be, confusion could arise. Email and federated identities might be intersecting sets, but not are not guaranteed to be either subsets or supersets of one another. The ambiguity of this seems problematic.
- politician 4y ago
  I disagree, I think we should demand that `username@domain.com` (coupled with a digital signature) be the one true way (TM) that services treat identity. Whether domain.com supports an email service, an HTTP service, or a social service is secondary. Standardized representation of the principal is the primary concern. Twitter and Facebook represent the principal using their own alternative formats to assert ownership over the domain, not because they're good formats (@foo, fb.com/you). They've normalized the idea that the textual representation of the principal should be different between different services, but there's no fundamental reason it should be so.