Restoring sessions after creating an account.

[caseyjkey]

Users can host many instances of agents and build context within each one. If they have to reset their app without noting seed data, all exisiting sessions are lost and there is a lot of friction to getting back up to speed w.r.t. restoring all sessions.

However, the sessions continue to run on the host machine(s). I think it would be convenient if there was a way to restore these sessions when logging into the machine from a new account rather than leaving sessions orphaned.

Ideas:

• Ask if user wants to connect/migrate/restore existing sessions to this new account.
• Use Github Oauth for user accounts as it is persistent across installs.

[leeroybrun]

Hey @caseyjkey !

Thank you for the discussion. :)

I'm not sure this is the correct way to solve this, as sessions are tightly tied to the accounts because of encryption. So even if the sessions are still running locally, might be difficult to resume in another account. And also I have the feeling that it would solve a symptom more than the root cause of that issue (losing the account encryption key), and might be more of an edge case.

I have added yesterday options on the server way to disable encryption for self-hosting. Which means that you could configure GitHub as the only auth method on your server, disable encryption, and so you can then simply connect to your server from any machine using GitHub and would always be connected to the same account.

I've also added recently the "backup your secret key" message so that it's clearer for users that the secret key is the only way to connect/restore their account (was a bit too opaque in happy).

What are your thoughts? Would the GitHub auth + disabled encryption solve your issue?

[caseyjkey]

No problem. I want to be mindful of priorities and plans when considering any changes.

Does disabling encryption cause all sessions to be shared among all users on the server? This would fit the usecase of resuming existing sessions and work better during development. However, I want to consider usual workflows via production Happier API server.

Does Github connection via Settings tab connect the Github account to that user, and then can Github Oauth be used to login instead of private key? I apologize as I havent registered a Github OAuth/App credentials to test functionality yet.

[leeroybrun]

No worries! It's great to have feedback

Encryption can be disabled entirely for a server, or be made opt-out (meaning users can choose to use it or not when creating an account). Not everything is finalized on that part, but the goal is to let users choose if they want encryption or not, so we can offer them features that we cannot offer with encryption (for example, search for past sessions/messages). It's also a good option for people who self-host, because in that case encryption makes less sense (if it's your server, you are the ony one having access to your DB, etc so you don't necessarily need encryption).

With encryption though, we cannot restore an account just with the Github OAuth, because only the user has the decryption key on his device (the secret key). We don't have it on our end, which is expected, otherwise we could decrypt users' messages.

This is why with encryption, we cannot support a "connect with Github, get your account back". The user still has to enter his key or connect it from a different device. We don't have the key to decrypt the user's data on our end.

Without encryption, this is effectively possible and users can log back in their account only with Github OAuth.

Now, the safest approach is to make the users understand that their key is the only way to access their account (what we do with the "backup your key" message) and to encourage them to link their mobile device so that they have at least 2 devices logged-in.

I don't think that we should support a "reattach to another account sessions". Users in the end can simply resume the sessions using the provider session ID. For example, if they had Codex sessions, they can simply take the Codex session ID from their past session, and resume them in their new accounts. But they should not even have to do this if they backup their secret key :)