-
Notifications
You must be signed in to change notification settings - Fork 48
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
Comments
sure! understood. a few thoughts:
having said all that, this still is reasonable, at least for email addresses on the same domain. i can definitely consider it. |
Hmm, good points.
Thoughts? |
I'm in a somewhat strange situation, and haven't actually decided what I want my "OStatus ID" to be. My web identity is |
@aaronpk out of curiosity, how would you ideally want to tell bridgy fed to use |
i'm tentatively changing the username from |
…ications with screenshots from snarfed/bridgy-fed#3
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:
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. |
domain@domain works for me. 👍 |
Ooh, wait, idea: the AP/OStatus identity could be customised on your |
Alternatively, a specialised property could be devised, like |
+1 for hcard url (or rel=me ?) of |
This allows users to choose their own username for their webfinger ID. Closes snarfed#3
fyi all, @singpolyma's #27 implements this by looking for an 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. |
This allows users to choose their own username for their webfinger ID. Closes snarfed#3
@snarfed less important but related to this, it seems that https://github.com/snarfed/bridgy-fed/blob/master/common.py#L300 defaults the Probably won't affect function, but might feel odd. Though I guess nothing in |
@singpolyma true! agreed, no user-visible impact of this right now afaik, but it could definitely use the |
I know we can use u-url to change the fediverse username by setting it to acct:user1@example.com and then presumably the fediverse ID would be @user1@example.com but is it possible to have multiple "users" and so havr a fediverse user as @user1@example.com and another as @user2@example.com and so on. |
@damianbrown no, sorry, and I don't expect that any time soon. That would require #491, which wouldn't be easy, since "one account per domain" for web sites is pretty baked into BF's current design. |
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.The text was updated successfully, but these errors were encountered: