[x0x0]

I used to run a hybrid mobile app + webapp company.

Private emails regularly lead to awful customer service interactions because people cannot tell us the email they used to register. Fastmail at least is off the beaten path enough that people probably can understand. Apple, especially using sign in with Apple, is horrid. And not just people unable to tell us the email; they then create multiple accounts; try to sign in on web and use their actual email and then have 2 accounts and flip shit that their stuff is gone; etc. Oh, and regularly blame us for their confusion.

[trollbridge]

It’s up to the app architect to make a way to make this work, and to stop using emails as anything other than a UUID type of token

[JoblessWonder]

So I guess the solution is just to begin to allow accounts to always register multiple emails? Although I guess the issue of multiple accounts is still going to exist if the users don't know the initial (private) email that they signed up with though unless there is a different unique ID that everyone will be able to remember.

I'm curious (and not trolling by asking) what a solution might be since email has been used as a unique account identifier for so long it is hard for my brain to think of another option at the moment.

[trollbridge]

Use a platform like Authentik where the immutable characteristic of your user is a UUID.

Allow them to sign in with OpenID, etc., to put one (or more) e-mail addresses on (obviously those e-mails end up unique to that account), in my case, I always force-link e-mail addresses from Google's OpenID (mostly to prevent people accidentally creating multiple accounts). Allow phone numbers too!

Also allow usernames (and just automatically generate them); the user can change their username if they really want to.

Every other dependent system should only be using the UUID. If you have some dumb legacy system that insists on e-mails for a primary key, have an internal only domain and hang the UUID off of that.

There is a specific use case when two people want to have their own accounts but share an e-mail or a phone number for logging in. In that case you want to just let the user pick a "primary" email address and "primary" phone number (which is the only one they can log in with as a user ID) and the secondaries are just for verification. This is kind of common with people who want their spouse's phone to be able to get into their account for example (a pretty common use case for one of our apps, although they're technically supposed to make their own accounts, we allow this simple form of sharing).

[weakened_malloc]

Just a regular old username + password, kind of like HN allows?

[JoblessWonder]

I feel like email overtook usernames because it was more likely to be unique/memorable. I hate when websites ask me to remember a username (even though I'm using a password manager so I should really just calm down.)

[bigstrat2003]

Usernames are no less likely to be unique and memorable than an email. You presumably chose something memorable for your email, so just enter that without the @foo.com bit. There, memorable and probably unique.

[trollbridge]

That's what I set the defaults to in Authentik. Of course, you do have to watch out for poorly-designed systems that have "reserved" usernames.

[int_19h]

If you do require an email as an ID then yes, you absolutely should allow multiple emails per address if only so that the person can recover if they lose one of their mailboxes (similarly if you support hardware keys you should allow more than one).