Address review

Address review. I opted for returning single MessageData instead of {[id: string]: MessageData}.

Make mergeUserToCollapsableInfo pure.

Move notification sending logic to peer-to-peer-context

Update queueDBOps to queue notificationsCreationData

Remove logic in db-ops-handler

In D13131#371051, @ashoat wrote:

1. Are there any other APNs fields that we need to surface outside of the encrypted blob like this? For instance, how about priority?

Sound was the only one. The priority field is not a part of notification but a part of headers of HTTP request to APNS which are never encrypted.

2. Do we have a similar problem with other encrypted notifs, such as the FCM ones we use for Android?

No, we don't send notification sound on Android. It is set locally on when notifications channel is first created. See here. createChannel implementation is in native code here. It does not mention sound but according to documentation notifications sent to this channel will make sound since its importance is HIGH. The value of this sound is some default set by the system. User can change it in settings.

Reorder the stack

Reorder teh stack

1. Reorder the stack
2. Change messageDataFromDMOp to notificationsCreationData.

Reorder the stack

Reorder the stack

Update stack order

Reflect changes in parent differential

Make method to return message data optional

Handle windows

Rebase before landing

Robust solution

In D13119#370310, @kamil wrote:

Shouldn't we update all usages of isDesktopSafari that could be affected, e.g. in getCryptoKeyPersistentForm?

Rebase before landing

Fix patch

Address Kamil review

Rebase before landing

Rebase before landing

Add db ops store action to schedule notifications creation and sending. Make db ops reducer aware of this new action

Extract notificationsCreationData as separate DBOpsEntry type

In D13023#368365, @ashoat wrote:

Ideally all three should match up. See my most recent comment

In D13023#368353, @ashoat wrote:

Need a deeper explanation. I think we should merge the codepaths

In D13023#368350, @ashoat wrote:

I saw that comment. All it does it link to some code on GitHub on comment. I don't understand how it explains something, and especially don't understand how it responds to my comment above

In D13023#368342, @ashoat wrote:

Why is the approach for constructing MessageData for notifs different than the approach for constructing RawMessageInfos above?

For instance, we use firstLine in one but not the other.

I strongly suspect it needs to be unified. RawMessageInfos can be constructed from MessageDatas. We should not maintain two duplicate codepaths.

Add comment explaining hacky pattern

Rebase before landing

Fix ESLint

Use context in peer-list-hooks.js

Fix CI

Fix CI

Fix CI

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

Rebase before landing

1. Address review
2. Rebase before landing

In D12836#366647, @ashoat wrote:

It sounds like you're saying the minified bundle is not used at all. If that's the case, why would it lead to backwards compatibility issues?

Perhaps I miscommunicated. I meant the case that the patch will fail to apply to bundle from updated version due to some conflicts. I don't expect them for source since I am just adding new functions but I wasn't sure hot it works for minified code. @tomek
told me that he would expect minified bundle to behave similarly as normal code.

In D12836#366502, @ashoat wrote:

Thanks for explaining your reasoning! It's a big patch, but I think the approach is okay. I'm guessing you tested on both native and web and confirmed that the changes to the minified bundle were necessary on web, and the changes to the source was necessary for native? (Or perhaps you kept those changes to make it easier for a reader to review)

In D12673#366496, @ashoat wrote:

Thanks @marcin! Can you link the diff where the context is used? Appreciate your explanation above!

Update types and bring patch back

In D12836#363503, @ashoat wrote:

Even if we don't use localforage in our code outside of web, this patch probably affects some transitive dependencies for other projects. It looks like it's backwards-compatible, so it should be safe. But we may face some trouble at a later point if a transitive dependency upgrades its version, depending on which package Yarn hoists to the workspace root, and how patch-package handles it when multiple versions of a package are present (does it patch all of them, or only the one at the workspace root?)