Personas: calling and texting as someone else

I recently built Personas, an app that allows you to create identities, each with their own email, phone number, credit card, mailing address, and backstory. They are great for when you want to preserve your privacy — think about organizing a purchase on Craigslist, signing up for random services, or even just trying to avoid data brokers building a huge profile on everything about you.

There are other excellent apps in the space — I’ve been a longtime user of Cloaked, MySudo is another I hear good things about, and as a point solution, Privacy.com offers cards. But they are built as broad-adoption consumer services, and as such, they need to make some sacrifices (e.g. they typically use VOIP phone numbers which are often blocked; and no mailing addresses; etc.) to be able to offer the service at a low enough price point.

Aside from the sacrifices, my other gripe with them is the UX, which is not great. It’s a little clunky to use them, and I felt like it would be possible to make a premium version of this service with outstanding UX and sophisticated techniques for how it all works from privacy, identity durability, and ease-of-use perspectives.

I’ll probably write more later about more of how Personas works (including the backstory & security questions generation, the browser extension, the mailing addresses, cards, emails and so on), but I figured I would start with the UX of calls & texts from a persona because it’s (I think) the coolest part.

Say I make a persona, Mark Sanchez. Mark has a phone number — let’s say 628.555.0191 — and I can hand that number out to anyone. The magic is that when they call or text that number, I (Andy) get a call or text to my phone’s native phone or messaging apps from a different number specific to the combination of that sender and the Mark identity. It looks like this:

So what you’re seeing there, with Plumber · Mark Sanchez or (415) 555-0129 · Mark Sanchez, is the plumber or the phone number texting Mark at 628.555.0191, and then a totally separate number sending me a text — and the Personas app on my phone automatically creating a contact for that separate number that identifies it as belonging to Mark’s thread with the plumber.

I can reply there — in my native Messages app! — and then the plumber gets a text back from 628.555.0191. My text goes to the relay number, which gets it to the Personas system, which then triggers an outbound text from Mark’s number to the plumber.

Diagram of a text and my reply, five boxes in a row with arrows both ways between them: the plumber's phone, Mark Sanchez's number, the Personas server, a relay number named Plumber · Mark, and my real phone. The plumber only ever sees Mark's number. I only ever see a contact called Plumber · Mark Sanchez.

The exact same flow works for phone calls. The plumber can call Mark and I get a call on my phone from Plumber · Mark Sanchez. I pick up and talk to them. And if I call the contact back, even though I’m calling from my personal cell, the plumber sees a call from Mark’s number.

Diagram of calls, in two rows. They call: the plumber dials Mark's number, the Personas server rings my phone from the relay number, and my phone shows Plumber · Mark. I call back: I dial that contact, the Personas server rings the plumber from Mark's number, and their phone shows Mark's number.

This all makes it so smooth to use multiple personas — no need to go into an app to send a text or make a call — it’s all just native.

(Bonus: I figured out how to make the profile photos for the Personas numbers in my phone square — like how businesses look in iMessage — instead of circular, so they stand out… the trick is just to put the whole name in the “company” field and leave first and last name blank. You can even do this for your own contact and share it with people and you’ll be square!)

The obvious way to implement this is to use a programmatic telephony provider like Twilio or Telnyx to create the personas’ numbers. But there are a bunch of issues with this. First, many apps and services refuse registration to people signing up with the sorts of VOIP phone numbers providers use, or reject transactions from users with these numbers. And second, before a number like that can send texts, you need to register it with the carriers through a process called 10DLC. This is a pain, but more importantly, I don’t believe the carriers would accept this Personas use case without a bunch of direct negotiation.

So instead, I avoid this entirely by literally setting up an automated real phone with a prepaid SIM card in it (two, actually — one physical, one eSIM — in a cheap Android device). To websites, carriers, and anyone else, this is as good as a real human. Each SIM is one persona’s main number, so each phone covers two personas. This is the “hub” number for the persona.

And then, for the “relay” numbers — the ones that I, Andy, interact with — I use toll-free numbers set up via a programmatic voice provider. Because I am the only person who interacts with the relay numbers (third parties only ever hit the persona’s number), it’s a much lower-stakes use case. (It’s also fewer numbers than it sounds like — a relay number only has to be unique across a given persona’s conversations. So a small pool can be reused across everyone who uses Personas if necessary.)

Diagram of the two kinds of number. On the left, three other people (the plumber, a bike buyer, a delivery driver) all text or call one number, Mark's number, the hub number. That goes to the Personas server, which sends each of them on to my phone from its own relay number: Plumber · Mark, Bike buyer · Mark, Driver · Mark.

For texts, the hub phone is running a custom Android app that handles the inbound and outbound flow programmatically. This includes some special code to address photo messages, which are always routed to the native messages app by default (and so instead the custom app actually needs to monitor the messages database and pull them out).

There are also some tricky implementation details around phone calls. The hub needs to use carrier forwarding to a hidden phone number controlled by the server, which then calls my phone and merges the audio at the carrier level. And for outbound calls, the telephony provider actually (legally, with consent) spoofs my hub number for the caller ID.

Diagram of the hub phone, in two rows. Texts: someone texts Mark's number, which is a SIM in a cheap Android phone, and a custom app passes every text along to the server. Calls: someone calls Mark's number, the carrier forwards every call to the server's hidden number. Either way the server passes it to me from the relay number.

But the net of all of this is:

A fake persona gets created with its own phone number
I can hand that phone number out to anyone to text/call, or text/call people outbound from it
Third parties only ever see that one phone number
But on my phone, everything is broken up into individual threads or contacts for the combination of the third party and the persona, so I can use my native Messages and Phone apps to interact with them

It’s a slick UX, and has made me much more apt to use these for privacy in more situations, as opposed to legacy apps that require more painful flows.

In future posts I may write more about the other features — how to handle mailing addresses for these personas, how I generate the backstory to be coherent, the flow with separate Chrome profiles and the extension that helps with autofills and keeping identities uncorrelated, how shortcodes work (including a magical experience of both emailed and texted 2FA codes getting autofilled in the browser!), email forwarding (following similar principles to the phone), and more.

Looking for more to read?

Want to hear about new essays? Subscribe to my roughly-monthly newsletter recapping my recent writing and things I'm enjoying:

And I'd love to hear from you directly: andy@andybromberg.com