i frankly don't think this adds much clutter at all... also it's more tedious for me to switch between diffs to see how these dependencies are being used. just looking at this diff, i have no idea what any of these dependencies are for besides the one that @jon annotated, and even then i still have to look at another diff to see what handle_pake_to_grpc_err looks like. the lack of context in this diff makes it difficult to determine if a given dependency is appropriate or propose an alternative.

so that a reviewer can have a more focused context when reviewing

i don't love adding the dependencies in a separate diff, would like to see them added when they're actually being used

Going to go to a more OOP-like approach instead of some "static methods". Following https://github.com/marucjmar/opaque-wasm as an example of more ergonomic JS bindings.

Rebase on master

Address feedback:

• clarify service comment
• Make LoginPasswordUser into stream, and finalize OPAQUE
• Remove GetUserID (at least for now, until we have a use case)
• signingPublicKey -> deviceEd25519PublicKey
• align opaque message with opaque_ke terms

looks fine to me, not going to accept so that atul can take a look as he's probably more familar with mac workflow.

grpc -> gRPC

Abandoned in favour of D7032

Abandoned in favour of D7032

rebase, update const

rebase, make type read-only

Previous types were too general (string instead of current algorithm names). I've updated this to be more precise (like D7023) but with specific types for the entire module - not only AES algorithms.

improve types and move to flow-typed

I'll add a test for the correct key, but the malformed ciphertext

i don't love adding the dependencies in a separate diff, would like to see them added when they're actually being used

Changed flow-typed -> Flow as suggested

UpdateUser -> UpdateUserPassword
Add comment on rpcs
Use a single "Empty" message instead of rpc specific versions

Some questions inline. Definitely feel free to re-request review if there's something I'm missing.

I pulled this from the version of the types in node_modules. Will try to make those improvements, with exceptions for any methods that might not exist in this older version of Olm (I think you're looking at master, which I linked above)

Noted some inconsistencies with the TypeScript types. Feel free to re-request review if the omissions were intentional.

Some questions inline. Definitely feel free to re-request review if there's something I'm missing.

JK, I shouldn't have just searched yarn build... should've considered that yarn scripts can be invoked via yarn workspace blah command.

Ah, but we probably DO want yarn build on prod. As @varun said:

Did we make sure this passed keyserver Docker build before landing?

Left a note about the error-handling on the Swift side, definitely let me know if there's something I'm missing. I think we should just be able to match what we're doing on the Android/Kotlin side?

Did we make sure this passed keyserver Docker build before landing? Just want to make that sure that running build:debug before we run build doesn't break build (doubt it)

(To your queue and off my mine while you figure things out with @kamil)

Oops, This is a duplicate of D6994 - I'll sync with @kamil and we'll decide what to do

don't install ci-deps for non-debug

• Updated diff description
• Added CI
• Removed lint-staged for desktop and native > On native we have only one dummy test which is failing

Not an expert in C++ but your code follows the pattern I used when writing the C++ message spec for reactions. Would be helpful to get a second pair of eyes here

fix yarn build:debug to include install-ci-deps step

I think we should consider if we also need shimUnsupportedMessageInfo and unshimMessageInfo. These functions will help us support older native clients that haven't been updated yet.

This is more related to this task: https://linear.app/comm/issue/ENG-2712/we-dont-run-tests-in-web-and-native-in-precommit-hook
So I'd rather do that when adding the hook

Now that they're working, can we update this diff to include them in CI?

Accepting, but if what I suggested doesn't take too long might be worthwhile to update