Revise README for clarity and updated instructions

Updated the 'Why?' section for clarity and added details about the project's architecture and limitations. Revised prerequisites and configuration instructions for better readability.

README.md

@@ -9,32 +9,39 @@ each as an independent Worker on its own subdomain.
 > experimentation. It is not affiliated with, endorsed by, or connected to Rec
 > Room Inc. "Rec Room" is a trademark of its respective owner.
 
-# Why?
+## Why?
 
 There are already so many multiplayer clones, why?
 
-1. None of them are fully open source
-2. None of them run on microservice architecture
-3. "Upgrading the server" is not a lasting fix
+1. None of them are fully open source (some had leaks of old code).
+2. None of them run on microservice architecture, and crash constantly.
+3. "Upgrading the server" is not a lasting fix.
+4. Exploits were rampant due to bad code.
+5. This was fun (sort of).
 
 RecFlare uses a true microservice architecture which, if developed correctly, is
 near infinitely scalable and could support the same number of concurrent users
-that the original game had.
+as the original game. It will never run out of CPU, memory, or disk space.
 
-Of course, all you need is money for the cloud costs...
+Being truly open source means that this project should have more eyes on it,
+resulting in bugs getting fixed faster. I hope.
+
+Of course, cloud services cost money. That's the only limitation.
 
 ## Client
 
 RecFlare is compatible with the
-[CannedNet client](https://github.com/CannedNet/CannedNet) and the build of Rec
-Room with manifest `7859140924515540835`. Other client or game versions expect
+[CannedNet client](https://github.com/djdevin/CannedNet) and the build of Rec
+Room with manifest `7859140924515540835`. Other client or game versions may expect
 different endpoints and response shapes and are not supported.
 
+See the project page for information on how to mod the game to connect to this server.
+
 ## How it works
 
 The Rec Room client discovers every service by fetching an _endpoints document_
 from the name-server (`ns`) worker at the apex domain. That document maps each
-service to a host like `https://api.<your-domain>`. Every service runs as a
+service to a host like `https://match.<your-domain>`. Every service runs as a
 separate Cloudflare Worker attached to its own subdomain, so the client's traffic
 fans out across the workers in `apps/`.
 
@@ -47,7 +54,7 @@ completely stateless and no data is stored alongside the microservices.
 
 ## Services
 
-These are every RecNet service the client discovers, taken from the
+This is a list of every RecNet service the client discovers, taken from the
 service-discovery map in [`apps/ns/src/endpoints.ts`](apps/ns/src/endpoints.ts).
 Each is reached at `https://<subdomain>.<your-domain>`. Services with a worker in
 `apps/` are implemented here; the rest are advertised in the endpoints document
@@ -114,6 +121,8 @@ No. The services are plain [Hono](https://hono.dev) apps, so the request-handlin
 code isn't tied to Cloudflare and can be deployed to other hosting providers —
 AWS (Lambda), Vercel, Netlify, Fly.io, a plain Node/Bun server, and so on.
 
+**However**
+
 The catch is everything _around_ the code. RecFlare leans on Cloudflare for the
 deployment and infrastructure layer — custom-domain routing per service, plus the
 storage bindings (D1, KV, R2, Durable Objects) the workers use. On another
@@ -122,13 +131,14 @@ object storage, a pub/sub or WebSocket layer) and wire up the deployment yoursel
 
 ## Prerequisites
 
-- node.js v22 or later
-- pnpm v10 or later
-- bun 1.2 or later
+- node (modern)
+- pnpm
+- bun
+- jq
 - A Cloudflare account with a zone (domain) you control, for deploying
 
-The free plan is good enough for testing (100k requests/day) but the client is
-pretty chatty, so frequent testing may exhauast that quota.
+Cloudflare's free plan is good enough for testing (100k requests/day) but the
+Rec Room client is pretty chatty. Frequent testing may exhauast that quota.
 
 See https://developers.cloudflare.com/workers/platform/pricing/#workers
 
@@ -142,32 +152,32 @@ just install
 
 **Configure your custom domain:**
 
-For local development, set your base domain in a `.env` file at the repo root; it
-is gitignored, so each clone needs its own copy. (For CI you can skip the file and
-export `RECFLARE_DOMAIN` directly — see below.)
+Create a new .env file:
 
 ```bash
 cp .env.example .env
 # edit .env and set RECFLARE_DOMAIN to your domain
 ```
 
+Or, export it:
+
+```bash
+export RECFLARE_DOMAIN=rec.example.com
+```
+
 `just deploy` resolves the base domain at deploy time and passes it to wrangler —
 each worker is attached to its custom domain via `--domain <subdomain>.<domain>`,
 and the base domain is injected as the `DOMAIN` var so the `ns` service-discovery
 document and the api share-link base URL are built at runtime. Nothing in version
 control is rewritten; committed `wrangler.jsonc` files have no routes.
 
-The domain comes from the `RECFLARE_DOMAIN` environment variable; for local dev
-that's loaded from `.env`, and an already-exported value (e.g. a CI secret) takes
-precedence over the file. Per-app subdomain overrides come from
-`RECFLARE_SUBDOMAINS` (a JSON object, e.g. `{"playersettings":"settings"}`). For
-CI, set `RECFLARE_DOMAIN` as a secret and skip `.env` entirely:
+Per-app subdomain overrides come from
+`RECFLARE_SUBDOMAINS` (a JSON object, e.g. `{"playersettings":"settings"}`).
 
-```bash
-RECFLARE_DOMAIN=rec.example.com just deploy
-```
+**Run the development microservices:**
 
-**Run the development server:**
+@todo This works, but the nameserver document won't use local services. You could still
+call each service individually. Each instance of Wrangler runs on a different port number.
 
 ```bash
 just dev
@@ -215,7 +225,31 @@ command. Some key ones:
 
 For a single worker, scope with -F, e.g. `just deploy -F playersettings`.
 
-## Why a monorepo?
+## FAQ
+
+### What year is this for?
+
+This works with 2023 clients. It has been tested with manifest 7859140924515540835. Other clients may not work.
+
+See the "Client" section above for instructions on how to modify a client to connect to this server.
+
+### Can I run this locally on my PC?
+
+It's not currently supported. But theoretically, you could.
+
+See "Run the development server" above. It may be possible later as Wrangler will mock remote services. YMMV for now.
+
+### Can I use this to make my own server?
+
+Yes, that's the point.
+
+### Can I copy this project and modify it?
+
+Yes, see the (LICENSE)[LICENSE).
+
+I would love if you contributed your changes back.
+
+### Why a monorepo?
 
 The services share types, auth logic, and tooling, so keeping them in one repo
 keeps those in sync: `pnpm` workspaces share dependencies, `@repo/` packages