Thanks for linking – I guess I was probably thinking of the 32-bit archs, which don't need to be supported.

(There are no reviewers specified)

Can you link to where you got the list from? I don't see them getting "added" to cargo-lipo in the old version of this file, perhaps it's somewhere else? To be honest I would've expected to see some other architectures on the list (doesn't Apple consider the iOS processor architecture and macOS processor architecture to be different?), but I'll be convinced if you can just link the code where you got the list from

Remove "Clean up keychain" step

Accepting, but before landing @marcin please address the two points in my last comment

1. I haven't tested my changes. Hoping @marcin can cover this
2. One point of feedback that wasn't addressed is setting the whole CryptoStore with a single action, but @marcin mentioned he has a diff up for this and will add it to the stack shortly

Revert to previous approach, address my feedback, and unset the Promise in an effect if the cryptoStore is unset

We definitely should not be defaulting to a half-baked light mode implementation, but I assume this has been considered

Wouldn't we NOT want CI-* then?

One challenge here is going to be that if eg. the Android CI pipeline is filing, then the person debugging will have to update the Android CI job.

Haven't you already forked? What's the benefit of avoiding already-complete work?

You can remove it from threadPermissions as well

Accepting, but please remove the membership permission before landing!

Can you figure out which version of React Native brings in that version of Flow? If you need pointers on that let me know. We'll need a Linear task either way, but hopefully we can make it a follow-up for the current upgrade task

This popped up while discussing QR code format with @anunay. @rohan, wondering why we encoded the AES key in this weird way, rather than just as a string (with optional encoding if necessary?)

Directionally correct, but a ton of small issues...

Regarding setting up the cors on commAppRouter - after testing it actually should to be there so that this diff can be tested. Currently the dev urlPrefix for the web app is hardcoded to localhost:300/comm (which I'm changing in D9451) and the web app uses the commAppRouter endpoints (also changed in D9451). This means that if I try to test from the subdomain.localhost:3000 the cors issues still fail. This shouldn't be a problem on normal dev setup with web app hosted on localhost (without subdomains), but in my opinion we should keep the diff as it currently is.

I see your point – I'll try to do that next time. In this case, since I'm landing these together as a stack I'm going to skip the extra work of reordering

I'm not sure if move construction is unsafe. I would actually assume it is safe. The question is whether std::vector (what we use for OlmBuffer) has a move constructor that allocates new space on the heap for the vector's data. I would assume it does not – the point of a move constructor is generally to avoid having to do that.

Does the native concept of a theme translate cleanly into the web concept? Does web have access to the "system theme" selected by the user? Does the API for accessing it mirror the native ones?

Some docs issues

Thanks!! Reminder to make sure you mention to me after you land this, so I can make the appropriate changes to keyserver/.env on my keyserver in production before deploying the changes

Making sure it pops up back in my review queue