Feature proposal: Session strings with variable state.

[TheCommCraft]

A problem with scratchattach is that you cannot easily use scratchattach with your main account as you will get logged out when the program uses your login data to create a session and a supplied session id will expire relatively fast. This could be partially fixed if you can save your new session ids somewhere so they don't have to be regenerated every fresh start of the program. This, however is not always possible. A possible alternative would be to save the session ids to the cloud. This would need very careful handling of the data being transferred to the server. I once created a prototype program where one could save data to an untrusted server without the data being compromised by first specially encrypting the data before sending it. But if we implement this and make a mistake, a lot of users could possibly have their session ids, which cannot easily be revoked, leaked. I would appreciate feedback from @faretek1 aswell as users of scratchattach. To test something like this publicly, it could always be optional.

[faretek1]

An existing store of session ids and authentication credentials is the CLI. We could add a feature that allows saving/loading of sessions from the CLI's sessid SQLite database. This was a feature I was planning but forgot about

something like sa.login_by_cli("faretek1")

[faretek1]

I don't think it would be a good idea to save session ids to the cloud. What particular cases do you think would need that?

[TheCommCraft]

it is possible to save them securely so a key is needed to read the plaintext

[TheCommCraft]

btw the sqlite db wouldn't be an option if there is no persistent storage

[faretek1]

The only case I can think of where you don't have persistent storage is something like a deployment. In which case, you may be better of using environment vars.

I'm not sure about the idea of adding a password to the sqlite db