Feat: Enable virtual RuView execution with Colab and ngrok

[iamaanahmad]

This Pull Request introduces a new Colab notebook and updates to the project's documentation to enable users to run the RuView project virtually using Google Colab and ngrok.

This integration allows for easy setup and execution of the wifi-densepose-sensing-server in a cloud environment, making the project more accessible for development, testing, and demonstration without requiring a local setup.

Key Changes

• New Colab Notebook: Provides a step-by-step guide to clone the RuView repository, install dependencies, run the sensing server, and expose it via ngrok.
• NGROK_AUTH_TOKEN and NGROK_HOST handling: Instructions are provided within the Colab notebook and the updated README on how to obtain and configure ngrok tokens and hostnames securely.
• Updated README: The main README (README.md) has been updated with a concise section outlining how to run the project virtually using the provided Colab notebook.

How to Use

1. Open the Colab notebook (link available in the README).
2. Follow the instructions to set your NGROK_AUTH_TOKEN and NGROK_HOST.
3. Run all cells to launch the wifi-densepose-sensing-server and get a public ngrok URL.

This significantly lowers the barrier to entry for new contributors and users to experiment with RuView.

[ruvnet]

Nice for accessibility — a one-click Colab demo is great. One security issue to address before merge, though, because this puts the sensing surface on the public internet (not just a LAN):

The notebook exposes the sensing API + live stream unauthenticated. Cell 5/6 run:

sensing-server --bind-addr 0.0.0.0 --http-port 3000     # no RUVIEW_API_TOKEN
ngrok.connect(3000, "http")                              # → public URL

With no RUVIEW_API_TOKEN, /api/v1/* bearer auth is a no-op (see #864). The only guard here is SENSING_ALLOWED_HOSTS (host-header validation), which is not authentication — it stops browser DNS-rebinding, not a direct client. So anyone who has (or scans for) the ngrok URL can read:

• GET /api/v1/sensing/latest, GET /api/v1/pose/current
• WS /ws/sensing — the live presence/pose/vitals stream

ngrok-free hostnames are public and enumerable, so this is effectively "publish live in-room sensing to the internet."

Suggested fixes (any one closes the REST hole; do the tunnel one to also cover the WS):

1. Generate and set a token before launching, and print it for the user:

   import secrets; API_TOKEN = secrets.token_urlsafe(24)
   env["RUVIEW_API_TOKEN"] = API_TOKEN
   print("API token (send as 'Authorization: Bearer …'):", API_TOKEN)

   Note (per Docker default exposes unauthenticated sensing API and /ws/sensing stream #864): this protects /api/v1/* but /ws/sensing is intentionally outside bearer auth, so the live stream is still open.
2. Best for a public demo — put auth on the tunnel itself, which covers REST and WS:

   ngrok.connect(3000, "http", auth="demo:<password>")   # basic-auth on the tunnel
   # or ngrok OAuth: oauth_provider=..., oauth_allow_emails=[...]

3. At minimum, a prominent ⚠️ in the notebook + README that this publishes unauthenticated live sensing data publicly, and to stop the tunnel when done.

I'd go with #2 (tunnel auth) as the default in the notebook — it's the only option that also protects /ws/sensing. Happy to suggest the exact cell edit if useful.