plannings

plans/private rover outline.md

@@ -0,0 +1,30 @@
+# private rovers
+## basic concept:
+private rovers will be mostly just for lockdown admins to drive and use, but they can be temporarily unlocked manually by lockdown admins for use by verified users.
+
+- cannot be spectated by spectators, ever
+- cannot be replayed, ever
+- private status is defined in the roverd config
+- needs to never leak through access to anyone while locked
+- unlocking a private rover is a big deal for verified users
+
+## locking / unlocking:
+- private rovers start locked
+- when locked, only lockdown admins can drive them
+- when unlocked, only verified users can drive them
+- if left unlocked with no one online for 1 hour, the server will automatically lock them
+
+## cliff rules / speed limit / overcurrent limit
+### private rovers will be in a sensitive area, so their physical capabilities will be limited by the server
+- if the cliff sensors get triggered, stop the rover and back it up
+- speed limit is already kind of a thing but has never been tested, need to make sure it works all the way through the control pipeline
+- hard overcurrent limits done server-side. completely seperate from the current client only ones. 
+  - almost zero tolerance for wheel and side brush overcurrents
+  - come up with a way to do this without making it feel too punishing. overcurrents often happen by accident
+  - ignore the main brush, private rovers wont have one so it may read wrong
+
+## UI specifics
+- private rovers don't show in the list for normal users unless they are unlocked
+  - they will only show for lockdown admins
+  - when unlocked, they show for everyone
+    - with a different color in the rover list

plans/user verification outline.md

@@ -0,0 +1,44 @@
+# user verification system
+## main idea
+- a relatively simple system to verify trusted users and allow them to use special features
+- uses IP, a cookie user ID, and nickname to verify people
+
+## on-connect system to send user info to the server
+- a new system in the web UI (and server a little bit probably)
+- ensures that the server gets all of your user info when you connect
+  - also ensures that the server can seamlessley remember who you are if you happen to lose connection and reconnect
+- info contains:
+  - nickname (replace the current reconnect and nickname logic with this new system)
+  - cookie ID
+  - more stuff in the future probably
+
+## cookie user ID
+- an ID that the server assigns to a user
+- saves as a setting in the settings persistence system in the user's browser
+
+## how will the server verify people
+- when a user connects and sends their user info:
+- step 1: IP address OR cookie user ID
+  - if the user's IP or their cookie ID matches, continue to step 2
+- step 2: nickname
+  - if the user's nickname matches to it's expected step 1, the user is now verified
+- the user is now verified and added to a persistent database on the server
+
+## how will verification requests work
+- user goes through the process in the web UI
+- the request is DMd to lockdown admins in discord
+- each message can be reacted with a check or an x emoji by the lockdown admins to accept or deny a request
+- no realtime UI feedback is needed for when a request is accepted or denied
+
+## UI specifics
+- a new VIP tab in the sidebar
+- either shows a button to request verification, or shows the VIP controls
+### verification process
+- a button in the sidebar to request verification
+  - only shows if you aren't verified
+- the actual process:
+  1. press the button
+  2. the page opens a new pop-up
+  3. it explains what verification is, how it works, and that your nickname is attached to your verification
+  4. prompts users to confirm their nickname, as if they change it their verification won't work
+  5. a final confirmation saying that their request has been sent