In retrospect I should hold off on landing this until D7453 is shipped to clients first. It only affects user registration and we can assume they will be using newer client versions, but we should still wait until it actually ships before landing this, in order to avoid blocking keyserver deploy

Add code comment

1. Update to use updateThread utility so that updates are correctly created for all clients
2. Only reset thread names to the empty string if they are for SIWE users. For other users it won't affect behavior on new clients, but will break old clients

Talked with this offline with @ginsu and we concluded that EditAvatar is being overloaded and doing two things instead of one. We concluded we're going to split this component and EmojiAvatarCreation into two components

Thanks for explaining @marcin! To your queue for folly::Optional<std::string>

Just added Ginsu to Dropbox

Not sure familiar with this stuff – would be great if @atul could take a look

Please address inline comments before landing!

I should either:

Having identity service be aware of the "websocket payload", also couples identity service to being aware of the websocket implementation. Which would mean that the client messages would need to reside in a shared location (not necessarily a bad thing, but it is an implication of making the messages opaque).

Sorry yeah I didn't actually check!! Looks like it's just the unit test failure

Bye bye

It's cool how the ThreadAvatar / ChildAvatar is a child of EditAvatar

Our messages got crossed when you re-requested review I think, passing back to you for my more recent message where I discuss tradeoffs

My proposal: single TunnelbrokerService with a single RPC that takes targetDeviceID and generic message (API will probably expand in the future though)

Can you explain a little bit more these two decisions:

@atul is rather busy right now and probably won't be able to review anytime soon, but if I recall correctly I think he was the original architect of the message ops, so would be good for him to take a pass here

Didn't review too closely since it looks like just a "factor out" diff. Please wait for CI to pass before landing

Does nothing actually use this component? Usually we'd have to update some import paths as well

S3 now defaults to virtual bucket addressing, which is not supported by localstack

In D7382#220558, @rohan wrote:

In D7382#220270, @ashoat wrote:

Also ESLint errors are concerning, we should get those resolved

Will do - ran yarn eslint:fix web/ for each of the diffs in this stack, so the ESLint errors should be resolved in the updates (I'll double check this once I put up the revisions)

Still seeing ESLint issues. Might be good to make sure you're able to confirm locally that all ESLint issues are resolved before updating the diff again

The issues with threads started from images was more complicated than I realized.

I would have included this in D7402. It's hard to understand the need for this function (vs. the existing hash function approach) without reading your comment here. In general I think small utility functions like this should be introduced alongside their callsite, to make it easier for the reviewer to understand why / how they're being introduced. A good rule of thumb (not a hard rule) is whether you have unit tests for it.

New dependency looks good!! 1.2k stars on GitHub, updated in the last month, and MIT-licensed

Also ESLint errors are concerning, we should get those resolved

It's hard to know how to review this diff when we don't know how the types will be used. Is it possible to combine this diff with another one that uses the types?

On the prod it might be a lot slower - should we display a spinner or something? How would the UI look if messages are being fetched?