This part modelled after createPendingThread

Cast as { ...ThickRawThreadInfo } to get rid of read-only

The only await necessary. I think we will need to query SQLite here

The caller will have a try-catch around calls around processDMOperation. If we fail to process a DMOperation, I think we should probably just print an error to the console and otherwise ignore it

This part modelled after thread-creator.js on the keyserver

This part modelled after createPendingThread

Cast as { ...ThickRawThreadInfo } to get rid of read-only

The only await necessary. I think we will need to query SQLite here

The caller will have a try-catch around calls around processDMOperation. If we fail to process a DMOperation, I think we should probably just print an error to the console and otherwise ignore it

This part modelled after thread-creator.js on the keyserver

This part modelled after createPendingThread

Cast as { ...ThickRawThreadInfo } to get rid of read-only

The only await necessary. I think we will need to query SQLite here

The caller will have a try-catch around calls around processDMOperation. If we fail to process a DMOperation, I think we should probably just print an error to the console and otherwise ignore it

This part modelled after thread-creator.js on the keyserver

I should actually update this. I initially was thinking that it's not important because only receiving clients will process this, and it looks like sourceMessageAuthorID is only used for notifs.

But now I'm thining the sending client will probably call processDMOperation to generate the RawMessageInfos that are stored locally, and will use the result to generate notifs. We have access to the sourceMessage above, so it should be simple to set this correctly

These ids are only used for UpdateInfos on the keyserver side... they don't matter at all on the client side. At some point we probably should have changed the types to remove them, and I suppose we should still do that now... but it's tough to prioritize it given our launch schedule

Created ENG-8713 as a follow-up

This part modelled after createPendingThread

Cast as { ...ThickRawThreadInfo } to get rid of read-only

The only await necessary. I think we will need to query SQLite here

The caller will have a try-catch around calls around processDMOperation. If we fail to process a DMOperation, I think we should probably just print an error to the console and otherwise ignore it

This part modelled after thread-creator.js on the keyserver

Good catch

Yes, I think that we'll call processDMOperation on all recipients – both the devices of the user, and the devices of their peers

Will merge

Are we relying somewhere on this ID schema? I think that using a deterministic ID could cause some issues, e.g. when we create a pending DM thread, add a new user, and then create a new DM thread with the original set of users. I'm not sure if threadID could be a "pending thread ID" - but if yes, then the described scenario will cause a conflict between message IDs.

In this case, threadID should be a non-pending threadID. So I don't think that hypothetical could occur.

Can we use UUIDs instead for the role and all the created messages?

I suppose this would be safer, but it would require extending DMCreateThreadOperation to include UUIDs for all of these, which might be a little messy.