Two things:
1. FIX a live regression the async conversion missed: chat.js calls repos via the
lazy repos() helper (not the R. prefix), so my sweep skipped it — effectiveStatus
/ broadcastPresence read `repos().users.byId(userId)` synchronously, but that's a
Promise now, so presence broadcasts always reported status 'active' and dropped
last_seen. Now awaited (effectiveStatus/broadcastPresence async); touchSeen is a
fire-and-forget UPDATE with .catch. Audited all non-R. repo calls — only chat.js
was affected (media.js backfill was already awaited).
2. Swappable pub/sub for multi-instance real-time fan-out (the actual blocker to
running >1 instance — not the DB). server/pubsub.js picks a backend by
PUBSUB_BACKEND (default 'memory'). Local socket delivery is UNCHANGED; publish is
additive — memory = no-op (zero hot-path cost, identical single-instance
behaviour), redis = fan-out to other instances with a self-echo guard. chat.js
pushToUser/broadcastPresence now also publish; each instance subscribes to deliver
remote events to its local sockets. Interface is tiny so Redis is one swappable
file (Postgres LISTEN/NOTIFY or NATS could drop in the same way — never hardwired,
as requested). Dormant redis service added to compose behind the 'scale' profile;
redis dep added; PUBSUB_BACKEND/REDIS_URL documented.
Validated: smoke 22/22 (memory), e2e chat delivery green. NOTE: full multi-instance
also needs distributed presence (isOnline is per-process) + meeting-signaling
sharing — chat/presence fan out via this layer; those are follow-ups.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a dedicated Postgres 16 service (container bizgaze-postgres, own named volume
bizgaze_pg_data, healthcheck) on the shared NPM network. The app depends_on it
healthy. Inert until DB_BACKEND=pg is set in .env — default stays SQLite, so this
deploy changes nothing functionally; it just makes the engine available. Documented
POSTGRES_PASSWORD / DATABASE_URL / DB_BACKEND in .env.example.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Server streams the upload body straight to /data/uploads (a .part temp file, atomic rename on
success), backpressure-aware, so a 1 GB file never buffers in RAM. MAX_UPLOAD_MB env (default
1024 = 1 GB) controls the cap; error message reflects it.
- Client size guard raised 25 MB -> 1 GB.
- docker-compose documents MAX_UPLOAD_MB and the required Nginx Proxy Manager client_max_body_size.
NOTE: the actual bottleneck for the user's 9.7 MB reject is almost certainly NPM's client_max_body_size
(nginx default 1 MB) — that must be raised in the NPM admin; the app change alone can't lift it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Broken images: UPLOADS_DIR/REC_DIR/TRANS_DIR were server/<dir> INSIDE the image,
so every deploy.sh rebuild wiped uploaded files — old images 404'd ('broken
image') though their DB rows survived. Make them env-overridable and point prod
at /data/uploads|recordings|transcripts (persistent volume), matching DB/downloads.
NOTE: files already lost to prior rebuilds can't be recovered; new uploads persist.
- Duplicate notifications: harden connectChatWs — close/detach any prior socket
before opening a new one and keep a single pending reconnect timer, so a flaky
reconnect can't leave two live sockets delivering every event/notification twice.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The bundled livekit-client@2.20 uses signaling protocol 17 and the /rtc/v1 path,
which the v1.7 server didn't implement (404). The client fell back to the legacy
path, leaving the track publisher in a bad state so mic/cam publishing failed with
'InvalidAccessError: The sender was not created by this peer connection' — surfaced
to users as a misleading 'permission required' toast. v1.9 supports protocol 17.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The prod box is behind NAT (private 192.168.88.61 behind public 118.95.33.89), so
LiveKit auto-IP-detection would pick the wrong (outbound) address. Pin
rtc.node_ip=118.95.33.89 and collapse media to one UDP port (50000) + TCP 7881 to
minimize the upstream gateway port-forward the network team must add. Docs updated
with the exact forward table.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A normal deploy no longer starts the livekit container (it would crashloop with
empty keys before provisioning). Enable with 'docker compose --profile sfu up -d'.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds the server side of scaling meetings past the ~5-peer mesh:
- config.js: LIVEKIT_URL/API_KEY/API_SECRET + LIVEKIT_ENABLED flag. All optional;
when unset the app keeps the built-in P2P mesh (fully additive, like push).
- routes.js: GET /api/meetings/config (tells the client sfu on/off + wss url) and
POST /api/meetings/token (mints a per-user, per-room LiveKit join token — hand-rolled
HS256 JWT like the FCM/APNs tokens, no new dependency; secret stays server-side).
- docker-compose.yml: optional livekit service (single-node, no Redis), keys injected
via LIVEKIT_KEYS from the same .env; media over published UDP 50000-50100 + TCP 7881,
signaling proxied by NPM.
- livekit.yaml + .env.example documented.
Client (mesh->LiveKit media swap, behind the flag) lands in phase 2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- docker-compose: DOWNLOADS_DIR=/data/downloads so uploaded installers/latest.yml
survive image rebuilds (deploy.sh) instead of being wiped.
- DEPLOY.md: step-by-step for publishing a desktop release (build → upload the
3 feed files → verify) so the Download button + auto-update go live.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sravan
avinash