User Accounts and State

This documents user accounts and state, a foundational feature required for building a functional web UI for users to manage their information in the bot. The core of this idea is that users can register an "account" with the bot, which is just a record of their matrix user ID and a hashed password. But it also includes the ability to create and manage user state, like the active room for the user.

User Accounts

The primary part. We need to store user information in the bot.

User account table: A DB table. Duh.
Secure command handling: Registration command is sensitive and contains password. Can only be done in E2EE room alone with the bot. Password is not logged.
Registration command: !register <password> to create or update an account with the bot.
Registration command for bridges: For bridged non-Matrix platforms, we must support a method of registration that doesn't require E2EE rooms. Likely way to do this is a temp password/activation code sent via email + complete registration in a web UI somewhere.
Check account command. Give it the password and it will tell you if you are able to log in.

The trickier part of this is supporting bridged platforms, since those don't work with the native end-to-end encryption in Matrix. For this, we'll need to add the ability to send emails to the bot (Optional SMTP config), and an account status that tells us if we are full or only partially active. Partially active accounts need to complete registration elsewhere (web UI).

User State

Store some information about what the user is doing, and provide commands to manage it. The primary use case for this is for Private Commands (contextually managing info in any room from a DM with the bot). If we store the active room for a user, we can then add that room to any command executed from a DM, and it will even hook into the existing context system (mostly).

User state DB table with columns user_id, account_status, active_room.
!room command to switch active room.
Add originating_room to Context, so we can differentiate between room where command is executed, and room where command should apply.