rebase and land

rebase and land

Rest of the comments were discussed on Comm

(Really great to see we're adding DB tests right off the bat)

Did not review this closely

I'm sorry, I completely missed that it was an old migration. My apologies for making assumptions and leaving an unnecessarily aggressive comment

On context on why this diff has been up for 2 weeks and hasn't been reviewed?

Note that I didn't bother adding a line here because @commapp/opaque-ke-wasm isn't actually consumed directly via Yarn workspaces, so we don't need its package.json in order to run yarn cleaninstall. Instead, we'll consume published versions of @commapp/opaque-ke-wasm as an NPM package.

A little out my expertise for best practcies, but looks good

In D6924#212240, @tomek wrote:

In D6924#211911, @rohan wrote:

Ah I understand now, sorry. Yeah you're right, those are the three things we want to display client side.

1. Robotext: Will be handled by introducing a new message type and spec
2. Pin indicator: I think this is the one I'm a little unsure on since I've not begun working on the client-side yet so I wasn't sure on the best way to handle this. I'm not sure if updating RawMessageInfo to support something like RawPinnedMessageInfo and MessageInfo to support PinnedMessageInfo is the best way
3. A list of pinned messages: D7110 and D7112 should handle this, I can call the endpoint to retrieve all of the pinned messages for a given thread.

1. Makes sense!
2. We should spend some time thinking about it as it might affect the backend side. We have a lot of options, but most of them aren't good. Especially, we should consider how are we going to inform client A that a message was pinned on client B.
3. Here we also have some decisions to make:
   1. Do we plan to fetch pinned messages every time a user opens pinned messages view?
   2. Do we plan to fetch all the messages at once or we're going to fetch them while scrolling?
   3. Do we plan to have a couple of pinned messages on client and fetch more if necessary?
   4. Do we plan to update a view when a new message got pinned on other client?
   5. Do we plan to display pinned messages optimistically (so when a user pins a message and opens the view, should we display a message as pinned before server saves the pin)?

Answering these is crucial because it affects how the API looks like. We probably should prefer simplifying the solution but it still requires being sure what the requirements are.

Make response FetchPinnedMessagesResult mandatory

Planning changes to avoid putting it on reviewer's queue until the discussion in the comments is resolved

Return an emptyArray of pinnedMessages instead of null if there are none (feedback from D7112)

Do you think we can get rid of these alerts now? Having to click through the alerts is kind of getting annoying on iOS Simulator.

memoize MessageTooltipButtonAvatar

address comments

Addressed some of the comments

you almost certainly need to be looking at threadInfoFromRawThreadInfo.

Rebase on master

feedback

ran -> run

Important changes for media files permission and ability to launch MainActivity from SplachActivity

add import, improve query format