Cross-signing

[chrysn]

To ease the use of this tool, it'd be great if rather than having to export room keys regularly, the client could cross-sign with other clients.

Suggested mock workflow:

$ ./matrix-archive.py --help
Enter URL of your homeserver: [https://matrix-client.matrix.org] https://chat.example.com
Enter your full user ID (e.g. @user:matrix.org): @chrysn:chat.example.com
Password: *****
Enter full path to room E2E keys, or press Enter to start interactive verification. [Enter]
Scan this QR code from your device, or press Enter again to start emoji-based verification:
█▀▀▀▀▀█ ▀▄█▄█ ▀▄█ █▀▀▀▀▀█
█ ███ █ ███ ▄▄▀▀▀ █ ███ █
█ ▀▀▀ █ ▀ ▄█▀  ▀▄ █ ▀▀▀ █
▀▀▀▀▀▀▀ ▀ █ █▄█ ▀ ▀▀▀▀▀▀▀
▀▀█▀  ▀ ▀ █▀██ ▀▄▀▄▄█▀█▄█
▀ ▀██ ▀█ ██▀▀ ▄▀▀▄▄▄███ ▀
 ▀█ ▄▀▀  █▀▄█ █  ▀▄▄  █▄▄
▄▀█ ▀▀▀ █▄ █ ▀ ▀▀▀ ▄▄ ▄ ▀
  ▀▀▀▀▀▀███ ▀ ▀▀█▀▀▀███ ▀
█▀▀▀▀▀█  ▀▀▄ ██▄█ ▀ ███▄▀
█ ███ █ ▄▀▀  ▀▀█▀█▀▀▀▄▄▀█
█ ▀▀▀ █ █▄█▄▄▄██▀▀▄ ▀▄ █ 
▀▀▀▀▀▀▀ ▀ ▀▀      ▀▀ ▀▀ ▀
[Enter]
Does this sequence of icons show on your other device as well?
🍕 🍕 🍕 🍕 🍕 🍕 🍕
Pizza Pizza Pizza Pizza Pizza Pizza Pizza
(Enter "yes" to continue) yes
Cross-signing successful.
Importing keys. This may take a while...

(Just doing this with emoji would do just fine too; the QR code might just be a neat gimmick given that it's supported by the mobile device client.)

One change that'd bring is that suddenly the program would need to keep (and possibly protect, given the IMO weird but seemingly more widespread sentiment that creating user-only accessible may not be good enough) own state. Once established, though, that could persist the other entered data (or any derived from it) as well, eventually allowing a ./matrix-archive.py --all-rooms to be run regularly as part of a backup process without any user intervention (or, possibly, with only that intervention required to unlock the own data if deemed necessary).

[finefoot]

But do you not keep a local backup of your E2E room keys anyway? I think it would make more sense to have the program automatically retrieve that key backup from the server once matrix-nio supports that: matrix-nio/matrix-nio#218

[chrysn]

But do you not keep a local backup of your E2E room keys anyway?

Not a regular one (because it's a manual process, and those just don't happen regularly); also, AIU, keeping the backup key only makes sense if you expect the server to lose it, and then the messages decryptable with it would be gone as well.

I think it would make more sense to have the program automatically retrieve that key backup from the server once `matrix-nio` supports that: matrix-nio/matrix-nio#218

If matrix-archive supported that (and optionally stored it locally -- but what for, given the messages decryptable with it are already there), it may be just as good. Potential advantages of cross-signing over that are: * More convenient to set up (pressing a few buttons vs. going to the vault to fetch the backup key password) * Might interact better with users that have "Never send encrypted messages to unverified sessions from this session" configured.

[finefoot]

keeping the backup key only makes sense if
you expect the server to lose it, and then the messages decryptable with
it would be gone as well.

I don't know enough about how the server stores messages and key backup, so I don't know if it's fair to assume that if stored key backup is lost, this automatically always also means that stored messages are lost and vice versa. So, in case only key backup is lost, a local backup of E2E room keys would make sense.

Also, I think the key backup is being stored on the Matrix home server of your account while messages are stored on whatever server the room is on, right? So it seems to be useful to keep a local backup of E2E room keys in any case.

More convenient to set up (pressing a few buttons vs. going to the
vault to fetch the backup key password)

But doesn't that come down to personal preference, though? I, personally, don't like having to press buttons and would much rather prefer just using matrix-archive in a portable, unattended batch mode, providing my key backup passphrase to the call, and having E2E room keys automatically fetched for each backup.

Might interact better with users that have "Never send encrypted
messages to unverified sessions from this session" configured.

That sounds like it needs more investigation. Good point.

[russelldavies]

@chrysn Can you detail your use cases of how you intend to use matrix-archive? Quite a few people want to use this tool in an unattended way, either running continuously or periodically without input. This is different to the use case I had originally written the tool for, a one-time export of your homeserver data if you're leaving the homeserver, but I'd like to cover all needs if possible.

[chrysn]

What I want to have (and if matrix-archive can go there, it'd be great) is a tool I can run on a local device that ensures that when my home server goes away, I still have access to my chat histories like I have access to my IRC, Jabber, EMail and ICQ histories. Like with these, this should require little effort. Ideally, I'd set it up (on my working computer or an own server) once and let it run forever (being restarted whenever that device decides to); setting it up to run regularly is an an acceptable workaround (although then it should run incrementally -- what good is it to be started on the full hour when it takes 2h to siphon off all the data).

Personally, I don't care too much if the one-time setup is a tad more complicated (that becomes an issue when recommending the technology in general to others), but any per-backup interaction would kill usability. Depending on running a key export is more or less per-backup (sure you may get some more exchanges, but I have a gut feeling matrix rekeys quite often).

Sure, if I leave the home server, I'd run it one more time to ensure I got everything before I remove the account. But looking back at all the communication systems there were on the Internet, I rarely closed an account somewhere, they either fell into disuses so slowly I'd forget to pull that one last backup when I use the client the last time, or the operator went away somehow.

Hoping this helps the project and is not just me rambling of the good old days ;-)