I'm not sure about the logic here. PushNotificationsHandler contains an effect reacting to prevLocalToken.current && !localToken condition. It also renders useCreateDesktopPushSubscription which contains an effect reacting to the same condition. Can't we have a single effect doing all the work?

Delay pruning

Generate a timestamp when putting operations to the queue

In D12954#366380, @inka wrote:

I'm worried about a scenario where the user doesn't open the app for a couple of days, and when they do all ops are suddenly deleted before they can be processed. Are we protected against that somehow?

Rebase

Revert validators change

Set unread status and create a custom changes field

Agree that it would be a lot better to extract the logic from the specs. I'm going to think about it more but at this point, it seems hard because:

1. Updating the replies count happens through an update. If we extract the logic from the specs, we would need to inspect returned updates and modify or create a new one with the replies count update.
2. Messages can be returned both in rawMessageInfos and as a part of some updateInfos.

There are some possible ideas, e.g.

1. We can consider returning something different than rawMessageInfos and updateInfos from the specs, so that it's easier to know if the count should be updated.
2. We can start updating the count using a separate action and return a new count next to rawMessageInfos and updateInfos.
3. We can modify reducers to compute the replies count based on new messages automatically.

Each of these could be complicated, and it seems they mostly move complexity from one place to another.

Create a message even when a user is already a member

Add community field

In D12914#366368, @inka wrote:

In D12914#366270, @tomek wrote:

What about +community?: ?string, field?

I got a little confused here. But I think that communities are always thin because they live on keyservers. So for a thick thread, it is not possible to assign a community. Am I right?

createThickRawThreadInfo returns MutableThickRawThreadInfo which includes a community field. I am also confused why that is, but it is types as +community?: ?string,, so I am assuming it can hold some value. If so, we should be able to set it

In D12948#366063, @ashoat wrote:

I had previously suggested implemented a solution to this based on a tcomb validator. We'll need to specify IDs that have to be checked for collision again certain SQLite tables, and I was planning on using a tcomb validator approach for that. It seems like checking IDs for existence in certain SQLite tables is a very similar problem, and ought to be solved in a similar way.

In D12881#366124, @inka wrote:

Should we set the unread status?

What about +community?: ?string, field?

I got a little confused here. But I think that communities are always thin because they live on keyservers. So for a thick thread, it is not possible to assign a community. Am I right?

In D12941#365887, @inka wrote:

Rename file - I am not sure how to name this, but this seems better

About option 1 vs option 2: I think it is much worse if we have a false-negative token invalidation than a false-positive.
False-positive means that we think that a token is invalid when it is valid. In this case, we would ask a client to send a new token. If we have a good validation of notifications on Tunnelbroker, then it is unlikely to cause serious issues.
False-negative means that we think that a token is valid when it isn't. We won't be able to send any notif and don't have a way of recovering from it.

Change the API

Fix the types

Fix imports

Fix imports

Fix imports

Extract common logic

Correctly handle sidebars

Delete sidebar only if it doesn't have a parent

Add all the thread to the utils

Add all threads to utils

Add a new member

Add new users

Create a new thread

Include new messages in thread creation join update

Update unread status

Create new thread

Create a validator

Looks ok to me, but we need to make sure @ashoat will take a look before landing

Use UUID v4

Rebase and improve naming

In D12786#362267, @kamil wrote:

I think the usage of if and dmOpID can be improved and more descriptive, this might look confusing as we have plenty IDs all over the codebase - but I don't have idea about better ones

Fix device ID filtering

Filter out this device ID

Rename

Rename

Rename

Rename

Rename

Rename

Rename

Rename