Skip to main content

Spheres

System architecture

Chartflow aligned with the implementation plan: real-time on Socket.io, Firebase for auth + sparse writes, no Firestore as game bus.

Runtime stack

Browser · React + Vite + R3F

3D world, flight controls, HUD, Socket.io client, Zustand — no world truth in Firestore listeners

Firebase · Auth + Firestore (sparse)

Profiles, aura, core rating, reports — not positions, presence, or chat history

World server · Node + Socket.io

Token verify (Admin SDK), WorldState in memory, relay chat, AI spheres, throttle 10 Hz

Deploy & config (typical)

Web host

Vercel / Firebase Hosting

Railway

world-server · PORT + secrets

Env

VITE_* · CORS_ORIGINS · SA key

Real-time loop

One sync path from login token to smooth remote spheres.

1

Auth

Firebase ID token in client

2

join_world

Socket + token verify (Admin)

3

World state

In-memory Map per worldId

4

update_state

10 Hz throttle per client

5

Broadcast

player_update to peers

6

Render

Interpolation + R3F

Cost safety · data boundaries

Rules from the plan — keep Firebase bills predictable and privacy intact.

Firestore writes only: registration, debounced aura, core rating after chat, rare reports — target < 100 reads/writes per test session for two users.

Repo layout

pnpm workspace — shared protocol types, thin boundaries between apps.

spheres/
├── apps/web          → Vite · React · R3F · pages · stores · i18n
├── apps/world-server → Express · Socket.io · auth · world · AI
└── packages/shared   → types · protocol · constants

Implementation phases

Plan phases (checklist in repo) — condensed labels for orientation.

1

P1

Monorepo · web + world-server + shared

2

P2

Auth · account · aura · R3F preview

3

P3

World · flight · HUD

4

P4

Presence · sync · AI spheres

5

P5

Proximity · contact handshake

6

P6

Chat relay · no persistence

7

P7

Rating · core → Firestore

8

P8

Deploy · Railway + hosting

Design choices

Source of truth for tasks and env tables: PLAN.md in the Spheres repo.