Update 'Roadmap'

Roadmap.md

@@ -8,32 +8,27 @@ What is currently upcoming.
 | Feature | Description | Depends on |
 | --------------- | --------------- | --------------- |
 | **Room State Management v2** | Finish off the room state management stuff. | N/A |
-| **Room Metadata** | Internally store arbitrary key values on a per-room, per-user basis. | N/A |
+| **User Accounts and State** | Ability to register account with the bot, for external applications.| N/A |
-| **Character Sheet Integration v1** | Integrate with an external online character sheet service. | Room Metadata. Existence of said service. |
+| **External System Integration** | Bot exposes an API for external applications to control it. | N/A |
+| **Bot Web UI** | A web UI for managing variables in rooms. | Room State Management v2. | User Accounts, External System Integration |
 
 ### Room State Management v2
 
 Extend room state management to work under the following scenarios:
 
-- When the bot joins a room, add all users in the room to the database.
+- [X] When the bot joins a room, add all users in the room to the database.
-- When the bot joins a room, add the room name/ID to a room info struct/tree.
+- [X] When the bot joins a room, add the room name/ID to a room info struct/tree.
-- On startup, sync room member lists as an async task. Update member list for every room the bot is in.
+- [ ] On startup, sync room member lists as an async task. Update member list for every room the bot is in.
 
 The foundation already exists, which is the logic for the `!resync` command. This just needs to be executed in these scenarios.
 
-### Room Metadata
+### External System Integration
 
-The ability to store metadata on a per-room, per-user basis. This is foundational work for the character sheet integration. The metadata will be stored as key-value pairs, with the key consisting of user ID + room ID + key name. The value can be anything, and code will enforce type requirements.
+Add some kind of RPC server to the bot. Probably gRPC. This is the single most important task towards getting a functional web UI up and running. The API must initially be able to authenticate users, control user state, and set variables.
 
-The primary use cases for this are:
+### Bot Web UI
 
-- Store a link to the character sheet
+Essentially character sheets version 0. Yet another lowering of expectations. A very basic web UI where users can log in, see what rooms the bot knows about for them, and manage their variables in each room.
-- Store the locally cached character sheet protobuf data.
-
-
-### Character Sheet Integration
-
-The "holy grail" of the whole idea. A gRPC connection will be setup between the dice bot (acting as a server) and instances of the web app (gRPC clients). Changes in the web app will be reflected in the bot. The first iteration of this will not have bidrectional changes (that is, bot will not be able to force updates to the character in the web app).
 
 ## Intermediate
 
@@ -42,6 +37,7 @@ Things that are easier to implement, but not yet scheduled.
 | Feature | Description | Depends on |
 | --------------- | --------------- | --------------- |
 | **Private Commands** | Manage all bot functionality from a private room | Room State Management (done) |
+| **Room Metadata** | Internally store arbitrary key values on a per-room, per-user basis. | N/A |
 | **Resource Counting** | Creation of counters that can go up and down. System agnostic. | N/A |
 | **CofD Game Management** | Management of slightly complex CofD things like health. | N/A |
 
@@ -54,10 +50,24 @@ This will require some internal changes:
 * Dicebot must now be aware of what room a user is managing in a direct message. This may be the first introduction of a proper state struct for users in the database. Possibly new keyspace `state`, with just a key name of username. 
 * Commands must be aware of if they are being executed in a direct message or a regular room. Probably easiest to add this property to the `Context` object.
 
+### Room Metadata
+
+The ability to store metadata on a per-room, per-user basis. This is foundational work for the character sheet integration. The metadata will be stored as key-value pairs, with the key consisting of user ID + room ID + key name. The value can be anything, and code will enforce type requirements.
+
+The primary use cases for this are:
+
+- Store a link to the character sheet
+- Store the locally cached character sheet protobuf data.
+
+### Character Sheet Integration
+
+The "holy grail" of the whole idea. A gRPC connection will be setup between the dice bot (acting as a server) and instances of the web app (gRPC clients). Changes in the web app will be reflected in the bot. The first iteration of this will not have bidrectional changes (that is, bot will not be able to force updates to the character in the web app).
+
 ## Future
 
 Things in the far future that require a lot of groundwork or other features to be finished first.
 
 | Feature | Description | Depends on |
 | --------------- | --------------- | --------------- |
+| **Character Sheet Integration v1** | Integrate with an external online character sheet service. | Room Metadata. Existence of said service. |
 | **Character Sheet Integration v2** | Bidirectional character sheet changes. | Character Sheet Integration v1. |