allow users to choose their own username

[00dani]

I know it's standard IndieWeb practice to have only one user on the domain, but that doesn't necessarily mean their name is "me", and it's misleading to return (for example) WebFinger data that claims it's for acct:me@example.com when that address doesn't exist.

For example, on my site, I've provided an email address in my representative h-card. When this is done, I think it would be appropriate for Bridgy Fed to use that email address to construct the acct: identifier for the user.

[snarfed]

sure! understood.

a few thoughts:

• OStatus/ActivityPub addresses only look like email addresses. they're not actually email addresses, nor do they interact with email at all, so technically it doesn't matter whether the corresponding email address exists.
• the username in an OStatus/ActivityPub address is part of its identity, so if it ever changes, your identity on federated social networks will change, which will surprise other users, and maybe you too.
• me is intended to imply that you're the site example.com itself, not just a single user on example.com, which another username might imply. (that also means that we'd need to figure something out for multi-user sites. ¯\_(ツ)_/¯)
• on a related note, what should we do if your representative h-card's email address isn't on 00dani.me? we need an @00dani.me AP/OStatus address. should we still extract and use the username from the email address? unclear.
• how should conflicts be resolved? e.g. if your representative h-card has u-email abc@00dani.me and p-nickname xyz (generally interpreted as preferred username), which should we choose?

having said all that, this still is reasonable, at least for email addresses on the same domain. i can definitely consider it.

[00dani]

Hmm, good points.

• I did know that OStatus/AP subjects aren't necessarily email addresses - none of my six (!) Mastodon handles are email addresses for example - but sources like https://webfinger.net seem to assume they might be? That client expects you to enter an "Email or URL", and if given an email address it uses the acct: scheme to look it up. It might just be that https://webfinger.net is misleading though. 😉
• If the username changes under this suggestion, it'd be because your email address changed, which is already part of your identity, right? Although, if Bridgy Fed's behaviour changed, that'd change existing users' identities as perceived from the fediverse. Hmm.
• Using me@example.com to convey "I'm the site example.com" is really good actually. I'm starting to think I should set up me@00dani.me, at least as an alias. Still, that won't work for multi-user sites, which still need another solution.
• The representative h-card's email address should only be taken as the username if it's on the same domain, I think. More specifically, I think it should work like this:
• If your representative h-card has a u-email on the correct domain, use that. If it doesn't, use p-nickname. If it has neither, fall back on me@domain.

Thoughts?

[snarfed]

thanks! good feedback.

another argument against me is that mastodon largely prioritizes username over domain when rendering remote users, just like local users, ie the bold me in toots and lone me.old in notifications below. not so useful. :/

[aaronpk]

I'm in a somewhat strange situation, and haven't actually decided what I want my "OStatus ID" to be. My web identity is aaronparecki.com, I use aaron@parecki.com for email, and I also have aaronpk.com which just redirects to my main website but I use that in print and when speaking my domain name. Since I normally go by aaronpk on the internet, I was thinking about using aaronpk@aaronpk.com for my OStatus ID.

[snarfed]

@aaronpk out of curiosity, how would you ideally want to tell bridgy fed to use aaronpk@aaronpk.com? p-nickname in representative h-card, which wouldn't include domain? u-email, which is overloaded and would have false positives? other?

[snarfed]

i'm tentatively changing the username from me to the source site's domain. we can still consider more sophisticated approaches like p-nickname etc, but this fixes an interop bug with mastodon and also improves username rendering there.

[tantek]

The site's domain is an excellent default and I think mostly mitigates this issue in a very appropriate way. Want a different username? use a different domain. E.g. if @aaronpk wants something like "aaronpk" as his user name, he can choose to use his aaronpk.com domain as the domain he federates from to Mastodon.

Given this point from @snarfed:

• username in an OStatus/ActivityPub address is part of its identity, so if it ever changes, your identity on federated social networks will change, which will surprise other users, and maybe you too.

It may be the right answer to "wont fix" the rest of this issue, or rather, close as "fixed" by being domain@domain centric and pushing the "choose your username" question to "choose your domain", since frankly, it's about "choose your identity" (per the point above) more than "choose your username" and that's your domain on IndieWeb anyway.

Reason for not allowing further customization: it sets the user expectation that they can "easily" not just choose but change their username (e.g. like on Twitter, your visible username in contrast to your @-name) without accurately reflecting just how much will break across federation when a user changes their "username", and the fact that there really is no solution to repairing that breakage.

tl;dr: don't give a user a (somewhat cosmetic) feature that makes the federation experience potentially much more fragile.

reframed more positively: the domain@domain default is like a guardrail, that you may be annoyed by bouncing off of, but better than driving off the edge of a cliff and having everything break.

And N.B. Oops I wrote this natively on GitHub and it's 2018-02-01 (per thread/mention in snarfed/bridgy#333 (comment)). Mea culpa.

[00dani]

domain@domain works for me. 👍

[00dani]

Ooh, wait, idea: the AP/OStatus identity could be customised on your h-card by adding a u-url property that uses the acct: protocol. False positives are unlikely, and the identifier that Bridgy Fed outputs would simply exactly match the appropriate u-url, if one's provided. Thoughts?

[00dani]

Alternatively, a specialised property could be devised, like u-bridgy-fed-acct, but I think matching the u-url values against acct: would be just as reliable.

[singpolyma]

+1 for hcard url (or rel=me ?) of acct: to set username

[snarfed]

fyi all, @singpolyma's #27 implements this by looking for an acct: u-url in the representative h-card, as descibed earlier here, which seems pretty safe and likely to only be used by people who know what they're doing.

i'm still a bit reluctant, but i think it addresses all the main concerns, so i'm ok with merging it. feel free to weigh in if you disagree.

[singpolyma]

@snarfed less important but related to this, it seems that https://github.com/snarfed/bridgy-fed/blob/master/common.py#L300 defaults the preferredUsername profile field, but defaults it on output from granary when granary never sets that field, so the default is always used.

Probably won't affect function, but might feel odd. Though I guess nothing in h-card directly maps to that field, but could use the user part from acct: if it matches nickname or something? Maybe I'm overthinking this.

[snarfed]

@singpolyma true! agreed, no user-visible impact of this right now afaik, but it could definitely use the acct: value too, or instead.