Can you add this diff to the stack?

Could you create a task, to after fully migrating Identitiy client to the worker to deprecate opaque on the main thread?

In D11312#326574, @kamil wrote:

Can you link the diff where you update parsing prekeys when creating a session and land those two together? Now it's not possible to create a session between two native devices.

Can you link the diff where you update parsing prekeys when creating a session and land those two together? Now it's not possible to create a session between two native devices.

Do we have some alternatives to detect that secondary device auth succeded other than isAuthorized from Tunnelbroker? Wondering if this is the best approach

Putting back to your queue to address threadHash type

Please fix Android build before landing

Make sure Android build passes before landing

Looks good, there is one problem with thread_hash type - but let's discuss this in D11247 and then you can just update the type here

flow check. Not sure how to best test this right now. Might need to test later in diff stack

In D11287#326127, @will wrote:

The reduceIntegrityStore function starts with:

if (
  action.type === logInActionTypes.success ||
  action.type === siweAuthActionTypes.success ||
  action.type === keyserverRegisterActionTypes.success ||
  action.type === fullStateSyncActionType ||
  (action.type === setClientDBStoreActionType &&
    !!action.payload.threadStore &&
    state.threadHashingStatus !== 'completed')
) {
  return { threadHashes: {}, threadHashingStatus: 'starting' };
} else if (action.type === keyserverAuthActionTypes.success) {
  return { ...state, threadHashingStatus: 'starting' };
}

These currently just return either the current state or an empty threadHashes object. Do we have to refactor this in anyway with sqlite ops or is it fine as is?

Looks good but when landing you could comment in ENG-7198 to use olmAPI here - or if the olmAPI is ready at the time of landing, use it here.

@michal is moving the Identity client to worker now so should review this code as well

Looks good, just requesting changes to address my and @ashoat's comments

@tomek is off - going to request changes to clear our queues until he's back and able to respond to the question

In D11275#325678, @ashoat wrote:

Thanks for explaining that it would require weaker types and some any-casts. I'm curious what the other reviewers think about the two proposed approaches, and I'm also curious how expensive it might be to change the approach at this time.

The reason the differences exist in this revision of this diff is that I wanted to use the same opaqueURL for both tab-JS-context and webworker-JS-context. But the corresponding JS files for these context are hosted in different places and so have different default origins for network calls.

In D11259#325290, @inka wrote:

Can you explain why we don't want to persist ops? Wouldn't it be a problem if redux store got updated, but the app was closed before ops had the time to update the db?

Could you please form the stack with your diffs?