With the red border, is that a parent component of the message box? (Generally I would expect the parent component to enclose the child component.)

Should I decrease the width of the inner message (the chat bubble that is sticking out), or should we increase the width of the message box of the composed message (currently has the red border around it)? I personally think there is still enough space on the right side to just increase the width of the message box, but if we think it would be better to decrease the width of the inner message to fit inside the message box lmk

Have you made sure that that the height measurement code is still working correctly?

thanks for doing this!

In D6993#209859, @tomek wrote:

Do we know how this diff corresponds to https://linear.app/comm/issue/ENG-3322/fix-stale-cache-error-for-olmwasm#comment-d1aabe3d? Maybe this will somehow improve the experience about the path's configuration?

In D7058#209899, @ashoat wrote:

Why hasn't this been landed? It's an urgent issue and the diff was accepted on Monday...

In D6921#209900, @ashoat wrote:

Why hasn't this been landed? As mentioned on Monday, we need to create a release with these changes ASAP so we can test the before the end of the month...

Rebase before landing. Add check for code version

Rebase before landing. Extract thread ID key to constant

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Why hasn't this been landed? As mentioned on Monday, we need to create a release with these changes ASAP so we can test the before the end of the month...

Why hasn't this been landed? It's an urgent issue and the diff was accepted on Monday...

Do we know how this diff corresponds to https://linear.app/comm/issue/ENG-3322/fix-stale-cache-error-for-olmwasm#comment-d1aabe3d? Maybe this will somehow improve the experience about the path's configuration?

Generally, the code itself looks good to me. But I have a general note regarding naming conventions.
I haven't seen all call sites yet (only the key generation diff is up) so I can't really tell but maybe it's worth revisiting the types and function arguments to have this as clean and consistent as possible.
In my diffs regarding AES encryption, I defined a few naming rules which I stick to (you can find them in this Notion doc). You can take inspiration from them.

I might move this code into shared/comm-opaque2, so that we can retain the opaque 1.2 Cipher definition as it is now and avoid having to tackle the migration immediately. Once we trigger the migration, we can just replace the 1.2 code once we are ready to migrate over to opaque 2.0.

FYI @kamil, another thing we'll need to move to SQLite

Will this potentially affect the width of the chat bubbles? Have you made sure that that the height measurement code is still working correctly? (Are any seeing any of these errors?)

Can you share an updated screenshot?

Not going tackle updating to 2.0 in this diff, as all downstream usages of comm-opaque::Cipher (which is currently the entire code base) will need to be updated as well.

Expose facade as OOP

Works on dev. On prod I get invalid_parameters on the keyserver but I think that's because it's expecting web.comm.app

Would be good to quickly make sure login/SIWE on web continue to work as expected

Will wait on docker keyserver build CI before landing

(back to your queue pending changes)

address feedback

move promise earlier