changing username?!

[MenaHabib]

Is there any way to change the username without starting all over again?

[KirinDave]

I would like this to. There are many life events that may indicate a changed username.

[wintryKat]

I'll also throw my 'name' into the box for this feature request. I am a transgender woman and I am working to update my name/username everywhere, though keybase is a special situation. Unlike other services where I'm comfortable throwing the old accounts away I really want to maintain a hard link between my old and new identities on keybase for authentication of my new identity.

Might an alias be supported in cases where it's necessary? Maybe require some additional verification step to allow one user to have two aliases?

[malgorithms]

I feel everyone's pain on this and have in the past just encouraged people to nuke their accounts and make a new one.

the problem with this feature is that it's not as simple as on normal websites. Elsewhere you could imagine just making an alias table or something. With keybase, a name maps deterministically into our merkle tree, so you know everyone is getting the same answer for a user; from there you can play back their chain of signed announcements.

Technically it could be solvable by something like this: a username, X, terminates their chain with a signed announcement that they're switching to username Y. Then username Y begins its own sig chain with a signed statement using one of username X's keys, and also claiming it's accepted this username switch. From there, clients need to be able to start with X or Y and follow either sig chain and follow that it all makes sense. There are timing things to get right, since normally there's no guaranteed total ordering with X's and Y's chains, but that could be enforced.

But from all that, the clients need to be able to understand this process and all kinds of things like following someone and managing existing chats and and folders need to understand this change, and a lot of security UX has to be introduced to explain why you're seeing someone under new names.

so yeah, technically we can do this, but it's not like on other sites. If Twitter wants to let people change usernames, they can just do it. We will pour many, many person-months into it to support that.

which means, sadly, that something like our mobile app, performance improvements, and other crypto features all need to come first. not because we don't support this idea, just because we can't get it all done very soon.

So our official reply is that we like the idea but probably aren't going to be able to work on it in the next few months....it's the same old answer for now - you can delete your account and make a new one! sorry.

[KirinDave]

@malgorithms I'm in a similar situation to wintryKat and what I can say is that I accept that this is a complex feature. Migration records might not be a terrible plan, but there is an easier solution.

I genuinely don't mind that I have to migrate PGP keys to change my name, and I don't even mind if my password manager still fills in my old name. What I do mind is having that name be the URL and display by which I introduce myself and how people look me up in the system. The underlying system could call me 56-55 for all I care, what matters is how I introduce myself in a social context to other humans.

[jacklynrose]

Any update on this?

[pixelyunicorn]

I ended up deleting my account because of this issue 😞

