New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow users to choose their own username #3

Closed
00dani opened this Issue Sep 30, 2017 · 14 comments

Comments

5 participants
@00dani

00dani commented Sep 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 2, 2017

Owner

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.

Owner

snarfed commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@00dani

00dani Oct 2, 2017

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?

00dani commented Oct 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 4, 2017

Owner

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. :/

image

image

Owner

snarfed commented Oct 4, 2017

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. :/

image

image

@aaronpk

This comment has been minimized.

Show comment
Hide comment
@aaronpk

aaronpk Oct 23, 2017

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.

aaronpk commented Oct 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 23, 2017

Owner

@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?

Owner

snarfed commented Oct 23, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 26, 2017

Owner

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.

Owner

snarfed commented Oct 26, 2017

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.

snarfed added a commit that referenced this issue Oct 27, 2017

@snarfed snarfed changed the title from Shouldn't always assume the username "me" to allow users to choose their own username Dec 31, 2017

aaronpk pushed a commit to indieweb/wiki that referenced this issue Feb 1, 2018

@tantek

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Feb 1, 2018

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.

tantek commented Feb 1, 2018

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

This comment has been minimized.

Show comment
Hide comment
@00dani

00dani Feb 1, 2018

domain@domain works for me. 👍

00dani commented Feb 1, 2018

domain@domain works for me. 👍

@00dani 00dani closed this Feb 1, 2018

@00dani

This comment has been minimized.

Show comment
Hide comment
@00dani

00dani Feb 1, 2018

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 commented Feb 1, 2018

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 00dani reopened this Feb 1, 2018

@00dani

This comment has been minimized.

Show comment
Hide comment
@00dani

00dani Feb 1, 2018

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.

00dani commented Feb 1, 2018

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

This comment has been minimized.

Show comment
Hide comment
@singpolyma

singpolyma Feb 27, 2018

Contributor

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

Contributor

singpolyma commented Feb 27, 2018

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

singpolyma added a commit to singpolyma/bridgy-fed that referenced this issue Apr 12, 2018

Use the acct: URI for this domain, if in h-card
This allows users to choose their own username for their webfinger ID.

Closes #3
@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Apr 13, 2018

Owner

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.

Owner

snarfed commented Apr 13, 2018

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 added a commit to singpolyma/bridgy-fed that referenced this issue Apr 16, 2018

Use the acct: URI for this domain, if in h-card
This allows users to choose their own username for their webfinger ID.

Closes #3

@snarfed snarfed closed this in #27 Apr 16, 2018

@singpolyma

This comment has been minimized.

Show comment
Hide comment
@singpolyma

singpolyma Apr 16, 2018

Contributor

@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.

Contributor

singpolyma commented Apr 16, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Apr 16, 2018

Owner

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

Owner

snarfed commented Apr 16, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment