wondering if this is the best approach - but can't think of any alternative

we already have this API here but first we need to implement ENG-6462.

After ENG-6462 here will be just something like suggested.

@michal going to just move this code to worker side.

If we only need the API from within React components, we could consider a React context with a provider

If we do choose to use this approach, keep in mind that it might be difficult to implement without import cycles. This might be easier to handle if you replace this with a () => OlmAPI. @inka has been dealing with something similar in ENG-6872

I think on native this function does more. Is there a plan to add that functionality later?

Is this content account? What about a notifications account? Is it going to be included too?

As discussed in the office: Methods for notif account are already implemented in OlmSessionCreatorContext so I am not including them here to avoid code duplication - but those could be moved here while working on moving everything to worker (ENG-6657).

If we only need the API from within React components, we could consider a React context with a provider

I think in the future we can use it from different places, and this also allows us to implement the same interface and have more shared code with keyserver.

If we do choose to use this approach, keep in mind that it might be difficult to implement without import cycles. This might be easier to handle if you replace this with a () => OlmAPI. @inka has been dealing with something similar in ENG-6872

Maybe I am missing something but not sure if () => OlmAPI fixes this - OlmAPI is just an object with methods and doesn't require additional computation. I think we should only avoid using getConfig() on the level. (like I did in D11120 - going to update this).

yes, but this is tracked in ENG-6647. Current logic is implemented in GetOrCreateCryptoStoreProvider