Convert from emails to user IDs to identify users

[gnprice]

This is a meta-issue which covers a large number of independent tasks. Filing it in order to have an identifier (ha) we can use to refer to the overall effort.

In general, Zulip originally used a user's email address as the primary way of identifying the user, throughout the API and the client data structures. This isn't good -- among other reasons, because people change their email addresses. So, years ago, we shifted toward using numeric user IDs. This was a slow migration, but the server and the webapp are now pretty far along; just about the whole API can now operate in terms of user IDs.

In the mobile app, though, we still pass around emails to identify users in lots of places. This often complicates the code, as different layers look up the email for a user ID and vice versa in order to communicate with other layers; it also leads to bugs when a user changes their email address. So we should fix it.

In general, this means:

• Almost everywhere that we pass an email in an API request, it should instead be a user ID.
  • If the API route doesn't accept user IDs, there should be an issue for that on zulip/zulip and a comment linking to that next to our code that passes an email.
  • This requires some care to handle older servers that don't accept user IDs on the given route; see Typing notifications are mistyped, resulting in rejection (for servers < 2.0) #3732.
• Almost everywhere that a React component takes a prop like email, it should instead be a userId.
  • Possibly everywhere. Anyplace where we have a good reason to take an email prop -- other than the boring reason that we haven't gotten around to converting it yet -- there should be a comment explaining why.
• Almost everywhere that we have an object or Map data structure where the keys are emails, they should instead be user IDs.
  • The main exception is the data structures, like the one returned by getAllUsersByEmail, that we use only within code we haven't converted yet. Once other code is all converted, those should disappear too, or be used only in rare exceptional spots. (E.g., sending email addresses in API requests to older servers.)

Tasks for specific instances of this migration include #3501 and #3525; #3196 was related. There are also a lot of parts of the code where the conversion is straightforward; in those cases we don't need to file specific issues, and can just refer to this one.

[agrawal-d]

Hi!
I'm going to work on migrating navigateToAccountDetails, AccountDetailsScreen, and getUserIsActive to user IDs, to make pull #3878 mergeable, as per #3878 (comment).

[gnprice]

As an update to see (most of) what remains for this task, I tried commenting out the email property on User:

 export type User = $ReadOnly<{|
   user_id: UserId,
-  email: string,
+  // email: string,

and seeing where Flow reported we're still using it.

• In several places we still use emails because old server versions didn't accept user IDs:

  • get-messages
  • sending PMs
  • subscribing other users to streams
  • sending typing status

  I think those are all old enough now that we can drop that logic.

• The one area that's blocked is presence: state.presence is indexed by email, and as a result components like UserAvatarWithPresence need an email. The root cause here is that the users/me/presence endpoint in the server API returns an object indexed by email. There's said to be work in progress on that on the server side.

• In several places we use emails and it's appropriate to do so:

  • computing Gravatar URLs
  • matching for autocomplete
  • showing a list of users, where we sometimes include their emails

  In the future the server API will make it clearer when we have a real email, and when we have only a fake email like user1234@chat.example; see chat thread (which is what prompted me to make this survey). Then we can have appropriate fallback behavior in these cases:

  • Gravatar: use user.delivery_email ?? user.email, i.e. use the real email if we have it and fall back to the fake (but also, if we don't have a real email then the server should have already sent us a URL)
  • autocomplete: use the real email or skip it (and then match only on the display name)
  • display: show the real email or say something like "(Email not available)"

  That's all out of scope for this issue; we'll make separate issues for it when the server API for it is ready.

The above points also cover the remaining uses of email on PmRecipientUser, and of sender_email on Message.

There are a few other places we use emails:

• In notifications, in sender_email on a notification for a 1:1 PM. New servers have sent sender_id for quite a while, and since 4773cf4 we assume they do, so we just need to complete the use of that.

• In authentication, where we use the self-user's own email along with their API key. This should probably also change -- the status quo can't be a good experience when you change your own email address -- but let's call it out of scope for this issue and make it a followup.