Persistency, options, username validation, project blocking

.gitignore

@@ -2,4 +2,6 @@ node_modules
 # Private filter list
 private.filter
 # Logs
-logs
+logs
+# Database
+/db

README.md

@@ -1,55 +1,44 @@
 # cloud-server
 
-A cloud data server for Scratch 3. Used by [forkphorus](https://forkphorus.github.io/) and [TurboWarp](https://turbowarp.org/).
+A configurable cloud data server for Scratch 3.
 
-It uses a protocol very similar to Scratch 3's cloud variable protocol. See doc/protocol.md for further details.
+Used by:
 
-## Restrictions
-
-This server does not implement long term variable storage. All data is stored only in memory (never on disk) and are removed promptly when rooms are emptied or the server restarts.
-
-This server also does not implement history logs.
+ - [TurboWarp](https://turbowarp.org/)
+ - [forkphorus](https://forkphorus.github.io/)
 
 ## Setup
 
-Needs Node.js and npm.
+Requires Node.js and npm.
 
 ```
 git clone https://github.com/TurboWarp/cloud-server
 cd cloud-server
-npm install
+npm ci
 npm start
 ```
 
-By default the server is listening on ws://localhost:9080/. To change the port or enable wss://, read below.
+By default, the server listens on ws://localhost:9080/. This is good enough for local testing, but if you want to deploy this on a real website, you will probably need to setup a secure wss://.
 
-To use a local cloud variable server in forkphorus, you can use the `chost` URL parameter, for example: https://forkphorus.github.io/?chost=ws://localhost:9080/
+To test locally in TurboWarp, use the `cloud_host` URL parameter: https://turbowarp.org/?cloud_host=ws://localhost:9080/
 
-You can do a similar thing in TurboWarp with the `cloud_host` URL parameter: https://turbowarp.org/?cloud_host=ws://localhost:9080/
+To test locally in forkphorus, uses the `chost` URL parameter: https://forkphorus.github.io/?chost=ws://localhost:9080/
 
 ## Configuration
 
 HTTP requests are served static files in the `public` directory.
 
-### src/config.js
-
-src/config.js is the configuration file for cloud-server.
-
-The `port` property (or the `PORT` environment variable) configures the port to listen on.
-
-On unix-like systems, port can also be a path to a unix socket. By default cloud-server will set the permission of unix sockets to `777`. This can be configured with `unixSocketPermissions`.
-
-If you use a reverse proxy, set the `trustProxy` property (or `TRUST_PROXY` environment variable) to `true` so that logs contain the user's IP address instead of your proxy's.
+Edit src/config.js for additional settings. There's a lot of stuff in there and it's all documented. We will highlight a couple important settings below:
 
-Set `anonymizeAddresses` to `true` if you want IP addresses to be not be logged.
+### Database
 
-Set `perMessageDeflate` to an object to enable "permessage-deflate", which uses compression to reduce the bandwidth of data transfers. This can lead to poor performance and catastrophic memory fragmentation on Linux (https://github.com/nodejs/node/issues/8871). See here for options: https://github.com/websockets/ws/blob/master/doc/ws.md#new-websocketserveroptions-callback (look for `perMessageDeflate`)
+By default, cloud-server does not use a database, so any variables will be lost when no one has been in a project for a short while or the server restarts.
 
-You can configure logging with the `logging` property of src/config.js. By default cloud-server logs to stdout and to files in the `logs` folder. stdout logging can be disabled by setting `logging.console` to false. File logging is configured with `logging.rotation`, see here for options: https://github.com/winstonjs/winston-daily-rotate-file#options. Set to false to disable.
+In src/config.js, you can change the `database` option to `'sqlite'` to instead persist variables in an sqlite database. Variables are saved when a room is automatically deleted for being empty and on a periodic schedule set by `autosaveInterval`. If the server dies unexpectedly, anything that wasn't yet saved will not be saved.
 
-### Production setup
+## Production setup
 
-cloud-server is considered production ready as it has been in use in a production environment for months without issue. That said, there is no warranty. If a bug in cloud-server results in you losing millions of dollars, tough luck. (see LICENSE for more details)
+For this section, we will assume you have complete access to a Linux machine as this is the ideal environment for cloud-server.
 
 You should probably be using a reverse proxy such as nginx or caddy in a production environment.