Can we just pull this outside of the function body?

Looks like a Buildkite issue: https://www.buildkitestatus.com/

Looks good to me but I'm pretty ignorant on DDB... would be great if @varun could take a look

Just noticed that VerifyUserAccessTokenRequest requires userID – does that need to be included in TBSharedConnectionInitializationMessage too?

Discussed in our 1:1 and we settled on:

Not sure if we want to do this on the identity side when someone first registers (or login) with a device, or have tunnelbroker have this information tracked separately (this is some duplication, but probably the best route forward to avoid hammering identity service).

I believe @inka introduced CommunityPicker, so she should definitely be on the review

Found some background on this: https://linear.app/comm/issue/ENG-1995#comment-210dfba5

Seems good to me (assuming it passes CI)

Looks good, but should @inka be on this diff given that MessagesResult will be used for message search as well?

Nav stuff looks fine. For more context on ReactNav Flow types, you can read this blog post

Generally agree with @atul's feedback. The ReactNav stuff looks generally good here barring the wrong ParamList being used

Looks good, but some questions about the stuff we're passing to Tunnelbroker. Separately, I don't think we should be landing the "Hello world" example parent diff

Generally looks good, but requesting changes because I don't think we should land this "Hello world" example

Seems like boilerplate

Please amend test plan to include testing Android as well as iOS.

Nice work!!

It would've been nice to combine this with the next diff so it would be easier to see how useInitialNotificationsEncryptedMessage is used. Something to consider for next time (not worth making any changes now)

Nice work!

Great work here! Mostly requesting changes to get rid of the any type. You'll also potentially need to refactor the use of fetchCallUpdateOlmAccount following my feedback in D7568

The feedback regarding the transaction remains unaddressed. I had described an approach for doing this over a week ago. You said you were going to timebox the investigation of your proposed alternative. Is this still something you want to pursue? This is blocking the rest of your stack, and I wonder how much faster we could have landed this if you took the initially proposed approach...

Please address line length issues before your next update!! This is my third time repeating this on this diff!!

Once again – please pay attention to the feedback about line length! It's not a good use of my time (or your time) to have to go back-and-forth about this. Please address it BEFORE putting up diffs in the future

I have repeatedly given you feedback about line length. Please make sure to address it BEFORE putting up diffs in the future

Please address inline feedback and fix CI before landing. Would be great if all of these new types were in avatar-types.js

Are any CMake changes necessary here? Or does it work because of a GLOB somewhere?

This pattern of passing functions directly in instead of creating aliases is always easier if you type functions that take other functions as input (like useUploadSelectedMedia here) in a more permissive way, but letting them take any function that returns anything (mixed) instead of insisting that those functions return void specifically. In this case it didn’t matter because setState functions return void (see here) but it’s still a good pattern to follow.

Please address inline comment before landing. If it doesn't make sense or you feel like I am missing something, feel free to re-request review

New dependency looks good. Not familiar with Rust

Accepting for the .proto changes. Can't exactly speak for completeness on the Rust side of things, but the changes that have been made seem okay

Please make sure you're going through your changes carefully, and not just submitting a find-replace diff. The term "identity" is used in many places, and not all of those places correspond to the notif vs. content dichotomy

Not sure it really needs to be prioritized

1. Animation in the videos

There's a lot of imperative logic in this diff having to do with isExitingEditMode. I didn't review this code very closely on the first round... looking at it now, I have some comments: