Consider not duplicating the crypto API on MatrixClient

[turt2live]

we really just need a isCryptoEnabled flag and the rest can just NPE if people fail to handle client.crypto being null....

[jryans]

Yes, I've never quite been sure why we duplicate most crypto methods onto the client... 🤔

[turt2live]

ftr, I'm translating them verbatim in a typescript conversion but one day I'd like us to remove the ~1700 lines of code from MatrixClient.

[richvdh]

Yes, I've never quite been sure why we duplicate most crypto methods onto the client...

The reason it's done like that is to separate the internal interface of the Crypto module/object from the public one. But certainly it's ended up as a big mess with lots of stupid stub methods in MatrixClient.

My goal is to make the Crypto module properly internal as part of #21972. As part of that I can look into replacing it with two interfaces: a public one exposed to the application by, say, client.getCrypto(), and an internal one only to be used by other parts of the js-sdk.

[richvdh]

To update on this: it's in progress as part of my work on Element Web R. We're exposing a public CryptoApi interface which is accessible via client.getCrypto(), and deprecating the MatrixClient wrappers as we add things to CryptoApi.

Progress so far includes

• Pull out a public CryptoApi matrix-org/matrix-js-sdk#3211
• Element-R: Add support for /discardsession matrix-org/matrix-js-sdk#3209
• Element-R: implement {get,set}TrustCrossSignedDevices matrix-org/matrix-js-sdk#3281
• New CryptoApi.getDeviceVerificationStatus api matrix-org/matrix-js-sdk#3287
• Element-R: Stub out isCrossSigningReady and isSecretStorageReady matrix-org/matrix-js-sdk#3354
• Integration test for bootstrapCrossSigning matrix-org/matrix-js-sdk#3355
• Deprecate device methods in MatrixClient matrix-org/matrix-js-sdk#3357
• Add CryptoApi.getCrossSigningKeyId matrix-org/matrix-js-sdk#3360