Can you decompose into three effects?

Good call

Also update mariadb-up-mac.nix

Successfully tested this:

We actually want a 256-bit key. I think @anunay is in the process of updating that

Accepting since my comments are minor, but if you disagree feel free to re-request review

I won't block this diff on it, but I think we should strive to have correct types. invariants can feel messy, but I think they are better than having incorrect types

Can we use any random string as an AES-256 key? Or are there some additional requirements?

D8751 has been landed now, so it should be easier to dedup :)

We already pass all actions to a hook (even in class components, we use useServerCall) so I imagine there is some way to do it. But I won't insist

Ah sorry, I misunderstood!

The UX change doesn't seem particularly bad to me, but I'd like to understand if the approach you're using here (deleting the old notif) is similar to the approaches that other encrypted apps take. Is there no way to set a "collapse ID" from the NSE?

I agree that it would be good to migrate away from the Reanimated 1 API... given it's deprecated in Reanimated 3, we'll eventually need to migrate there anyways. Looking at animateTowards though, it seems fairly complicated... I don't think it makes sense to block @atul's work here on transforming that to the new Reanimated API. We'll probably need to have the Reanimated conversion be a monthly goal for someone...

I'm asking specifically about the health check. It's my understanding that the WebSocket protocol does not have any built-in health checks. Given we're using the Node.js ws library directly on the keyserver side, it seems like we'll either need to switch to using a compatible (Rust-based?) client, OR we'll need to do some additional work on the keyserver to implement this health check. Is that accurate?

Nice, forgot I had already done some of this work!

Awesome that we get the health check for free! I assume we'll need to implement something on the client for that to work, yes? The Tunnelbroker client in keyserver currently uses the ws library for Node.js

I wonder if it would be possible to rewrite this to use React hooks instead of createSelector. I believe that all uses of createSelector can be replaced by React.useMemo. The selector funcs passed to createSelector turn into dep lists. React hooks are more modern idioms than createSelector, but I'm not sure as to all of the tradeoffs.

Can we dedup this with the existing getOneTimeKeyValues? Looks like D8751 moves it around.

I think the reason is that ChatContextProvider renders dummy nodes for height measurement, and now those dummy nodes need navigation state since they might be rendering a link to a chat

Thank you!!

1. I think we should implement a separate reducer for this. We should expect that the access token will need to be cleared for a log out, account deletion, and session invalidation. For an example, see here
2. I think the reducer should be in lib, since this action will be shared with web. I think it should be possible to submit this diff purely on lib, without touching native or web
3. Please keep in mind that we will also need this info to be in CommSecureStore for @marcin's purposes, since he needs to be able to access it from native code (and NSE in particular)

Nice!! Some nonstandard stuff in this diff; requesting changes in the hopes that we can use the more standard mechanisms

Ah, my bad. It looks like @atul is right... this change would have been marginally beneficial. Sorry @ginsu!

Looking at the code of our Olm fork, it looks like the only effect of calling mark_prekey_as_published() is on the result of calling unpublished_prekey(). The only place we check unpublished_prekey is in the above code, where we use it to make sure that we don't throw away an old prekey before the newer prekey is published.

JS looks good, but I don't know Rust so couldn't review that part

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?

@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.

@kamil, would you mind commandeering this revision?

@kamil, would you mind commandeering this revision?

@kamil, would you mind commandeering this revision?

I don't love how we're mixing modal and panel families here. I know they are separate files, but it still feels like a violation of the design system (unless I'm missing something?)

Should this be abandoned? Wondering why it's been up for 2 weeks without an update

@kamil, would you mind taking over this diff, addressing my inline comment, and landing it?

Resigning to avoid blocking while I'm out

Skipping request changes to avoid blocking this diff while I'm out

I won't request changes since I'm about to go out-of-office, but my instinct is that the last revision was a step backwards. Open to landing this if both @marcin and @tomek disagree and think that the changes are definitely correct. Perhaps I'm missing something

Ah yeah my bad!

Please address or respond to my comment before landing!

Note that you don't need useStyles for something that doesn't use colors. In that case you could use StyleSheet.create directly

Makes sense, but the comment seems confusing

Thanks for breaking this out into a separate diff!

Mostly nits and minor requests