As mentioned in the description coalescing mechanism changes slightly and so does user experience. I recommend that reviewers watch recordings attached below:
Current coalescing:

NSE coalescing:

CI

rebase

• curve25519 -> ed25519
• deviceID -> userID
• remove auto-establishing session

In D8993#268930, @ashoat wrote:

At some point we'll probably want to think about how uploads might work in the background. If the backup is large, I could imagine that the client would need background upload in order to complete the upload. Is there a task to track this?

We probably should memoize the rules

Probably moving policies logic from the responder itself to a higher place where we just avoid returning anything will make this code simpler - but since this will change in the future anyway (ENG-4137) it's okay the way it is

Merge

Small fixes

This looks strange. We were rendering ChatContextProvider quite high in the tree, a couple of levels above navigation. Now, in order to make it accessible in other places, we're placing it within navigation. So it seems we're reducing the number of places where it is accessible. Am I missing something?

It might make sense to introduce a new hook that:

1. Get the candidates using useThreadChatMentionCandidates
2. Computes the rules using getDefaultTextMessageRules
3. Memoizes them using memo

In D9033#268896, @ashoat wrote:

@kamil, would you be interested in commandeering this revision?

Amend test plan, don't set userID if not needed. Also added a log for clearing sensitive data.

Looks like a straightforward change

Could you add to the test plan case, when you first apply this diff and then log in? (I remember this was a tricky case when implementing the first version)

Should we also update the docker-compose.yml to use the new port?

Might be overthinking this, so feel free to push back, but I think we can still use prevState with the useState hook

Thanks for breaking down this diff! It is super clear what the changes are!!

There are so many issues here. I don't think we can proceed with this approach, especially given @patryk's limited time left at Comm.

See comments in D9007. Given @patryk's limited time left on Comm, I think we need to abandon this approach

At some point we'll probably want to think about how uploads might work in the background. If the backup is large, I could imagine that the client would need background upload in order to complete the upload. Is there a task to track this?

rebase and land

@kamil, would you be interested in commandeering this revision?

I assume this work is necessary for the keyserver to be able to connect to the identity service. @varun, is that right? If so, I think you'll need to commandeer it.

ENG-4920

I removed copy paste between search on web and native. I will create a followup task to use this function in pinned messages, because it seems to me that this logic wan be used there as well.

Use isComposableMessageType

Requesting review, because I ended up extracting a lot of common code to lib. This is code that takes messages returned from messageListData and filters them to just include the messages we initaily fetched from the search endpoint