Update to 3.2.14; respond to review

Are we still waiting on D6924 before the rest of the stack is ready for review? Back to your queue for now, feel free to re-request review as-is if I should be reviewing it.

Are we still waiting on D6924 before the rest of the stack is ready for review? Back to your queue for now, feel free to re-request review as-is if I should be reviewing it.

I'm going to wait until the architecture of pinned_messages is decided in D6924 before requesting review, I just put this up so I could continue working locally.

Unit tests will be added in next diff.

Accepting since a lot of the feedback was captured in the iOS diffs.

rebase and land

I agree with @varun

In D7020#208568, @varun wrote:

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.

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.