Usernames in Signal enter public testing stage

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 :sunglasses:


Fantastic! I likely won’t install this but nice to know we should be close to usernames in production Signal.

1 Like

Finally, we have been waiting for this for such a long time. I would have preferred random user IDs like on Session, but usernames are fine.


Why? (Out of curiosity)

This sounds amazing but I’m still not 100% sure how usernames work. Can these be read by everyone? Does giving my username out make it so that my phone number is visible?

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.


For me, privacy is about choosing which info I want to share, not becoming a complete ghost.

The main benefits of usernames for me would be the ability to share my Signal username online (something random) instead of my phone number (uniquely tied to my person).

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


Now my question: How ok is it to spread my username? Do I hide it like a phone number or can I put it in my mastodon bio so people can contact me?

I can just deny incoming requests, so I’d guess showing it to the public is fine?

Here is a few screenshots I’ve seen shared on Mastodon:



Perfectly OK if you’re OK with people contacting you, however, you should make sure your “Who can see my number” setting is set to “Nobody” before you share your username with people.


Alright! I did that. Thanks Jonah :slight_smile:

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.

Username links

There’s three main components to username links:

  1. An encrypted username blob
  2. A serverId (which is a UUID)
  3. “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.

Github commit

First mention of this commit that i read (hashtags ftw)