The public can now test usernames on a live Signal staging network. This is independent of the regular Signal network, so you still can’t add a username to your current Signal account yet:
Think of The Staging Environment as a parallel Signal universe: you’ll need to install and run a new build (links below), and register for a new account with a phone number (you can use the same one you’re using in Production). Anybody you wish to talk with in Staging needs to be registered in Staging as well.
This has got to mean usernames in the real Signal app are close now though
Usernames encourage people to stick to bad privacy practices. People tend to put personally identifiable information in their usernames, just like with email addresses. I’m sure many people will use firstname.lastname or something like that. With randomized IDs, everyone’s ID would be anonymous by default.
@Stuxey true, but Signal adds a (~2 digit) discriminator to the end of each username to at least prevent people from randomly guessing someone else’s username based on personal information (like if I request “jonah” Signal might give me @jonah.87 or whatever).
@amog you’ll have the option to hide your phone number in your profile when this feature releases.
A LONG time coming. There’s one thing that i’ve had doubts about is if they were gonna drop phone number requirement since they’re rolling out the usernames, and the answer is apparently no (a quote from the subject forum link):
Installed this staging app but it still requires a phone number. I don’t see a way to bypass that. What good is a username if we still have to disclose a phone number.
(The answer): The point of usernames is to allow you to join groups without revealing your phone number to everyone in it as happens currently. Or so that you can hand out a means of contacting you to acquaintances/coworkers/whoever that doesn’t give them your personal phone number. Usernames also can be changed at will – you don’t register with them as some kind of permanent account identifier. You still have to register using a phone number, but usernames have plenty of value.
And yeah, it kinda makes sense. They needed phone numbers to help combat spam and bots, and so it’s gonna stay that way, but usernames are gonna be just kind of disposable pseudonyms to give out to strangers and to hide your real phone number behind.
Pseudonyms were the only Telegram feature that made me recommend it to activists instead of Signal and it’s otherwise indubitable and unconditional advantages, but now with Signal rolling out pseudonyms i’m gonna finally reconsider and ditch Telegram for good (or at least join Henry, Nathan and Jonah on the Telegram hate train).
A commit from two days ago with some interesting details:
(I´ve done my best to try and clean up the formatting).
Usernames and username links are more complicated than you may think. This is because we want the following properties:
We want usernames to be assigned a random numerical discriminator to avoid land grabs
We don’t want to store plaintext usernames on the service
We don’t want plaintext usernames in username links
We want username links to be revocable and rotatable without changing your username
We want users to be able to turn a link into a displayable username in the app
As a result, the process of reserving them, creating links, and parsing those links is more complex.
Setting a username
To start, let’s define a username as being composed of two parts: a nickname and a discriminator. The nickname is the user-chosen part of the username, and the discriminator is a random set of digits that we bolt onto the end so that people can choose whatever nickname they want. So a username ends up looking like this: mynickname.123
Setting a username is a multi-step process.
The user chooses a nickname.
We take that nickname and pair it with a bunch of possible discriminators of different lengths, turning them into a list of possible usernames.
We hash those possible usernames and submit them to the service. It will reserve the first one that’s available, returning it in the response.
We present the (nickname, discriminator) combo to the user, and they can choose to confirm it.
If the user confirms it, we tell the service the final username hash, and it saves it as the final username.
There’s three main components to username links:
An encrypted username blob
A serverId (which is a UUID)
“entropy” (some random bytes used to encrypt the username)
The service basically stores a map of (serverId → encrypted username blob). We can ask the service for the encrypted username blob for a given serverId, and then decrypt it with the entropy. Simple enough.
How are those pieces shared?
Well, the link looks like this:
https:// signal .me/#eu/<32 bytes of entropy><16 bytes of serverId uuid>
So, when we get a link, we parse out the entropy and serverId. We then use the serverId to get the encrypted username, and then decrypt it with the entropy.
This gives us everything we want:
We can rotate our link without changing our username by just picking new (serverId, entropy) and storing a new blob on the service.
When the user decrypts the username, they see it displayed exactly how the user uploaded it.
The service has no idea what links correspond to what usernames – it’s just storing encrypted blobs.