In D6897#205149, @atul wrote:

We could probably just have a function getOlmUtility that returns a Promise that does lines 345 and 346 here, and caches the result.

I'll need to make sure there that await olm.init(); is "idempotent" and there aren't any issues with calling it multiple times. Just want to make sure in the case where the keyserver gets multiple siwe_auth requests at the same time that calling await olm.init() simultaneously/multiple times doesn't break anything.

Please make the requested edit before landing. Otherwise Flow types look good, but defer to others on Rust

Awesome!! I thought you had earlier indicated that a parentheses was necessary, but either way it sounds like now you’re in agreement with that StackOverflow post about the ORDER BY / LIMIT.

Nice! After this verification step, we should then JSON.parse(signedIdentityKeysBlob.payload) and run the result through an input validator. Then we'll be ready to store them in the DB. (Assume that's for a later diff, though.)

PS looks like a missing screenshot in the Test Plan.

Nice!!

I spent some time reading through this and I understand how it works now. @ginsu wanted to catch the ref just as it was set, so he made a useEffect that would trigger immediately after renderEmojiKeyboard flips, which as it turns out will trigger the rendering of the emoji keyboard. He got this idea from the article he linked earlier.

Moving forward, if I run into situations where I am submitting code that is not an obviously clear solution, I will be sure to annote with comments with my rationale-- something that I can work on. This should require me think more critically of my solutions, learn better, and offer more context for my reviewer.

It looks like you're adding support for sending push notifs, but support is still missing for rescinds and for updateBadgeCount. Rescinds may be hard but updateBadgeCount should be easy.

Perfect! Love the small extra improvements you made

Permission checks query seems good. Can you amend the Test Plan to mention how you tested them?

Good catch @inka!!

Accepting to unblock, but would be great if we could avoid Object for new code. Not sure how easy it is to avoid here and whether the type there is predictable from whatever API we are getting it from

Please only land if you can confirm that the ORDER BY and LIMIT apply to the whole query, not just the second half

It might be for backwards compatibility, or maybe just for convenience of accessing. The idea of getConstants() is that it's called once by the module at initialization, so actually I think calling it directly might also have some nuanced differences if there is some stateful code there

@ginsu, strongly encourage you to be more critical of yourself before submitting code in the future. This pattern of submitting code you feel like might be "good enough" to sneak past review leads to wasted time for both you and your reviewers. You should hold yourself to a higher standard – it will help you learn better, and it will save you time.

This seems like it would've been a great time to introduce a shared library instead of copy-pasting. I understand there is a monthly goal at play here, but how long does it really take to set up a shared library? In JavaScript it can be done in ~15min, but I'm not as familiar with Rust

Why are we using Modal though? Should we just update MultimediaModal to look like those designs?

Accepting to unblock, but a little confused since I don't see the keyserver side

Nice, glad you're persisting this

Accepting to unblock, but not clear why we're sending primaryIdentityPublicKey up twice

EDIT – never mind, I see this is addressed later in the stack

Had a thought here – we should update our sanitization code to sanitize these public keys, as they are user-identifiable. Can you create a task for that and link here before landing? (Or a diff)

Just some nits

You need to do more than just add async. I don't think you have a full understanding of async/await here

I tested the types and they're good. Did not test the actual bindings but I assume @max did

Fix Flow types and remove .default

Okay, just make sure you did this part of the Test Plan so that all constants are included:

Otherwise there's no way to relate a nonce to an on-going exchange. Unless I'm missing something.

@atul and I had to deal with the same question when designing this on the keyserver side. General conclusion is that it probably isn't super important to associate a nonce with a specific session in this specific case.

Memoization is perfect! Almost done here, just an issue with the index

Perfect!!

I have no idea how to interpret this syntax... maybe @jon knows or can get up-to-speed on it?

It looks great, but I think this should be two or three diffs:

Can you add a screenshot to the Test Plan?

Confused why this needs to be a React component

Copy seems fine, defer to you on Yes/No vs. Cancel/Log out

Resigning to avoid removing from reviewer's queue, but feel free to re-add me later

Memoization confusion continues to abound. The current approach is simply not working... you can't continue to "guess and check". It's not a good use of my time and not a good use of your time.

Can you send a message to the UX Team chat? I don’t think Ted is fully aware of Dave’s inflight work on colors.js. I don’t think Dave has colors for this new entry in his recent themes. cc @atul

Aren't we missing "FETCH_RESULT_NO_DATA", "FETCH_RESULT_NEW_DATA", "FETCH_RESULT_FAILED"? Source here

Great work finding the right utilities in the Olm library!!