The task from the title https://linear.app/comm/issue/ENG-536/sidebar-list-modal-re-style - is marked as done. If we decide to do something more about that issue, it would be probably easier to do it from scratch instead of figuring out how to make this stack solve the problem.

Later in the stack, it is mentioned that this is a part of https://linear.app/comm/issue/ENG-536/sidebar-list-modal-re-style - which is marked as done. If we decide to do something more about that issue, it would be probably easier to do it from scratch instead of figuring out how to make this stack solve the problem.

Rebase

Rebase

Rebase

Rename

Rename and invert a condition

Use the new approach where we have only one queue and process the ops one by one

Update queueing logic

In D11281#328131, @ashoat wrote:

After today's meeting, I wonder if we still need to add this ID to all actions

Rebase

Simplify

Simplify the action

Update the types

Keep only one queue
https://linear.app/comm/issue/ENG-7040/implement-generating-and-awaiting-processed-ops#comment-bc0834f4

This looks reasonable, but I'm wondering if we shouldn't solve this on Identity service: it knows how many keys are there, and how many keys are needed to fulfill requests, and could ask a keyserver for the appropriate number. Also, it should know that a keyserver was asked for the keys recently and can decide either to not ask for more or to ask for e.g. only one more.

Similar to Android - shouldn't we have a separate holder for each recipient?

When creating a blob, we're setting one holder for the content. Then we send the same hash and holder to multiple recipients. After the processing, the recipient schedules blob deletion which means that other recipients may be unable to download the blob - as it is already deleted.

All the comments are minor except the one about badgeOnly handling which seems confusing.

At some point we should also blacklist integrityStore on native so that it isn't persisted using redux-persist

Generate an ID if it isn't provided

Simplify reducer logic

Simplify the action

We don't need a second ID - removing the ops ID

Rebase, rename

Rebase, update Redux types

Rename, rebase

Rebase

Update types

Add a comment. Update the types.

After reading the description it sounds like

By updating memberHasAdminPowers and appendUserInfo to depend on community root roles instead of computed member.permissions, we can avoid storing/persisting/sending that data to the clients.

is the main goal. What is the impact of doing this? How much can we save?

It seems like changing the code to check permissions in communityThreadInfo is a huge amount of work. Could you explain why we have to do this and what are the consequences of not doing it?

Separate serverThreadFrozenDueToBlock and clientThreadFrozenDueToBlock

Why do we want to do that?

Can you explain more about why it's necessary to include these field on all actions?

We need to know when the processing of an action is finished. This processing consists of generating 0 or more ops and applying them on the DB. We're introducing a new store, where the ops will be put and a handler that listens for new ops, applies them on the DB, and removes them from the store.

In D11271#325677, @ashoat wrote:

Is this is a temporary hack, shouldn't we have a Linear task to revert it?