In D12668#366328, @ashoat wrote:

In D12668#364083, @marcin wrote:

In D12668#361448, @ashoat wrote:

In D12668#361372, @kamil wrote:

I really don't like the idea (looking at this diff and the entire stack) of passing isKeyserverSession - notification crypto module should treat all devices the same regardless of whether this is a keyserver or client device, and we should only have senderID, because the current design makes it confusing. But given this is implemented and tested I believe we can proceed, you could create a follow-up task to improve it in future but for now LGTM.

Curious for @marcin's perspective on this, and how much time it might take to fix up

It would require us to implement migration for currently existing users from KEYSERVER prefixed key schema to DEVICE prefixed key schema. I initially thought that it will be easier to skip the migration and treat session separately.

Now I think that migration might not be that hard to implement. However I am worried that treating peer-based and keyserver-based notifications the same way will force us to use the same decryption function for both. Decryption function for peer-based notifications (D12750) is complex and might have bugs. Therefore the advantage of treating them separately is that we guarantee we won't break already existing and working functionality (keyserver-based notifications).

If we skip the work of unifying this logic now, we should at least create a follow-up task to address it later.

In D12673#366331, @ashoat wrote:

In D12673#361660, @tomek wrote:

This diff looks confusing to me. We're introducing a new context PeerOlmSessionCreatorContext but it doesn't look like we're using it.

@marcin can you please respond to this? What is the point of this new PeerOlmSessionCreatorContext? Please explain things like this in diff descriptions, and please make sure you always document any offline discussions in response to diff comments on that diff.

Address review

Fix keyserver based notifs

Address unaddressed comments

Testing was executed on Safari

After discussing it with @kamil and @tomek we concluded that changes necessary to be done in this diff include:

1. Sequentially awaiting db ops processing before notifs processing.
2. Put MessageData directly in DBOpsEntry.

PR: https://github.com/marcinwasowicz/localForage/pull/1

Update yarn.lock

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Update phab

Address review

Address review

Use localforage from fork PR

Use Object.freeze for constants mapping from platform types to identity platform types. Rebase before landing

Rebase before landing

In D12900#365111, @bartek wrote:

In D12900#365033, @varun wrote:

now that we supply platform details as metadata, should we be sending the device type in the key upload at all? seems like we should just remove it? cc @bartek

Not entirely sure, but probably yes. Would be good to create a follow-up task to discuss this more.

Fix desktop notifications

1. Use query to check notifications session for multiple devices at once and initilize crypto account in send utils instead of each time before encryption. it is huge performance improvement.
2. Fix context cycle

Add additional method to check for presence of notifications session for multiple devices with one db query

Address review

Address review

Addres review

Address review

Address review

Address review

Address review

Address review

Address review

Address review

In D12692#361481, @kamil wrote:

Right now two JS threads (shared worker and service worker) can concurrently modify the same key in IndexedDB. I think to make it safe we should use transactions to make sure this is safe.

Unfortunately, looks like locaforage is not supporting this: https://github.com/localForage/localForage/issues/582 and https://github.com/localForage/localForage/issues/17.

Could you do some research about whether it's safe or suggest an alternative solution?

(this could change most of the code so not reviewing details of this diff)

About to create fork with PR shortly

In D12677#361397, @bartek wrote:

The HTTP request-response logic looks good; it's analogous to the existing Blob GET request logic.

Accepting but please remember to fix that semicolon. Otherwise, release builds will fail.

In D12668#361448, @ashoat wrote:

In D12668#361372, @kamil wrote:

I really don't like the idea (looking at this diff and the entire stack) of passing isKeyserverSession - notification crypto module should treat all devices the same regardless of whether this is a keyserver or client device, and we should only have senderID, because the current design makes it confusing. But given this is implemented and tested I believe we can proceed, you could create a follow-up task to improve it in future but for now LGTM.

Curious for @marcin's perspective on this, and how much time it might take to fix up

Rebase

Use common C++ implementation on Android. It was tested the same way as iOS using latest staging Tunnelbroker release

Rebase

Use the API in send-utils

Make encryptNotification a part of olmAPI. This change is ESSENTIAL on web since it makes encryptNotification run on shared worker. This enables us to deterministically handle race conditions.

Improvement: use the same functions to fetch and persist olm data regardless of notification type (keyserver/peer device)

Use transactional write when creating outbound session

A couple of changes

If the patch file appears cumbersome to review I will create fork of localforage with PR containing those changes.

Rebase before landing

Rebase before landing

Rebase before landing

Log information about notification encryption failure regardless of user staff member status.

Remove TODO

Fix race condition by exposing olm session creation via context