networking-options.md

Options:

1. Integrate with concept-fetch in the android components, allowing GeckoView to provide our HTTP implementation.

   • The main potential issue is a possible dependency cycle with android components. Prior experience with exposing RustLog to them had trouble around this, however we've been assured that it shouldn't be an issue this time around, and if it is, it's one that can be resolved.
   • This is the most straightforward route, and I've scoped it out below. I'll explain the other options in terms of which parts of the work below we don't have to do, and what we have to do instead.

2. Bind to native Java networking APIs.

   • This allows us to avoid needing to add a new android component, e.g. step 5.
   • However, it will increase the amount of work to translate Rust network requests to Java, and Java responses back to Rust (part of step 2), as the Java networking APIs are not as direct of a fit for what we want to expose in Rust.
   • This option saves almost no work compared to option 1, and produces a worse outcome (using Java networking instead of our own).

3. Find a way to replace reqwest's backend with GeckoView via concept-fetch (was mentioned as an option in slack)

   • This allows avoiding defining our own HTTP abstraction, and avoids changing most of the existing application-services code (steps 1 and 3).
   • Instead, changes must be made to the Rust library application-services depends on, so that it can use necko directly, by calling through Java. This doesn't seem like something we could ever hope to upstream, which would force us to maintain a large, complex dependency moving forward.
   • This has another drawback of leaving us with a large number of rust dependencies related to the HTTP stack, which now would be largely irrelevant.
   • This option seems like far too much work and ongoing technical debt to be worth what it gets us, which is rather small (the steps we'd get to skip are not expected to be particularly difficult)

4. Integrate with Necko directly, skipping over Java and GeckoView.

   • This allows skipping writing bindings via Java/Kotlin, and exposing it to Android Components (specifically, steps 2 and 5).
   • Realistically, we can't do this unless we're part of libxul. Doing this requires a bunch of nontrivial work we haven't really begun to consider.
   • That said, ultimately, this (including becoming part of libxul) is the path forward and will be required for use in Desktop.
   • In the short term, there's not enough time to do this, as it requires a good amount of investigation we haven't started yet, so it's a bad fit for this project. However, it's worth revisiting in the future.

Suggested plan: Integrate with concept-fetch

1. We need to provide a Rust crate that defines an HTTP abstraction.

   • It should be configurable at compile time to either use the current Rust HTTP stack, or to use an implementation that can be provided at runtime.
   • Size: M

2. We need to provide Kotlin/Rust FFI that allows the Kotlin to be passed something that implements concept-fetch, which it binds and uses to initialize the Rust crate from 1.

   • Size: L

3. We need to replace the existing HTTP code with this abstraction.

   • Size: L

4. Integrate this with our build system satisfactorially.

   • Add to megazords.
   • Change build scripts not to bundle libssl with them (they still need openssl's libcrypto until we do the crypto replacement).
   • Ensure the non-megazord variants still use the current Rust stack OR do the work to replace their networking
   • Size: M. The main uncertainty here is:
     • Unclear if the non-megazord use can work given the limitations of cargo features
       • If they can't, we may be able to make work based on concept-fetch, it just adds more unknowns to step 5.
     • Unclear how easy it is to separate libssl from libcrypto given that we're using rust-openssl. It's not clear how bad failing to do this would be, however -- we'd still not be using openssl for networking, which might be enough for people to be happy.

5. Add a new component to android-components analogous to the RustLog component, but instead of initializing logging for the rust code, it initializes networking.

   • Size: M. The main uncertainty here is:
     • If we can't make cargo features work in step 4, we'll have to use cargo targets to say "Okay, on android we always use this concept-fetch based networking", which can be done more reliably. This means that we have to figure out how to make this work in a non-megazord context.
       • This is should be possible, but not something we've done before. For RustLog, we didn't bother because it's not trivial, and the downsides of including our fallback logger everywhere are very minimal (a few kilobytes of dead code in the build).