rebase and land

address feedback

address feedback

This revision should be closed since this bug was fixed in D6851 and D6845

Aligned 'Delivery failed' notice to the message label. Only for the right side, because we can't get delivery failed on the left side.

I'm not sure if it is the case. For now, displaying both 'delivery failed' and the label ('Edited') at the same time is impossible.

That looks correct!

I'm going to leave both for now.

I'm not sure if it is the case. For now, displaying both 'delivery failed' and the label ('Edited') at the same time is impossible.

Oh yeah, that makes sense, sorry!

In D6963#209536, @tomek wrote:

The proper way of testing older clients involves running an older client in prod mode (so that it won't get hot reloaded when we update the code version), then checking out the newest code, and running the server with this code. In this case we can consider a simplified approach: the thing which interests us the most is if the server sends an original message or the shimmed version. To test that we can run a client and set code version in the condition on the keyserver. If the client's version is higher than server's, we should receive an original message. Otherwise, it should be the shimmed one.

Changed minCodeVersion for messageShimming

In D6963#209487, @kuba wrote:

I don't know how to test message shimming yet, so for now it isn't tested.

I don't know how to test message shimming yet, so for now it isn't tested.

Added shimming message info, changed content to JSON format.

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!

yeah let's de-dupe and remove deviceEd25519PublicKey. one other nit inline

Use username or wallet ID for looking up keyserver info

Got no response to this one, requesting changes again

Use userID to find KeyserverInfo

Cool! My feedback now is that deviceEd25519PublicKey should be removed to dedup, but I think @jon is waiting on @varun to confirm before making that change

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