2 ms·
I think there are _two_ primary issues with email addresses being used as a core part of account definitions. The one emphasized here is that email addresses ch
by abeppu 3y ago
I think there are _two_ primary issues with email addresses being used as a core part of account definitions. The one emphasized here is that email addresses change, but the other is that the user is giving every service provider they have an account with a _shareable/leakable_ form of contact info, which cannot effectively be revoked.
I wish we would move to a Permissioned Messaging Provider model, where a standardized API allows a user to issue tokens to specific parties to send messages, which is revocable, and where the user can control the destination and medium of those messages. You want your airline to be able to send you status updates about your flight? Great -- you can choose whether those messages arrive as emails, text messages, whatsapp messages, etc, and you can remove those permissions later if you like. Permissioned Messaging Providers will also change sometimes. I think a keybase-like mechanism could be used for asserting that you're the same person across two services, but knowledge that @user1@providerA is the same as @user2@providerB wouldn't allow anyone to send messages to either, since you still need a token (unlike announcing publicly that you're moving from myname@emailprovider.com to myname2@email2.net).