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?

This looks really hacky, but we probably don't have a clear way of doing this.

This migration wasn't already applied, right?

Do we have a task for the migration?

In D11209#324884, @atul wrote:

In D11209#324215, @tomek wrote:

However, if there is no specialRole field encountered, we will assume we're dealing with a Server/"legacy" type and fallback to sketchy string search.

What is the scenario when this can happen?

There are three places where threadHasAdminRole is encountered:

1. lib/shared/thread-utils: getAvailableThreadMemberActions()
2. lib/selectors/thread-selectors: baseOtherUsersButNoOtherAdmins()
3. keyserver/src/updaters/thread-updaters: leaveThread()

getAvailableThreadMemberActions is used in

• native/chat/settings/thread-settings-member.react.js
• web/modals/threads/members/member.react.js

Which are all expected to have the specialRole field in RoleInfos.

baseOtherUsersButNoOtherAdmins is a Redux selector that is only used on the client, where again we expect the specialRole field in RoleInfos.

leaveThread() is part of thread-updaters on the keyserver and calls threadHasAdminRole with LegacyRawThreadInfo | RawThreadInfo returned from rawThreadInfosFromServerThreadInfos. This is the scenario where we need to handle RoleInfos without the specialRole field patched in.