Rip out legacy crypto code

[richvdh]

As a result of our work on Element R, lots of the js-sdk code is deprecated or unusable. Once Rust crypto becomes the default (related: #26869), we should begin ripping out the legacy code.

Hopefully, as part of that, we can close #17488.

[richvdh]

We'll need to make sure they are all deprecated first, of course: #26919

[richvdh]

Blocked on #27001

[Johennes]

The legacy crypto code treated libolm as an injectable dependency, loading it from the Olm global. This is crucial for environments that don't support WASM (such as React Native) and allows consumers of matrix-js-sdk to provide libolm based on their specific restrictions.

The Rust crypto code doesn't appear to have the same feature and relies on loading WASM. Removing the legacy crypto code would, therefore, effectively cut off the WASM-incapable environments – seemingly without a suitable alternative.

Additionally, for environments that can run WASM but don't require encryption, the bundle size is bloated significantly as per matrix-org/matrix-js-sdk#4154.

Could we maybe provide the same global injection mechanism for the Rust crypto code?

[richvdh]

The Rust crypto code doesn't appear to have the same feature and relies on loading WASM. Removing the legacy crypto code would, therefore, effectively cut off the WASM-incapable environments – seemingly without a suitable alternative.

Yes, that is regrettable. Unfortunately we're not really in a position to maintain two crypto stacks, so I can't see that we can do much about it. The legacy crypto stack, apart from being a somewhat unmaintanable mess, contains known issues that we really don't have the time or resources to fix, and attempting to maintain it in parallel with the Rust stack would impede our ability to iterate the protocol to fix things in future.

I'd be interested to hear which applications require crypto but lack WASM support, but I think the die was cast at the point we decided to rewrite the existing stack in rust: matrix-js-sdk will not be supporting cryptography without WASM. Grand rewrite projects always come at a cost of someone's favourite feature, and in this case crypto-without-wasm is such a feature.

Additionally, for environments that can run WASM but don't require encryption, the bundle size is bloated significantly as per matrix-org/matrix-js-sdk#4154.

Could we maybe provide the same global injection mechanism for the Rust crypto code?

I don't entirely follow what's going on in that issue; certainly the intention is that, if you don't need crypto, you don't need the WASM artifact and you should configure your Webpack/Vite/whatever so that it isn't built in.

The global injection mechanism made crypto very hard to use as a developer. Having to inject things into global variables simply isn't a thing a modern Javascript developer expects to do. The only reason we had it was because of some US-export-regulation-hoop-jumping that stopped us shipping cryptography implementations from Github. It made testing hard and was generally a pain in the butt to maintain. I'm very happy to see the back of it :).

[Johennes]

Yes, that is regrettable. Unfortunately we're not really in a position to maintain two crypto stacks, so I can't see that we can do much about it. The legacy crypto stack, apart from being a somewhat unmaintanable mess, contains known issues that we really don't have the time or resources to fix, and attempting to maintain it in parallel with the Rust stack would impede our ability to iterate the protocol to fix things in future.

Yes, agreed and I'm not trying to make a case for maintaining both stacks. I'm merely advocating for having the same loading mechanism in the Rust stack that we currently have in the legacy stack.

I'd be interested to hear which applications require crypto but lack WASM support, but I think the die was cast at the point we decided to rewrite the existing stack in rust: matrix-js-sdk will not be supporting cryptography without WASM.

I don't know if there are other environments but, as I mentioned, React Native lacks WASM support. There is https://github.com/cawfree/react-native-webassembly but it hasn't seen any updates in a year and people seem to be struggling to make it work at all.

Grand rewrite projects always come at a cost of someone's favourite feature, and in this case crypto-without-wasm is such a feature.

The unfortunate thing is that this is not just an arbitrary tiny feature. You're shutting out an entire ecosystem and React Native isn't exactly an exotic technology. Using matrix-js-sdk in React Native has even been semi-officially supported through https://github.com/matrix-org/matrix-rn-sdk in the past.

I understand that the global object isn't exactly a great approach. I'm not really an expert on the technical details but would there be any other way in which we could allow consumers of the SDK to control the WASM loading?

[richvdh]

I understand that the global object isn't exactly a great approach. I'm not really an expert on the technical details but would there be any other way in which we could allow consumers of the SDK to control the WASM loading?

In theory, if you don't enable crypto in your client, you won't load the WASM artifact. That's why it's dynamically loaded. It should be a fairly simple matter of configuration in your bundler of choice.

[Johennes]

My use case is matrix-js-sdk in a React Native app with encryption. I'm currently using the official ASM build of libolm which, so far, works great with the crypto store from matrix-org/matrix-rn-sdk#2.

[richvdh]

@Johennes perhaps I'm not understanding what you're asking for, then.

It seemed you had two points:

• First: clients that don't support WASM (such as React Native) are going to be prevented from using crypto via matrix-js-sdk. On this: I agree with you that this is a problem, and one which was unforeseen when Element decided to adopt the Rust cryptography implementation, but like I said: the die is now cast and I can't see any viable solution.
• Second, you were saying that even if you don't want crypto, you're forced into downloading the WASM binary as part of your app. I'm trying to say that I don't think that is correct.

[Johennes]

Sorry, the first point is my actual problem. I clumsily tried to use the second point to underpin it, arguing that having the import injectable would have other benefits. But I think you're right that this particular case is probably solvable via bundler configuration.

I'm finding this pretty unfortunate overall, not least because matrix-js-sdk is a matrix-org project. Any chance you'd be open to an external contribution that makes matrix-sdk-crypto-wasm injectable?

[richvdh]

Any chance you'd be open to an external contribution that makes matrix-sdk-crypto-wasm injectable?

Possibly, but how does that help your situation?

[Johennes]

So basically with libolm I'm loading the legacy ASM build into the Olm global with

global.Olm = require('@matrix-org/olm/olm_legacy');

If the matrix-sdk-crypto-wasm import could be injected, I could maybe do something similar by translating the Rust Crypto WASM to ASM (e.g. via https://github.com/WebAssembly/binaryen#wasm2js) and providing that instead.

[richvdh]

I see. Interesting. We're somewhat off-topic here: could you open a separate issue and we can discuss further?