Feature: Intercept downloads to transcode/decrypt payload

Currently I am downloading encrypted payload and its stored on storage as a file. To display the data in the app After the download I have to read the whole file that was just written to storage back into memory (in chunks or as a whole), decrypt it, save it back to storage and removing the encrypted version of the file.

I wonder now if the library could allow the user to supply a file writing interceptor that this lib delegates the file writing to like this:

await BlobCourier
  .onDownload({
    blockSize: 16384 * 5,
    transcode: (input: ArrayBuffer, last: boolean):Promise<ArrayBuffer> {
      last ? return aes.finish(input) : aes.decrypt(input)
    }
  }
  ).fetch("https://example.org/encrypted.enc")

Some starting point maybe? https://medium.com/swlh/okhttp-interceptors-with-retrofit-2dcc322cc3f3

It would be crucial to operate on streams rather than having the whole response in memory.

[edeckers]

I’ve created feature requests #139 and #140 for this; first on I’ll work on will be #139.

[edeckers]

Hi @pke , apologies for the late reply I was vacationing.

As for your question, I think you meant to refer to the new JSI architecture / Turbomodules or am I wrong? I have been working on migrating BlobCourier to it https://github.com/edeckers/react-native-blob-courier/pull/213. There’s two things holding it up for now:

1. There is a bug in mockk https://github.com/edeckers/react-native-blob-courier/issues/217, related to M1 architecture, which causes my instrumented Android tests to fail - although I could circumvent this by just reverting and hardcoding the library to its previous version
2. I need to add instrumented Android tests that check not only the NativeModules but also the TurboModules
3. I’m not 100% confident yet I migrated everything correctly, the documentation for migrating is still lacking a little, but when (1) and (2) are fixed I think I’m confident enough

That being said, I don’t think react-native-vision-camera uses the TurboModules-architecture, but they do use JNI as you mentioned correctly. Although they seem to achieve it through this method: https://thebhwgroup.com/blog/react-native-jni. That fixes the problem only for specific plugins you’d write for BlobCourier though, you wouldn’t be able to hook-up react-native-simple-crypto as-is.

The way I understand TurboModules at this time - as I mentioned above, I’m not 100% confident yet - I think you’re right and they should solve our problem indeed. But only if both BlobCourier and react-native-simple-crypto migrate to it. There will be efforts to convince maintainers do migrate their libraries as soon as possible, so you might be in luck: https://reactnative.dev/blog/2022/03/15/an-update-on-the-new-architecture-rollout#the-3rd-party-libraries-ecosystem

If we identify a library that becomes a blocker for a number of users, we will try to reach out to the maintainer and understand why they haven’t migrated yet.