But after some contemplation, I changed my mind. It's not so easy to say if there is a better alternative.
We need way to say "This is a Fediverse users. Their instance is xyz.com and their username is abc". A way that easy to grok visually and also by software.
abc@xyz.com - is alread taken for emails.
xyz.com/abc - would be a link
xyz.com@abc - is the wrong way round.
abc*xyz.com - would work. But is it good? Hmm...
Those are significantly worse, because they do not ambiguously state what @user@site does. This is such a minor thing to be up in arms about, aesthetically it looks fine and immediately communicates what it is.
I think inverting this is also a sweet spot. It lets you drop context if on a locally federated node:
@abc/xyz.com
@abc[/xyz.com]
@abc
The username first prioritizes the human, and the host instance lookup can be added with tooling [1].
We should weigh ergonomics, visual distinguishability, ease of parsing from plaintext (important), ease of typing, visual aesthetics, simplicity, and extensibility.
We should collect dozens of candidate formats and weigh them on these (and more) dimensions.
[1] (eg. autocomplete that doesn't change the previous buffer, unlike, for instance, Google Docs chips).
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.
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.
It isn't as easy to type as @. In fact, my keyboard doesn't even feature a tilde written on any of the keys, so I make it appear solely from muscle memory.
Comments
In my humble opinion the double asperand is a visually atrocious abomination and wholly redundant. I hope this pattern dies quickly.
I had the same reaction at first.
But after some contemplation, I changed my mind. It's not so easy to say if there is a better alternative.
We need way to say "This is a Fediverse users. Their instance is xyz.com and their username is abc". A way that easy to grok visually and also by software.
These are definitely better:
Those are significantly worse, because they do not ambiguously state what @user@site does. This is such a minor thing to be up in arms about, aesthetically it looks fine and immediately communicates what it is.
I think this portion of the discussion on the ampersand satisfies the definition of "bike shedding", right? :-)
I'm not sure. I don't like @abc.xyz.com at all.
@xyz.com/abc has the nice benefit that it is like https://xyz.com/abc with only the https:// part is changed.
But "Written by @joe@someinstance.com" reads much nicer than "Written by @someinstance.com/joe".
@xyz.com/abc is the best I've seen so far.
I think inverting this is also a sweet spot. It lets you drop context if on a locally federated node:
@abc/xyz.com
@abc[/xyz.com]
@abc
The username first prioritizes the human, and the host instance lookup can be added with tooling [1].
We should weigh ergonomics, visual distinguishability, ease of parsing from plaintext (important), ease of typing, visual aesthetics, simplicity, and extensibility.
We should collect dozens of candidate formats and weigh them on these (and more) dimensions.
[1] (eg. autocomplete that doesn't change the previous buffer, unlike, for instance, Google Docs chips).
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
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.
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.
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.
Given decades of ~abc for a home directory and xyz.com/~abc/ URLs, perhaps the tilde could be put to use yet again:
It isn't as easy to type as @. In fact, my keyboard doesn't even feature a tilde written on any of the keys, so I make it appear solely from muscle memory.
abc@xyz.com is definitely not taken for email. It works as a HTTP url, or SSH logins and it can very well work for ActivityPub.
needs to be differntiated from email (or maybe not, i would prefer it if SMTP was just extended to be social)
what would be a better format?