# Identities in Status. Work Package #1 ###### Tags: `Design` `identity` `security` **The Goal** Provide a simple and secure way for Status users to join a certain conversation (public, private or 1-1 chat) privately or publicly **Glossary** *Private Group Chat* – A group chat of 2 or more participans with invite-only access. Messages *can not* be read by anyone outside the chat. *Public Group Chat* – A group chat of 2 or more participans which anyone can access. Messages *can* be read by anyone outside the chat. *1-1 Chat* – A chat between 2 users. Messages *can not* be read by anyone outside the chat. *Conversation* – a Private Group Chat, a Public Group Chat or a 1-1 Chat. *Identity* – Profile of the user, consists of: - Public Name *(editable by user)* - Picture *(editable by user)* - ENS Username *(editable by user via ENS DApp)* - Contact code *(static)* - Wallet address *(static)* - Online/Last seen status *(dynamic, not editable)* *Primary Identity* – let's call the "real" profile this way for now. Example: Emily Clark *Burner Identity* – an "alternative" Identity. Example: Tremendous Unexpected Bull **The Problem** Currently, besides from the Primary Identity, user gets a generated Burner Identity. The idea is that you as a user reveal you Primary Identity to somebody only if you added that person to your contact list. The problem with this is that it's never 100% clear if the name is the Primary Identity. Also, this approach hevily relies on Contacts as an abstraction between a public and a provate conversation, which also imo causes confusion. **Possible ways of reaching the goal and solving the problem** 1. Generate and manage many burner identities; 2. Pre-generate one burner identity *(current implementation)* and improve contact management; 3. Generate a new burner identity when joining a new chat *(google docs style)*; 4. Global private/public mode; 5. Allow creating multiple primary identities and make it easier to switch between them; Below i tryed to describe each of those ways in more detail: **1. Generate and manage several burner identities** Screens: https://www.figma.com/file/FwEv7oz7gW9KGS69RtKcbPuL/Identity-types?node-id=0%3A1 This was the most promising concept to me. Lets the user to create many burner identities and choose wich one to share or to use when joining a chat. Burner identities can have limited possibilities: no way to change the name or the user picture. No profile-specific contact list, ENS username or profile-specific settings. There are several problems with this concept: - Are we allowing to export the recovery phrase for each "burner" identity? - If the burner identity has limited possibilities yet remains technically disconnected from the primary profile, would that create a confusion for the users? But there are also some prons: - Easy to swith from one burner identity to another and maintain anonimity; - Possible to destroy a burner identity if there's a risk it has been compromised; - Possible to join several conversations using the same burner identity. This could be important when there are several chats which have a contextual connection. **2. Pre-generate one burner identity** The current implementation. The problem with this is that it gives an illusion of anonimity (even if it's done right, not the current way). You never know if someone in a group chat is aware that "Big Salty Seal" is you. **3. Generate a new burner identity when joining a new chat** This way is probably the most elegan way UX-wise. Could work this way: each time a user joins a new chat, we provide two options: join using your primary profile or join "anonymously" and generate a conversation-specific burner identity. This reduces the complexity of option #1: no need to list and provide a UI to manage the profiles in the "Profile" screen etc. But this approach makes it impossible to join more than one conversation usnig the same identity, which i believe is critical as being not flexible enough. **4. Global private/public mode** Elegant concept, familiar to a lot of users from the "private" mode in web browsers, yet not flexible enough. Basically if a user wishes to join one public chat in a "private mode", but at the same time wishes to continue another conversation in "public mode" it creates a problem since we dont have "windows". They would have to continuously switch between public and private. A conversation-specific identity choice seems more flexible and closer to the goal we're trying to reach. **5. Allow creating multiple primary identities and make it easier switching between them** Screens: https://www.figma.com/file/FwEv7oz7gW9KGS69RtKcbPuL/Identity-types?node-id=329%3A0 The last but not least classic multi-account pattern. Could be the lowest hanging fruit in our situation. Basically it would be up to the user to create and maintain as many identities as they wish and what we do is just make it easier to switch between them. But what about the random names we all got used to? I think we should get rid of those eventhoug they are quite fun. Random names create confusion, as a user, you would never be sure if you see the Primary Identity or the random name. **The Scope** 1. User Profile updates - Account switching 2. Chat Profile updates - Introducing Chat Admin Management - Introducing a way to block users 3. Dapp Profile updates 4. Settings update - New Settings Structure - Privacy settings: chat invites, message requests - Improved Notification managmenent - Moving Wallet Settings to Settings - Passcode and Face/Touch ID settings - Data settings and export - Device Syncing 5. Introducing passcode lock + face/touch id 6. Minor Onboading updates 7. Minor text input update in chats **Questions** - Contact Requests? - Message Requests? - Tribute to Talk? - Sign in with Passcode? - Signing Transactions with Passcode?