Design: server-side world persistence architecture
Decides where chunk/object content lives at rest and who may write it, now that there are two server-side processes per world (the always-on FastAPI backend and the per-join, reaper-killed Godot dedicated server). Decisions: chunk data lives in the existing Postgres DB (not world.md's per-world SQLite file); the FastAPI backend is the sole writer and the editor saves to it over HTTP; the dedicated server pulls content read-only at startup over a loopback /api/internal route with a per-spawn token; full-chunk PUT with base_revision instead of JSON-Patch deltas; the client streams chunks over HTTP through the existing ChunkStreamManager.set_server_rpc() seam. Adds docs/architecture/world_persistence_impl.md and marks the superseded sections of world.md (SS4, SS5) and editor.md (the request_chunk_edit path). Design only -- no implementation code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y2FESCaMXeJpC9gSctiEeD
This commit is contained in:
@@ -4,6 +4,11 @@
|
||||
> **Owner:** Platform team
|
||||
> **Related:** World chunk data format & persistence, server authority + client
|
||||
> prediction, content moderation & age verification, avatar component system
|
||||
> **Note:** the recommendation here stands, but edits do **not** ride the
|
||||
> `request_chunk_edit` ENet RPC (§4.2, §7.4). Per
|
||||
> [`world_persistence_impl.md`](world_persistence_impl.md) the editor saves
|
||||
> chunks over HTTP to the FastAPI backend, which is the sole writer; the
|
||||
> validation/moderation boundary moves with it.
|
||||
> **Godot version:** 4.6.2 stable
|
||||
|
||||
## 1. Overview
|
||||
|
||||
Reference in New Issue
Block a user