(I've been a user since HN launch, but my username is literally a name I longer use)

[edwardgrubb3rd]

Please Add

[maxtaco]

Sorry, it's not on the road map. Too many security headaches on all sides of this issue.

[maxtaco]

(I'll leave the issue open though for further discussion and/or updates, though none are anticipated)

[blackforestboi]

Hey folks!

I totally understand that this is not on your roadmap and that there are just other competing commitments. It's such a complicated feature request that requires a lot of architecture changes. To make such a big decision about a user name may better be delayed as much as possible and if so done in full awareness for the user.

The following things don't seem too hard to implement, but greatly greatly improve the UX:

1. Making it really clear, maybe even with a popup, that the user name cannot be changed later.
2. (maybe) making adding the name the last step of the whole signup process so people can start exploring some things.

[junderw]

If you are changing your user name, all the trackers and proofs are signing a commitment to your current user name... so changing user names should not be allowed (even with some super complex sigchain trickery that risks destroying the whole point of keybase)

However, the workaround should be making a workflow of create new account -> provision first key -> migrate KBFS data that is as seemless as possible.

KBFS data migration as of current would require downloading all the data, and rsync-ing it to the new account etc... which is probably the biggest hurdle for me.

As far as getting people to re-follow you, re-doing proofs, and re-joining teams... that should be a manual process, otherwise I could easily phish people by just saying "oh I changed my name, but you don't need to re-follow me"

When someone follows my new account they should unfollow my old account, and eventually I should just delete my old account.

I understand 90% of users are coming at this from a "twitter, tumblr, discord, slack" type platform image...

But for the 10% of us that use Keybase for its security properties, please do not do anything that will undermine the security of the platform and make it easier to phish etc.

[junderw]

1. Making it really clear, maybe even with a popup, that the user name cannot be changed later.
2. (maybe) making adding the name the last step of the whole signup process so people can start exploring some things.

@blackforestboi makes a good point. Education on how Keybase works from the get-go should help people from picking a name that they might no longer like down the line.

[NyanHelsing]

@junderw What about implementing a nickname feature; a user can then pick a nickname to show in chats, but the user id would not change. I.e I look at a person's profile and I see their keybase username, and verify the persons identity/proofs, and that they've chosen to be known by the given nickname?

[junderw]

This is the same problem.

Phishing becomes easier, as I can just download your icon and use your name as my nickname.

Yes, a person paying attention could see through it, but the whole point of phishing prevention is to protect the users who don't pay attention.

Not to mention I think the point of this request is to disassociate yourself from your old user name. So a nickname feature would not please either side of this argument.

[NyanHelsing]

@junderw

As a user concerned about people I follow phishing me, I find more inherent risk in accepting a brand new account with a new name that I have never followed than I find in allowing the account I already follow to be known by a nickname. The history that some followee's account contains about proofs isn't discounted by a change in name; that history still exists to tie that accounts together.

Nicknames would need to be unique; out of the same space as usernames. If I know that nicknames can't shadow other users, I see no greater threat from this nicknames phishing mode than I would from users creating similarly named accounts.

If I am a user who wants to change my username, I would see a massive benefit to keeping the history, conversations, projects, etc. that already exists in the account. If I accept that that benefit is something I don't want to give up, but I also accept that the ability to change my username is something that the architecture of the platform doesn't easily permit, I think you'd agree that the ability to define a nickname in this manner actually would please me if I'm being reasonable.

If my goal actually is to disassociate myself from the account and it's history, I would still be left with the option of creating a totally new account. Either way, the usernames I can choose from in creating a new account and in choosing a nickname would need to be taken from the same pool.

[junderw]

I find more inherent risk in accepting a brand new account with a new name that I have never followed.

Which is understandable, and even desirable.

If anyone can change their nickname at any time, users will get used to just brushing off name changes and not thinking too much of it.

If my chat feed entry for our conversation is constantly changing, I will be less likely to realize something's up when some guy creates a new account with a name you would probably choose.

A name change SHOULD raise red flags and require me to re-verify your identity out of band.

Having a system where changing names willy nilly 100 times a day is ok will desensitize users, and that one time when you sigh and think to yourself "another name change? ok, here's the secret document." then two seconds later realize "wait a second, that wasn't a new nickname, but a new account completely!?" it will be too late.

[NyanHelsing]

A nickname change in a user I follow could easily be designed to require me to accept the change, just as a change in proof requires. Honestly, If I am following someone that changes their name every 5 minutes, I'm going to notice that, especially with it requiring me to accept any change they might make. This would prevent users from "not thinking too much of it."

The requirement about usernames and nicknames coming from the same pool makes it impossible for someone to create a nickname for themselves with a name they couldn't create a new account with. If I already have a username, I can rest easy knowing that nobody that creates a new account can have the one I have, and nobody would be able to create a nickname with it either.

If my chat feed for that conversation is constantly changing, that IS the red flag and it is raised because the name has changed!! I'll notice the username has changed; thanks to the requirement to accept that change (Just like if you changed a proof), and I'll know who the person is. This would also allow you to distinguish between new account vs new nickname in the last example you mentioned.

Your last example poses an issue. The problem is that the account getting a new nickname is more trustworthy than the new account. From the user with the secret document's shoes, I have a followee that either in the current state of affairs,

I don't recognize this name. They say they're so and so, used to be so and so with a different account. Hmm that account still exists and I'm following. Idk about this...

or in a system with nicknames...

I don't recognize this name. They say they're so and so, used to be so and so. I look at the account. I see all the proofs, I see that they did indeed change the name; I know this information I want to send will only be available to that user's devices.

There is the case that I may have forgotten the user's old name, and verifying the wrong name would lead me to be vulnerable to a phishing attack. I am no more vulnerable to this in a system with nicknames than in a system without, because in both, the space for names a user can choose is the same; a user in the system without nicknames could still create an account with a similar name.

If you agree with this:

I find more inherent risk in accepting a brand new account with a new name that I have never followed.

which it seems like you do, because you said this:

Which is understandable, and even desirable.

We should use this thread to explore ways to make the problem more solvable, and allow this source of risk to be minimized.

[dowlingw]

How about adding a ”keybase” proof?

This would allow people to attest that their new keybase identity is related to their old one, which is a key feature of the platform.

Proofs could be published in a users public part of their keybase filesystem, so this would really only need significant effort in the keybase clients (perhaps an oversimplification).

Whether the user then re-establishes all their proofs or keeps multiple identities active can be flexible based on their situation.

[ilyvion]

I may not fully understand the problem, but couldn't you do something like this:

Keep the current usernames as the internal representation of an account (the one used in merkle trees and whatnot), and add a new field, which is a changeable username. Set this new field to be the same as users' currently unchangable username. Now you can allow people to change who they show up as, while still keeping all their old proofs and whatnot.

New accounts just get assigned a random, non-colliding value for the internal representation, and to avoid phishing/impersonation, these changable usernames should be required to be unique, and once used, never reclaimable (except perhaps by a previous owner). To avoid somebody running a bot claiming/hoarding 10000 usernames in an hour, have some kind of cooldown for name changes.

[jwarkentin]

The whole point of the signing and proofs is establishing identity. I want to know that when I'm interacting with user X, they are the same person I first connected with and believe them to be. I don't care if X decides to be known as Y or Z. What I do care about is that I still personally know who the individual is behind that name and can be equally confident about that fact on my 2nd or 3rd interaction as I was on my 1st.

The problem here is that for some insane reason we conflate identity verification with identity recognition. People should be able to identify/describe themselves with any descriptor they want. And that may change and evolve over time as people change and evolve or circumstances do. That person's choice should not in any way change my ability to know or recognize that they are still the same individual.

Fundamentally, this is an auditing issue. I don't give two flying fucks what someone's username is at any given time. What I do care about is my own understanding of the person behind the account and my past relationship with them.

I think a better solution would be allowing me to assign my own identifier/description to any user I want so that I have a constant to recognize them by. And once I've interacted with a user, if I haven't assigned my own identifier or description to them, then I should always see the identifier that I first saw when interacting. That way, I always know them the same way. And if they change their username, I want to have the option to leave the old identifier because I know them by that, or use the new one they have chosen if I don't care about the particular individual's identifier at the time or interact with them enough that I know I will remember and quickly get used to the new identifier, or just assign something else completely custom that I know will always be a clear indicator to me of who they are.

The point They should be able to choose how they identify themselves and I should be able to choose how I identify them. Neither of those chosen identifiers should change the underlying proof that they are in fact the same individual. We've coupled two separate things that don't need to be coupled for any reason.

Having a quick, editable audit log of past interactions with a given account (date/time & interaction type) would also help to reinforce the account identity in relation to the way that I personally know/identify them. That's way more reliable than depending on their chosen identifier at any given point in time to inform me of who they are.

[chindraba-work]

@jwa

Having a quick, editable audit log ...

Bad idea. If it's editable it has no practical value for audit purposes or logging. Immutable log has to be in-built to the system or there's no trust to speak of.

Identity verification and identity recognition are the same thing in the online virtual world. There are rare exceptions, of course, yet in the main how we "recognize" users is by their username, and how we "identify" them is also by that username. I've yet to find a system which allowed me to "tag" a user to recognize them my way no matter what they did to change their username. I have been in a system where users could change their names at will, and the record of comments gets all scrambled when the comment refers to a now empty username, and gets responded to by some other name. On another platform they can change their "nickname" on a per-channel basis, and it's linked to a system name. That was "okay" until I found that even the system name was changeable, with enough money.

For a system, with the security implications of Keybase, changing your username, the "identity" by which you present to the rest of the system, should be at least as hard as changing your name on your government issued identification papers.

If you have an email account with Yahoo, Gmail, or Hotmail, etc., how easily can you change your username there? To the best of my knowledge, you cannot. You can open a new account, and close the old account. Between opening and closing you can send an email to other contacts to inform them of your new account, and hope they remember. You can copy, manually, all the data connected with that account (emails, Google Drive contents, etc.) from old to new if you choose. In neither case does the system provide a method of migrating one account to another. As far as their system is concerned the two accounts are not connected in any manner.

In short, I don't support the concept of changing user names on accounts, for any reason, nor of linking an old account to a new account using any of the system's automated processes. If someone wishes to change their identification in KB they can make a new account, connect the proofs to the new account, and suffer the consequences of some users not taking the time to reconnect with the new identity. Out-of-band verification is expensive in terms of my time. If I spent the time to do it the first time, I expect it to be worth something. If the username, and everything else, has been changed, I just might not re-verify the account.

[jwarkentin]

Identity verification is about a verifiable mathematical proof that I am communicating with the person I think I am and not a MITM or other 3rd party attempting to spoof identity.

Identity recognition is associating that proof (an identifier in its own right) with an identifier that helps me as a mere human to know who that mathematical proof is associated with.

It doesn't matter if the identifier I recognize that proof by changes as long as I know that the new identifier and the old identifier referenced the same proof.

For the sake of further avoiding possible human errors, it would make sense to allow me to choose a personal identifier to associate with anyone's proof to help me recognize and remember who that proof belongs to.

[chindraba-work]

If, per chance, you were to assign one name to a user while I assign the same name to a different user, concurrently a user has selected that very same name as their "official" name, you and I are left with the inability, sans convoluted interactions, to discuss either of the three users without first stating which "identity" we are referring to. Adding additional users, having selected their own nicknames for users we might have in common, and the problem compounds significantly. Now, where's the "further avoiding possible human errors" come into that scenario?

If, on the other hand, a user creates, or selects, a name, from a pool of never-to-be-reused names without the possibility of changing it, or hiding it behind some other nickname, when user asmith13 is addressed, directly, by reference in some other communication, or by the client verifying the attested proofs, there will never be any misunderstanding, or significant probability of error, human or machine, relative to which collection of mathematical proofs are connected to the user id asmith13.

I much prefer that assurances, and associations between "identities" is immutable, and guaranteed so by machine-based mathematical proofs, than to have it based on my memory, or worse yet, the whim of a third party.

Your choices (assigning a personally chosen identifier to others, or selecting and changing your identifier) could be limited by that setup. At the same time my trust in the presented information is enhanced, and the associated security is magnified.

Just today I was in a channel where, as a joke, the users were changing nicknames, and avatars, to mimic each other. At one point there were 14 users with the same name and a collection of 3 avatars. It was a group of long-time associates, and style alone identified most of them anyway, but it was a bit confusing nonetheless. Where assurance of identity and security of data is concerned, such a mess would be completely unacceptable.

[c9s]

I started using keybase from market.link, the UI made think the account name is a team name, and now I found that I can not change it. :-\

and the deleted account name can not be reused... now it's like a disaster...