remove if then and just return

address feedback

rebase and land

rebase and land

Looks good! Thanks for linking to the Linear issue and jotting down detailed notes there.

Nice, glad we could cut code and make it simpler with the combined initializer

Regarding all naming issues (applies to the whole stack), I've created a Notion doc that clarifies the names

Sweet, thanks for addressing those comments

Thanks for including these tests!

fix..

If we're fully deprecating non-Nix workflow we can probably add cmake-lint to Nix and bring back this diff?

update after fix + rebase

fix signedIdentityKeysBlobSelector after testing

with the data URI I don't think it really matters

Thanks for including unit tests

Some questions inline

rebase and land

See if ClientClientResponse for serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB is correctly constructed and received by keyserver.

land

See if ClientClientResponse for serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB is properly constructed and received by keyserver.

include call to commCoreModule.initializeCryptoAccount(...)

rebase and land

Haven't done this yet, will test before landing.

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

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.

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

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

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