remember joined chans

[martinetd]

some clients don't reconnect joined rooms on reconnect, remember "currently active rooms" for them to join it back on reconnect

[martinetd]

This came up from @aiobofh a bit ago, so brainstorming here a bit...

I think we need to dump quite a bit of state to disk:

• channel names <-> matrix id, because on name collision we're adding a suffix to the names and that could change from one reconnect to another and that's just horrible UX
• for the same reason, users joined in a chan also have duplicates, so foo_2 and foo could interchange between two reconnects!
• as pointed out a user might prefer having some direct conversations as chan depending on their client, we could remember that easily -- other way around should also work as we prefix messages in queries when it's not obvious who it come from.
• Need to decide on an interface but would also allow to rename some chans or nicks in chans

Obviously dumping it all to json and writing to disk everytime would be possible but possibly a bit slow; since we already depend on sqlite for the matrix rust sdk I'm thinking of making that a sqlite db and just updating on changes which should be much more efficient.

I don't think there's anything sensitive here, but might as well encrypt the data on disk -- that can perhaps come later -- need to check how the matrix sdk does its encryption but we can add a new random key to the initial session and keep it in memory as low stake secret (we've got all the state there anyway!)

So:

• check rust sqlite bindings
• dump & load stuff
• profit!

[martinetd]

So while I said encryption is optional I;d rather not leak channel names so I had a quick look at matrix-rust-sdk code

Unfortunately, matrix-sdk-store-encryption is rather low level (readme suggests not to use it directly with some recommendations about rekeying I'm not confident I understand given I don't see matrix-rust-sdk do it...), while the matrix-sdk-sqlite crate bakes in the matrix client schema so it is not appropriate to use either.

With that in mind I'm not sure whether it makes much sense to roll our own or look for alternatives e.g. rustqlcipher? On the flip side "rolling our own" doesn't have to be too bad -- if we give up on sqlite/a db interface, it's easy enough to serialize some kind of state to json and re-encrypt it in the state dir everytime we change it (with a random nonce...), because we'd only be keeping in joined channels list it's not something that'd change often. However it has a few downsides:

• it's a bad idea to keep the password around in memory while a client is connected (the current code ought to forget it once matrix has logged in)
• it'll be one more obstacle to changing password, we shouldn't use the irc client password for encryption everywhere.

Both of these problems can be solved by having an intermediate passphrase derived from the original password (which is my understanding of what the matrix-sdk encryption stuff does), but it's starting to look like a PITA and I'm way too tired right now to think straight let alone think about encryption :grin:

So, yeah, v0 might be in plain text for people who trust/run their own server (which I expect to be 100% of matrirc users at this point), with the caveat that we might want to make this optional in that case?

Once that's decided, the feature itself (keeping list of joined channels) ought to be really simple, so it's really just a matter of deciding how we want to store it.

Opinions welcome if anyone cares