I think it would be easier to make the requested change RE keyserverID and follow up with questions you might have for me separately.

For now, I renamed them all deviceEd25519PublicKey as I think that was the goal initially

signingPublicKey -> deviceEd25519PublicKey

Fix refreshPreKeys message. response -> upload

Please remove the conditional before landing (it doesn't do anything)

@kuba can you reach out to Ted on the design team regarding this? Design above looks weird, I would at the least swap the order of the two

Got it, I think it's okay to have both. Up to you

I'm also asking for consistent naming of the ed25519 primary device public key

My personal inclination is to remove the duplication, and just parse of the keys, as we should be validating the IdentityKey payload anyway.

I think this diff would be easier to review if you included this new function's usage in the same diff

I think this diff would be easier to review if you included this new function's usage in the same diff

Cool, glad it never reached prod. Don't care about Redux vs. MySQL consistency (personally)

Mostly requesting changes to get rid of the keyserverID concept

Mostly requesting changes to revise this API to get rid of all streams for gRPC-web compatibility, but see inline comments

Split opaque RPCs into two unary RPCs

Correct KeyserverKeysResponse structure

Limit diff to just account actions

In D7017#209165, @michal wrote:

Can you check what it looks like with the "Delivery failed. RETRY?" text which appears when sending a message, and attach a screenshot? Not sure if this case was considered in the designs.

Is it possible we'll want to add some metadata to the content field later? I think it would be safer to use JSON

This is fine, but in order to unblock ENS-3302 we need to get to the point where we're actually rendering images here I think

reabase

there is more crypto-relatud stuff, making names more exact to easily distinguish

Check if database result is not empty

• update type
• add message type to error message

• update type
• update worker path
• add check

Change order

Looks ok - it doesn't seem necessary to do a migration.

Good point, I've added a check that makes sure that the timer doesn't already exist before creating a new one

Rebase

Can you check what it looks like with the "Delivery failed. RETRY?" text which appears when sending a message, and attach a screenshot? Not sure if this case was considered in the designs.

Looks good to me, but I haven't worked with this code so it would be nice if someone else could also take a look.

Revert accidental changes

• Rebase
• Added new tests

• Rebase on new types
• Address review feedback
  • Used consistent naming for ciphertext, sealed data etc.

Add comment explaining even release pattern

Address code review feedback

Address code review feedback

Address code review feedback