Not implemented, and not waiting on anything. Rejects with kind
'not_implemented'. createRecovery is the call that does this
job, and it is the one to use.
The signature has been frozen since the first milestone: a passphrase in,
a Uint8Array out. What has become clear since is that no such byte
array exists in Matrix. matrix-sdk-crypto provides the payload and
not the container: export_secrets_bundle yields the three signing
seeds as plain JSON, neither encrypted nor derived from a passphrase, and
its two passphrase primitives are the wrong shape for wrapping it. One is
the session-key export format, which is a different payload. The other is
secret storage itself, whose salt and iteration count belong in account
data rather than inside a byte array.
So the container would be a format this library invented, and no
other Matrix client would read it. That is a defensible thing to build
for "move my identity to my other phone over a cable", and the wrong
thing to hand anyone who expects a Matrix recovery key. Since
createRecovery delivers the interoperable form, shipping a
private one beside it would invite exactly that confusion, so these two
stay unimplemented on purpose rather than pending.
If you need the identity on a second device you still have, that is
requestSelfVerification. If you need it after the first one is
gone, that is recoverIdentity.
Not implemented, and not waiting on anything. Rejects with kind
'not_implemented'. createRecovery is the call that does this job, and it is the one to use.The signature has been frozen since the first milestone: a passphrase in, a
Uint8Arrayout. What has become clear since is that no such byte array exists in Matrix.matrix-sdk-cryptoprovides the payload and not the container:export_secrets_bundleyields the three signing seeds as plain JSON, neither encrypted nor derived from a passphrase, and its two passphrase primitives are the wrong shape for wrapping it. One is the session-key export format, which is a different payload. The other is secret storage itself, whose salt and iteration count belong in account data rather than inside a byte array.So the container would be a format this library invented, and no other Matrix client would read it. That is a defensible thing to build for "move my identity to my other phone over a cable", and the wrong thing to hand anyone who expects a Matrix recovery key. Since createRecovery delivers the interoperable form, shipping a private one beside it would invite exactly that confusion, so these two stay unimplemented on purpose rather than pending.
If you need the identity on a second device you still have, that is requestSelfVerification. If you need it after the first one is gone, that is recoverIdentity.