Admin should be able to deactivate/reactivate a user with no data loss

[holmesworcester]

When an admin removes a user, we should be able to re-instate that user with no data loss. What would the UI for this look like?

User story:

A newsroom has journalists who sometimes work in a dangerous area where their phone can be seized by law enforcement. Before travel to this area, an admin suspends the user, or perhaps the user suspends themselves. This deletes all message and community data from their device--except the restoration key, which is not visible in the device UI. When the user returns, to restore the user the admin marks them as re-instated (they appear as removed in a list of users) and then sees a special invite link to provide to the user. The user would open the invite link and their account is restored using the restoration key stored on that device. Their account is fully restored, including DMs.

Additional feature: to delete Quiet completely from their device, the user can write down the restoration key as a series of words, like a BIP39 passphrase.

Notes:

• To start with we can just focus on the scenario where the admin suspends the user, and not the one where the user suspends themselves.
• We need a members screen where an admin can suspend a user. (Maybe this is the same as remove? Or maybe this is the first step to removing someone)
• Admin should be able to see suspended users and click to unsuspend
• We need to see the workflow for unsuspending someone.
• Users mention LastPass and 1password as tools where in team mode admins can suspend and restore users.

[holmesworcester]

Let's have some bullets to see if users understand what "deactivate" will do and what "remove" will do.

[holmesworcester]

Bullets for "Deactivate":

• Notifies everyone of deactivation
• Denies access to new messages
• Attempts to delete community from their devices
• You can reactivate user later

Bullets for remove:

• Removes user permanently
• Deletes all user DMs
• Cannot be undone

[jgaylor]

@holmesworcester here's the Figma.

1. I added the bullets to the 'Deactivate' info page.
2. I added a 'Remove' info page and user flow for removing.
3. I'm unclear on what needs to be on the page when a user reinstalls after previously being active. I left comment in Figma.

[jgaylor]

@holmesworcester

I’ve made some updates to the Figma and I have some thoughts/questions

1. Updates
   1. Bring back deletion
   2. Explore variations of the deactivated profile to improve the UI
   3. Add flow for getting the key/passphrase into onboarding
   4. Where should we add the ‘generate passphrase’ flow?
2. Assumptions based on our conversations in Slack:
   1. If a user deletes and reinstalls the app, they must contact a community admin to send an activation link and unlock their account.
   2. Users won’t be set to status ‘deactivated’ when they delete the app on iOS: iOS doesn't provide direct hooks for an app to execute logic upon being deleted from the home screen.
3. Current scenarios
   1. Scenario 1—Admin deactivates another user:
      1. User is currently active and has the app.
      2. Admin deactivates them
      3. Admin reactivates them and sends them a link
   2. Scenario 2—User deletes app
      1. User has uninstalled the app, and then reinstalled.
      2. The only way they can get back in is by following an activation link sent from an admin.
      3. When the admin goes to get the link the user is not in ‘deactivated’ status
      4. Admin deactivates the user
      5. Admin reactivates the user and sends them a link
   3. Scenario 3—User deactivates themselves
      1. User goes to their profile and goes through deactivate flow
      2. When they do this it deletes all message and community data from their device
      3. From here an admin can reactivate them and send them a link
4. Problems
   1. Scenario 2 is really cumbersome. Is this expected and ok?

[holmesworcester]

Notes:

"Scenario 3" above actually splits into a few cases:

1. The user does "leaves community" on one or more of their devices - nobody else sees them as deactivated and their other devices are unaffected. Maybe they only want quiet on their desktop and not their phone, or vice versa.

2. The user "deactivates" themselves using their profile - they need an invite link to get back in.

3. The user "removes" themselves from their own profile - their account is irrevocably destroyed so they'd need to make a new one later.

I think it's an interesting question whether we do 2 or 3. Let's assume that we want to, do some designs and get feedback. We should note to users that the best way to remove themselves is to do "leave community" on all their devices. The warning would be: "Be sure to run Quiet on your other devices to ensure deactivation has taken place. You should probably leave this community on all devices to be sure."

[jgaylor]

Since the profile is per community (I could be Jason in one and Bob in another) It seems there are only 2 'removal' options for the user:

1. Self-removal from a community
2. Self-deactivation from a community

I presume both of these would happen by going to Community (E.g. nyc-activism), navigating to a profile and going through the flows for either of those options. Both of these would be community-based.

If we want the ability for a user to remove or deactivate all data or all communities, it seems we'd need a concept of a global user. Otherwise, I would not expect to leave other communities if I removed myself from one. And I may not want to deactivate myself from all communities, but rather just one.

Thoughts?

[jgaylor]

@holmesworcester With that said, I started to rough out some things around self-deactivation from a community and Self-removal from a community, but they are more about communicating my misunderstandings or questions, and to give us a starting point for discussion.

Overall there are a lot of unanswered questions on this spec and feels very wide in scope. I think it's in need of your attention so we can focus and be intentional with next steps. Hopefully the rough starts help guide us. Maybe we can workshop when you are feeling better.

[holmesworcester]

This looks good. I left some comments and made a few copy changes.

The main idea here is that one reason for self-deactivation is that users want to remove evidence of being part of a community from their phone.

We'll still have a recovery key on there but we don't need to label it at all in our locally stored data, and we don't need to show anything in the UI.

[jgaylor]

The main idea seems clear. We're now looking a possibilities for where users end up in various scenarios. Based on your reply and comments in figma my understanding is as follows:

1. Users are deactivating or removing themselves from a specific community, when they do so...
2. If they aren't in any other communities, then they are taken to the "Let's get started" view where they have the actions we already know about (Join with invite link, QR code, Create new community). When they land here, we'll show "Deactivated" alert for X seconds before it fades out.
3. If they are in other communities then we should take them to the home page of another community, and the community they left is no longer available in the community switcher. Which community we switch them to TBD, maybe just the first one on the list. This seems simplest if we want to remove all indications of the community they self-deactivated/left and if we don't want to communicate anything about how to get reactivated. If we don't do this, the other option is to have some sort of new community launcher screen like I showed in the mockups, but this doesn't seem necessary now.

Are we seeing this this same? If so, next step is to update the mockups to reflect this thinking.

[holmesworcester]

Sounds good to me

[jgaylor]

I've updated the two flows we've been discussing:

1. Self-deactivate from a community
2. Self-removal from a community

Let me know if you have anything else on those.

[jgaylor]

@holmesworcester In addition to those items above, some other things awaiting feedback/discussion:

1. You asked me to explore different ideas for Deactivated indicators
2. I'd like to get your opinion on where you think it makes the most sense to add the flow for generating a 12-word passphrase in onboarding. Mock-ups here

[holmesworcester]

For reactivation, I think the best option is this one.

Though I think "deactivated" would be better here than "inactive" for consistency.

[holmesworcester]

For reactivation, I think the best option is this one.

For where to put the 12-word backup code, immediately after opening the reactivation link is best.

[jgaylor]

Thank you. Here's the latest Figma

Outstanding would be exploring desktop for all of this, but I'd wait until we've decided if all this works.

[holmesworcester]

This looks good!

[holmesworcester]

I got some feedback on this that seems actionable. Comments in Figma.