WIP checkpoint: Plan: Social — Friends, Chat & Groups

Verified all three options from the task against Godot 4.6.2 directly
(godot --headless), rather than trusting the probe scripts' own printed
output from earlier sessions:
- ScriptServer doesn't exist as a class; no disable_os/disable_file_access/
  disable_network project settings exist either. Nothing to configure.
- SubViewport isolates rendering/input only, not script capabilities — a
  script inside one has identical OS/FileAccess/network access.
- Expression is not safe by default (can still reach unsafe methods through
  a base instance); blocklisting dangerous substrings is trivially bypassed.

Recommendation: don't sandbox GDScript in-process (nothing to sandbox
with) — use a narrow non-Turing-complete content DSL for the common case,
and OS-level process isolation only if genuinely general scripting turns
out to be required.

docs/architecture/editor.md

@@ -0,0 +1,369 @@
+# Editor Architecture: Godot Editor Plugin vs. In-Game Editor
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** World chunk data format & persistence, server authority + client
+> prediction, content moderation & age verification, avatar component system
+> **Godot version:** 4.6.2 stable
+
+## 1. Overview
+
+This document evaluates the two primary ways to build the **world/level
+authoring tool** for **agp-game**:
+
+- **(a) Godot editor plugin** — extend the Godot editor itself with custom
+  panels, dock widgets, and tools that operate on the project's scenes and
+  resources.
+- **(b) In-game editor** — a fully custom editor built as game UI (Godot
+  `Control` nodes) that runs inside the running game, editing the game's own
+  world data.
+
+The goal is to pick the approach that best fits the platform's constraints:
+a **server-authoritative** multiplayer game where the **world is stored as
+versioned chunks** (see `world.md`), content is **moderation-flagged** (see
+`content_moderation.md`), and the client is a **shipped binary** that players
+run (not a dev tool).
+
+This document is a **decision record**: it lays out the trade-offs, gives a
+clear recommendation, and defines the resulting architecture boundaries.
+
+---
+
+## 2. Context & Constraints
+
+Before comparing the two approaches, we must fix the constraints that drive the
+decision. These come from the existing architecture docs.
+
+### 2.1 The World Is Data, Not Scenes
+
+`world.md` defines the world as **chunk data** (JSON for authoring, binary for
+runtime/network), persisted in SQLite on the server. A chunk is the atomic unit
+of load, save, and stream. The **server is the only writer** to the store;
+clients submit **deltas** against a `base_revision` and the server validates and
+applies them.
+
+**Implication:** The editor's output is **chunk payloads**, not `.tscn` scene
+files. Whatever editor we build must serialize to the chunk contract, not to
+Godot scene resources.
+
+### 2.2 Server-Authoritative & Moderation-Aware
+
+- The server validates every edit (schema, bounds, moderation) before
+  persisting (`world.md` §5.4).
+- Content carries **content flags** aggregated from referenced assets/scripts
+  (`content_moderation.md` §3). Mature content is gated behind age verification.
+- The client receives a **content manifest** and never loads content not in it.
+
+**Implication:** An editor that runs on a **player's machine** cannot be the
+authority on what gets published. Editing must go through the server's
+validation pipeline, and the editor must surface moderation flags.
+
+### 2.3 The Client Is a Shipped Binary
+
+The game is a multiplayer product. Players run a **release build**. The Godot
+editor is a **development tool** that players do not have.
+
+**Implication:** If authoring is a first-class *player* feature (user-generated
+content), the editor must ship inside the game binary. If authoring is a
+*developer/platform* feature, it can live in the editor.
+
+### 2.4 Two Distinct Audiences
+
+The evaluation must separate two audiences, because they have opposite needs:
+
+| Audience | Who | Where they run | What they build |
+|----------|-----|----------------|-----------------|
+| **Platform/dev** | The team building the game | Godot editor (dev machines) | Base worlds, rooms, templates, test levels |
+| **Players (UGC)** | End users | The shipped game | Their own rooms/worlds, published to the server |
+
+The two approaches map cleanly onto these audiences, and the right answer is
+likely **both** — but with a clear primary recommendation.
+
+---
+
+## 3. Approach (a): Godot Editor Plugin
+
+### 3.1 What It Is
+
+A Godot editor plugin is a set of scripts (and optionally scenes) that extend
+the editor via the `EditorPlugin` API. It can add:
+
+- **Dock panels** (`add_control_to_dock`) — e.g., a chunk/tile palette panel.
+- **Toolbar buttons** (`add_control_to_container`).
+- **Inspector plugins** (`EditorInspectorPlugin`) — custom property editors.
+- **Import plugins** (`EditorImportPlugin`) — custom asset importers.
+- **Scene/Node plugins** (`EditorNode3DGizmoPlugin`) — custom gizmos.
+- **Menu entries** (`add_tool_menu_item`).
+
+Plugins are enabled per-project via `project.godot` (`[editor_plugins]`).
+
+### 3.2 Pros
+
+- **Full editor power for free:** You get the scene tree, inspector, viewport
+  navigation, undo/redo, gizmos, and asset pipeline — all battle-tested.
+- **Native Godot editing:** Editing `.tscn` scenes, materials, and nodes is
+  exactly what the editor is built for. Great for authoring **base content**
+  (rooms, templates, avatar base bodies).
+- **Fast iteration for devs:** The platform team can build and test levels
+  directly in the tool they already use.
+- **Undo/redo, selection, snapping** come from the editor's `EditorUndoRedoManager`.
+- **No runtime footprint:** Editor-only code is stripped from export builds
+  (`@tool` scripts and editor plugins are not shipped to players).
+
+### 3.3 Cons
+
+- **Not available to players.** Players don't run the Godot editor. Any
+  player-facing UGC authoring cannot use this approach.
+- **Tied to the editor's UX.** You inherit the editor's look and interaction
+  model; deep customization is limited by what the editor API exposes.
+- **Editor API churn.** `EditorPlugin` APIs change between Godot versions;
+  plugins are more brittle across upgrades than game code.
+- **Scene-centric, not data-centric.** The editor is optimized for scenes and
+  resources. Our world is **chunk data** (`world.md`). We'd have to build a
+  translation layer (scene ↔ chunk) and keep it in sync — a real source of
+  drift.
+- **Single-user, local.** The editor edits local files. It does not natively
+  talk to our server-authoritative chunk store or the moderation pipeline.
+- **Headless/CI friction.** Validating plugin behavior in CI requires running
+  the editor headless, which is heavier than testing game code.
+
+### 3.4 Fit for Our Constraints
+
+- **Platform/dev authoring:** Excellent. This is the natural home for building
+  base worlds, rooms, and templates.
+- **Player UGC:** Not applicable. Players cannot run the editor.
+- **Server-authoritative chunk store:** Poor fit natively. The editor edits
+  local scenes; we'd bolt on a chunk export/import and a server sync layer.
+
+---
+
+## 4. Approach (b): In-Game Editor
+
+### 4.1 What It Is
+
+A fully custom editor built as **game UI** — Godot `Control` nodes (panels,
+buttons, toolbars) that run inside the running game. It edits the game's own
+world data model (chunks) and submits edits through the normal server pipeline.
+
+### 4.2 Pros
+
+- **Ships to players.** The editor is part of the game binary, so **player UGC
+  authoring is possible** — the core requirement for a user-generated-content
+  platform.
+- **Data-native.** The editor operates directly on the **chunk model**
+  (`world.md`), so there is no scene↔chunk translation layer and no drift.
+- **Server-authoritative by construction.** Edits go through the same
+  `request_chunk_edit` RPCs as gameplay, so validation, revisioning, and
+  moderation apply uniformly. The editor cannot bypass the server.
+- **Moderation-aware.** Because edits flow through the server, content flags are
+  computed and enforced at the boundary (`content_moderation.md` §4). The editor
+  can surface flags and gate mature content.
+- **One codebase, one UX.** The editor uses the same UI toolkit and art style as
+  the game; no separate editor theme to maintain.
+- **Testable in CI.** The editor is ordinary game code; it can be exercised
+  headlessly and unit-tested like any other system.
+
+### 4.3 Cons
+
+- **We build everything.** No free scene tree, inspector, gizmos, or undo/redo.
+  We must implement selection, snapping, undo/redo, viewport navigation, and
+  property editing ourselves.
+- **Runtime footprint.** Editor UI ships in the binary (though it can be gated
+  behind a feature flag / separate scene that is only instantiated on demand).
+- **More upfront work.** A usable in-game editor is a large feature; it needs
+  its own architecture (tool modes, gizmos, palette, inspector).
+- **Not ideal for deep asset authoring.** Modeling a mesh or authoring a
+  material is better done in the Godot editor / DCC tools. The in-game editor
+  should focus on **world composition** (placing tiles and objects), not asset
+  creation.
+
+### 4.4 Fit for Our Constraints
+
+- **Platform/dev authoring:** Workable but not ideal for deep asset work.
+- **Player UGC:** The **only** viable approach. Players can only author through
+  the shipped game.
+- **Server-authoritative chunk store:** Excellent fit. The editor is a client
+  that submits validated deltas.
+
+---
+
+## 5. Comparison Matrix
+
+| Criterion | (a) Editor plugin | (b) In-game editor |
+|-----------|-------------------|--------------------|
+| Ships to players | ❌ No | ✅ Yes |
+| Player UGC authoring | ❌ Impossible | ✅ Core capability |
+| World data model fit | ⚠️ Scene-centric; needs translation layer | ✅ Chunk-native |
+| Server-authoritative edits | ⚠️ Bolted on | ✅ Native (same RPCs) |
+| Moderation enforcement | ⚠️ Manual | ✅ At the boundary |
+| Free editor features (undo, gizmos, inspector) | ✅ Rich | ❌ Build ourselves |
+| Runtime footprint | ✅ None (stripped from export) | ⚠️ Ships in binary (gated) |
+| Dev iteration speed | ✅ Fast | ⚠️ Slower to build |
+| Deep asset authoring (mesh/material) | ✅ Native | ❌ Out of scope |
+| CI testability | ⚠️ Heavier (headless editor) | ✅ Ordinary game code |
+| Editor API churn risk | ⚠️ Higher | ✅ None (game code) |
+
+---
+
+## 6. Recommendation
+
+**Primary recommendation: build the in-game editor (b) as the platform's
+authoring surface, and use a lightweight Godot editor plugin (a) only as an
+internal dev convenience.**
+
+### 6.1 Rationale
+
+1. **Player UGC is the deciding factor.** The platform's value proposition is
+   user-generated content (rooms, worlds, avatars). Players cannot run the Godot
+   editor, so **only an in-game editor can deliver player authoring**. This is a
+   hard requirement that the editor-plugin approach cannot meet.
+
+2. **The world is data, and the in-game editor is data-native.** `world.md`
+   defines chunks as the atomic unit. An in-game editor edits chunks directly
+   and submits them through the server pipeline. An editor plugin would force a
+   scene↔chunk translation layer that is a constant source of drift and bugs.
+
+3. **Server authority and moderation fall out naturally.** Because in-game
+   edits use the same `request_chunk_edit` RPCs as gameplay, validation,
+   revisioning, optimistic concurrency, and content-flag enforcement
+   (`content_moderation.md`) apply uniformly. The editor cannot bypass the
+   server — which is exactly what a moderation-aware UGC platform needs.
+
+4. **The editor-plugin's strengths are not what we need.** Its free features
+   (scene tree, inspector, gizmos) are for editing Godot scenes and resources.
+   Our authoring is world composition against a chunk contract, not scene
+   editing. The plugin's main win — deep asset authoring — is better served by
+   DCC tools and the Godot editor for the *platform team*, not by a plugin we
+   must maintain.
+
+### 6.2 The Role of the Editor Plugin (Dev Convenience Only)
+
+We still recommend a **small, optional** editor plugin for the **platform team**
+to author **base content** (base rooms, templates, avatar base bodies, test
+levels) directly in the Godot editor. This is a dev-time convenience, not a
+product feature:
+
+- It can export a scene/resource as a **chunk** (reusing the same encoder as the
+  in-game editor) so dev-authored content flows into the same pipeline.
+- It is **not shipped** to players and is **not** the authoring surface for UGC.
+- It should be kept thin to minimize editor-API churn risk.
+
+### 6.3 Scope Boundary
+
+To keep the in-game editor tractable, define its scope clearly:
+
+- **In scope (world composition):** placing tiles, placing static/dynamic
+  objects, setting transforms, editing object properties, saving/loading chunks,
+  submitting edits to the server, showing moderation flags.
+- **Out of scope (asset creation):** modeling meshes, authoring materials,
+  rigging avatars. These are done in DCC tools / the Godot editor and imported
+  as catalog assets (see `avatar.md` §7). The in-game editor **references**
+  catalog assets by id; it does not create them.
+
+---
+
+## 7. Resulting Architecture
+
+### 7.1 Shared Editor Core
+
+Both the in-game editor and the (optional) dev plugin should share a single
+**editor core** that operates on the chunk model. This avoids two divergent
+implementations.
+
+```
+EditorCore (shared, data-native)
+├── ChunkEditorModel      # in-memory chunk being edited (tiles, objects, flags)
+├── ChunkEncoder          # JSON/binary encode/decode (world.md §3)
+├── EditSession           # base_revision tracking, delta generation
+├── EditSubmitter         # request_chunk_edit RPC wrapper + conflict handling
+├── UndoRedoStack         # command pattern over chunk mutations
+├── SelectionManager      # selected tiles/objects
+├── ToolRegistry          # brush, object-place, select, erase, etc.
+└── ModerationView        # surfaces content flags; gates mature content
+```
+
+### 7.2 In-Game Editor (Primary)
+
+```
+InGameEditor (Control-based UI, shipped in binary, gated by feature flag)
+├── EditorViewport        # custom 2D/3D viewport with camera navigation
+├── Toolbar               # tool mode switcher
+├── PalettePanel          # tile/object palette (from catalog)
+├── InspectorPanel        # property editor for selected object
+├── ChunkBrowser          # load/save chunks, list rooms
+└── EditorCore            # shared core (above)
+```
+
+- Instantiated only when the player enters "build mode" (a separate scene /
+  feature flag), so the runtime footprint is negligible during normal play.
+- Submits edits via `request_chunk_edit`; handles `chunk_edit_result` conflicts
+  by re-fetching and re-applying (`world.md` §5.4).
+
+### 7.3 Dev Editor Plugin (Optional, Thin)
+
+```
+DevChunkPlugin (EditorPlugin, dev-only, not shipped)
+├── Dock panel: "Chunk Export"
+├── Reads the current scene / selected nodes
+├── Maps scene content → chunk model (via EditorCore.ChunkEncoder)
+└── Exports a .chunk.json / submits to a dev server
+```
+
+Kept thin to minimize editor-API churn. Its only job is to let the platform team
+author base content in the editor and push it into the same chunk pipeline.
+
+### 7.4 Data Flow
+
+```
+[In-game editor]  --request_chunk_edit(delta, base_revision)-->  [Server]
+        ^                                                          | validate
+        |                                                          | apply
+        +--chunk_edit_result(ok/new_revision | conflict)-----------| persist
+                                                                   v
+                                                              SQLite (world.db)
+
+[Dev plugin]  --export chunk JSON-->  [EditorCore.ChunkEncoder]  -->  [Server]
+```
+
+Both paths converge on the **same server validation pipeline**, so moderation
+and revisioning are uniform regardless of authoring surface.
+
+---
+
+## 8. Risks & Mitigations
+
+| Risk | Mitigation |
+|------|------------|
+| In-game editor is a large build | Scope it to world composition (§6.3); reuse EditorCore; ship behind a feature flag |
+| Custom viewport/gizmos are hard | Start with a 2D tile editor (matches `CHUNK_SIZE_Z=1` default); add 3D later |
+| Undo/redo complexity | Use a command pattern over chunk mutations; test headlessly |
+| Editor-plugin API churn | Keep the plugin thin; treat it as dev-only convenience, not a product surface |
+| Drift between dev plugin and in-game editor | Both use the same `EditorCore`/`ChunkEncoder` |
+| Players bypass moderation | Impossible by construction: edits go through server validation |
+
+---
+
+## 9. Open Questions / Future Work
+
+- **3D editing:** The default world is flat (`CHUNK_SIZE_Z=1`). A 3D in-game
+  editor (volumetric chunks) is future work (`world.md` §8).
+- **Collaborative editing:** Multiple players editing the same chunk concurrently
+  — the optimistic-concurrency model already supports it, but the UX (live
+  cursors, conflict resolution) is unspecified.
+- **Template library:** A curated set of room templates players can start from.
+- **Publish/review flow:** How a player's authored room enters the moderation
+  review queue (`content_moderation.md` §6) and becomes publicly joinable.
+
+---
+
+## 10. Summary
+
+| Concern | Decision |
+|---------|----------|
+| Primary authoring surface | **In-game editor** (ships to players, enables UGC) |
+| Dev authoring convenience | Thin, optional **editor plugin** (not shipped) |
+| World data model | Both operate on the **chunk model** via a shared `EditorCore` |
+| Server authority | Edits go through `request_chunk_edit`; server validates |
+| Moderation | Enforced at the server boundary for both paths |
+| In-game editor scope | World composition only; asset creation is out of scope |
+| Runtime footprint | Editor gated behind a feature flag / separate scene |

docs/architecture/scripting_sandbox.md

@@ -0,0 +1,159 @@
+# GDScript Sandboxing for User-Written Scripts
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** Content moderation & age verification (scripts are one of the
+> three moderated content types), avatar component system
+
+## 1. Overview
+
+This document evaluates how to safely run **user-written scripts** as part of
+UGC (user-generated content) in **agp-game**, and recommends an approach.
+
+**Bottom line: Godot 4 has no built-in security sandbox for GDScript, and
+none of the three options named in the original task hold up under testing.**
+A script running anywhere inside the Godot process — however it's loaded,
+parented, or wrapped — runs with full engine privileges: arbitrary process
+execution, full filesystem read/write, and raw network access. Sandboxing
+has to happen *outside* the scripting language, not through an in-engine
+restriction mechanism, because no such mechanism exists.
+
+This was verified directly against Godot 4.6.2 (`godot --headless`, evidence
+in `sandbox_probe/` on this branch) rather than assumed from documentation,
+some of which (see §2.1) describes APIs that don't actually exist in this
+version.
+
+## 2. Options Evaluated
+
+### 2.1 Godot's built-in "ScriptServer" restrictions — does not exist
+
+There is no `ScriptServer` class in Godot 4.6.2:
+
+```
+ClassDB.class_exists("ScriptServer")  →  false
+```
+
+There's also no project setting to disable engine subsystems for scripts —
+none of `application/run/disable_os`, `disable_file_access`, or
+`disable_network` exist as settings, and `ProjectSettings.get_property_list()`
+returns nothing matching "sandbox", "restrict", or "security". Any plan that
+assumes a flag like this exists needs to be dropped; it was likely conflated
+with sandboxing features from a different engine/scripting ecosystem, or
+with **export template stripping** (which controls what ships in a build,
+not what a script can call at runtime).
+
+Directly probed capabilities of an ordinary GDScript running as a normal
+node script, no special setup:
+
+| Capability | Available to any script? |
+|---|---|
+| `OS.execute(...)` — run arbitrary processes | ✅ Yes |
+| `FileAccess.open(...)` — read/write any path the OS user can reach | ✅ Yes (read `/etc/hostname`, write `/tmp/...` both succeeded) |
+| `TCPServer` / `HTTPClient` / `HTTPRequest` / `PacketPeerUDP` / `WebSocketPeer` | ✅ All instantiate and work |
+| `ClassDB.instantiate(...)` — construct any engine class by name | ✅ Yes |
+| Loading and running a second script from source text at runtime (`GDScript.new()` + `.reload()`) | ✅ Yes |
+
+**Verdict: rejected.** There is nothing to configure here — the restriction
+surface this option assumed doesn't exist in the engine.
+
+### 2.2 Isolated SubViewport with a limited API — doesn't isolate scripts
+
+`SubViewport` is a **rendering and input isolation** primitive (it gives a
+scene subtree its own render target and can gate input propagation) — it is
+not a security or scripting boundary. A script attached to any node inside a
+`SubViewport` still runs in the same process, on the same GDScript VM, with
+the exact same access to `OS`, `FileAccess`, networking classes, and
+`ClassDB` as a script anywhere else in the tree. Nothing about being
+"inside" a SubViewport changes what API calls are reachable from a script.
+
+**Verdict: rejected.** This solves a rendering/UI-composition problem, not
+the security problem the task is asking about. Worth keeping in mind for
+other purposes (e.g. isolated preview rendering of user avatars), but it
+provides zero script sandboxing.
+
+### 2.3 Custom GDScript interpreter with an allowlist — right idea, wrong layer for "custom interpreter"
+
+Two ways to read this option, tested separately:
+
+**(a) Write/embed a separate GDScript parser+interpreter.** Not
+practical — this means re-implementing (and then indefinitely maintaining,
+in lockstep with every Godot release) a full language interpreter outside
+the engine. Far more engineering than the problem justifies.
+
+**(b) Use Godot's built-in `Expression` class as a restricted subset.**
+`Expression` *looks* like a natural allowlist mechanism — it only evaluates
+a single expression, no control flow, no arbitrary statements. But it isn't
+safe by default: it can still reach through to unsafe engine methods if you
+aren't careful about what object you hand it as a base instance:
+
+```gdscript
+var expr = Expression.new()
+expr.parse("get_environment('HOME')", ["OS"])
+expr.execute([], OS)   # → "/home/daddy"  (successfully called OS.get_environment)
+```
+
+So `Expression` is a viable building block only if the host **never passes
+a base instance (or arguments) that exposes anything sensitive** — i.e. the
+allowlisting work still has to happen at the call site, `Expression` itself
+enforces none of it.
+
+**Static text pattern-matching (blocklisting dangerous substrings like
+`"OS.execute"` before parsing) was also probed and is not a real
+defense** — it's trivially defeated by string concatenation, `call()`,
+`Callable`, or any other indirection, and produces false confidence.
+
+**Verdict: partially viable, but only as a foundation, not a solution on
+its own.** A hand-built, narrow, data-driven DSL (not full GDScript, not
+raw `Expression`) with an explicit allowlist of safe operations and *no
+ability to reference engine singletons or arbitrary objects* is the only
+version of "custom interpreter" that's actually safe. This is real
+engineering effort, not a config flag.
+
+## 3. Recommendation
+
+**Don't run untrusted GDScript in-process at all.** Given none of the three
+in-engine options provide a real boundary, the two approaches actually worth
+building are, in order of recommended priority:
+
+1. **Primary: a narrow, non-Turing-complete content DSL**, not general
+   scripting. Most UGC scripting needs in a game like this (custom
+   interactions, simple triggers, item behaviors) don't need a general
+   programming language — they need a small set of declarative
+   verbs/conditions (e.g. `on_interact: give_item("torch")`,
+   `on_enter: play_sound("chime")`). Expressed as data (JSON/Resource, not
+   code) and interpreted by trusted, hand-written GDScript on the engine
+   side. This has *zero* attack surface by construction — there's no
+   interpreter to escape because there's no general execution, just a
+   fixed, reviewed set of verbs. This is almost certainly sufficient for
+   the actual UGC use cases in this game and should be scoped against real
+   feature requirements before assuming more is needed.
+
+2. **If genuinely general scripting becomes a hard requirement**, isolate it
+   at the OS level, not the engine level: run untrusted scripts in a
+   **separate process** (a stripped-down Godot instance or a dedicated
+   interpreter) under OS sandboxing (a restricted user account, a
+   container, or `firejail`/`bwrap`/seccomp), communicating with the main
+   game over a narrow IPC/RPC boundary that only exposes intentionally-safe
+   operations. This is the only approach that provides a real security
+   boundary for arbitrary code, because it doesn't depend on the scripting
+   language cooperating — the OS enforces it. Substantially more
+   infrastructure than option 1; only worth it if option 1's DSL genuinely
+   can't express what's needed.
+
+**Do not** attempt in-process GDScript sandboxing via SubViewport,
+ScriptServer, or ad hoc blocklisting — all three were directly tested and
+none provide a real boundary (§2).
+
+## 4. Open Questions
+
+- What do actual planned UGC scripts need to *do*? (Trigger conditions,
+  simple item/state effects, dialogue branching?) This determines whether
+  the DSL in §3.1 is sufficient or whether §3.2's process isolation is
+  needed. Needs a concrete feature list before implementation starts.
+- If §3.2 is needed later, does it run per-user-session or shared/pooled?
+  Affects resource cost and isolation guarantees.
+- Interaction with the content moderation pipeline (`content_moderation.md`):
+  scripts as a moderated content type still need a moderation flag path
+  regardless of which execution model is chosen — a DSL makes static
+  analysis of *what a script can possibly do* far easier than it would be
+  for general code, which is an additional point in its favor.

docs/planning/social.md

@@ -0,0 +1,170 @@
+# Social — Friends, Chat & Groups — Plan
+
+> **Status:** Planned
+> **Owner:** Platform team
+> **Feature ID:** `social`
+> **Godot version:** 4.6.2 stable
+> **Backend:** FastAPI + SQLAlchemy (async) + PostgreSQL + Redis
+
+## 1. Overview
+
+This document breaks the **Social** feature into user stories and right-sized
+implementation tasks. The feature delivers:
+
+- **Friends & following** — a friend request/accept model plus a one-way follow
+  relationship, with block lists.
+- **Presence & status** — online/offline, custom status message, last-seen.
+- **Chat** — direct messages (DM) and in-experience (world/room) chat with
+  **first-class safety**: server-side text filtering, report-message, and rate
+  limiting.
+- **Groups** — named groups with roles (owner/admin/member) and a simple group
+  page.
+- **Public profiles** — avatar, bio, favorite experiences, and a friends list
+  that respects privacy settings.
+
+## 2. Why chat safety is the differentiator
+
+The platform is explicitly meant to pull adults away from a youth-oriented
+competitor. Chat is the highest-risk surface: it is real-time, user-generated,
+and where abuse happens fastest. Safety is therefore treated as a **blocking
+requirement**, not an add-on:
+
+- Every message passes a **server-side text filter** before it is stored or
+  delivered. The client filter is cosmetic only; the server is authoritative.
+- Every message can be **reported**; reports flow into a moderation queue with
+  actor + reason + audit trail (mirroring `content_moderation.md`).
+- Sending is **rate limited** per user (Redis token bucket) to stop flooding and
+  harassment-by-volume.
+- Report and block are always reachable from a message context in the UI.
+
+## 3. Existing constraints (do not re-build)
+
+- **Auth:** JWT bearer tokens; `get_current_user` / `CurrentUser` dependency in
+  `app/dependencies.py`. All social endpoints reuse this.
+- **DB:** async SQLAlchemy + Alembic; migration `0001_initial` is the head.
+- **Redis:** configured (`REDIS_URL`) but unused so far; adopted here for
+  presence and rate limiting.
+- **Models:** `User`, `World` (owner_id), `Asset` (owner_id, is_public). Avatars
+  and favorite-experience references point at existing rows.
+- **Client:** Godot 4.6.2, minimal `main_menu.gd`; no social UI yet.
+
+## 4. Key design decisions
+
+| Concern | Decision |
+|---|---|
+| Message transport | REST for send/history; **WebSocket** gateway for real-time delivery + presence (matches `networking.md`'s "WebSocket as secondary transport" for chat) |
+| Presence store | Redis (TTL heartbeat) + persisted `last_seen_at` on the user record |
+| Text filtering | Pluggable `TextFilter` interface with a deterministic default (profanity list + normalization) so it runs without external services; third-party hook later |
+| Rate limiting | Redis token-bucket dependency, reusable across all social endpoints |
+| Reports | `message_reports` table + moderation endpoints (list/review/resolve) with audit fields |
+| Friends vs. follow | Friends = mutual (request→accept). Follow = one-way (no approval). Block = hard deny that also hides content and prevents DMs |
+| Privacy | Per-user settings JSON (`profile_visibility`, `friends_list_visibility`, `favorites_visibility`) enforced server-side on every read |
+| Groups | `groups` + `group_members` (role: owner/admin/member) + group page aggregate endpoint |
+| Real-time | One WebSocket endpoint multiplexing presence, DM, and world-chat messages via Redis pub/sub |
+
+## 5. User stories
+
+### US-1 Friends & following
+As a player, I can send a friend request, accept/decline incoming requests,
+unfriend, follow/unfollow other players, and block users so they can't interact
+with me.
+
+**Acceptance criteria**
+- Friend requests are one-directional until accepted; accepted friendships are mutual.
+- Follow is one-way and requires no approval.
+- Block prevents DMs, hides the blocked user's profile/friends interactions, and
+  removes any existing friendship/follow between the two.
+- Duplicate/self requests are rejected idempotently.
+
+### US-2 Presence & status
+As a player, I can see whether my friends are online, their custom status, and
+when they were last seen.
+
+**Acceptance criteria**
+- Online/offline is derived from a server-side heartbeat (Redis TTL), not client claims.
+- `last_seen_at` persists and is visible (subject to privacy settings).
+- Custom status text is optional and length-limited.
+
+### US-3 Public profiles
+As a player, I can view a public profile page showing avatar, bio, favorite
+experiences, and a friends list that respects the owner's privacy settings.
+
+**Acceptance criteria**
+- Avatar and bio are editable by the owner only.
+- Favorite experiences reference existing `World` rows.
+- A viewer sees only the sections the owner's privacy settings allow; blocked
+  users see a restricted view.
+
+### US-4 Chat (DM + in-experience) with safety
+As a player, I can send direct messages and chat inside a world/room. Messages
+are filtered, rate limited, and reportable.
+
+**Acceptance criteria**
+- Server filters message text before storing/delivering; filtered content is either
+  rejected (blocking) or redacted (configurable per filter policy).
+- Send rate is limited per user (token bucket); excess sends get `429`.
+- Every message has a stable id, author, timestamp, and conversation/world scope.
+- Any message can be reported with a reason; reports are stored and reviewable.
+- Real-time delivery over WebSocket with REST fallback for history.
+
+### US-5 Groups
+As a player, I can create a group, join/leave groups, and (as owner/admin)
+manage roles and view a simple group page.
+
+**Acceptance criteria**
+- Each group has exactly one owner and any number of admins/members.
+- Role transitions are authorized (only owner can transfer ownership or promote/demote admins).
+- Group page lists name, description, member list with roles, and member count.
+
+### US-6 Godot client
+As a player, I can access friends, presence, chat, profiles, and groups from the
+game UI.
+
+**Acceptance criteria**
+- An API client handles JWT auth, HTTP, and WebSocket for all social calls.
+- Dedicated screens/panels: friends+presence, DM & world chat (with report),
+  profile page, group page.
+- Client-side filtering is cosmetic; server responses remain authoritative.
+
+## 6. Task breakdown
+
+Right-sized to 1–3 files / one coherent piece of functionality each. Task IDs
+are sequential for dependency chaining.
+
+| # | Task | Story | Depends on |
+|---|------|-------|-----------|
+| 1 | Friends/follow/block models + Alembic migration | US-1 | — |
+| 2 | Friends & follow API router | US-1 | 1 |
+| 3 | Presence & status model + endpoints (Redis heartbeat) | US-2 | — |
+| 4 | Profile model + migration + own-profile endpoints | US-3 | 1 |
+| 5 | Public profile view + favorites + privacy enforcement | US-3 | 2, 4 |
+| 6 | Chat data models + migration (conversations, messages, reports) | US-4 | — |
+| 7 | Text filtering service + profanity config | US-4 | — |
+| 8 | Redis rate-limiting dependency | US-4 | — |
+| 9 | DM chat send/list endpoints (filter + rate limit) | US-4 | 6, 7, 8 |
+| 10 | Report-message endpoint + moderation queue | US-4 | 6, 9 |
+| 11 | In-experience (world/room) chat endpoints | US-4 | 9 |
+| 12 | Real-time WebSocket gateway (presence + DM + world chat) | US-4 | 3, 9, 11 |
+| 13 | Group + membership models + migration | US-5 | — |
+| 14 | Groups API (CRUD, join/leave, roles, group page) | US-5 | 13 |
+| 15 | Godot API client (auth + HTTP + WebSocket) | US-6 | 2 |
+| 16 | Godot friends & presence UI | US-6 | 3, 15 |
+| 17 | Godot chat UI (DM + world chat + report) | US-6 | 12, 15 |
+| 18 | Godot profile page UI | US-6 | 5, 15 |
+| 19 | Godot groups UI + group page | US-6 | 14, 15 |
+
+## 7. Phasing
+
+- **Phase 1 (data + core APIs):** tasks 1–5 (friends, presence, profiles).
+- **Phase 2 (chat safety — the differentiator):** tasks 6–12 (chat + safety +
+  realtime). This is the critical path and highest priority.
+- **Phase 3 (groups):** tasks 13–14.
+- **Phase 4 (client):** tasks 15–19, each landing after its backend dependency.
+
+## 8. Out of scope for this feature
+
+- Age verification / maturity gating (covered by `content_moderation.md`).
+- Voice chat, media/image messages, message editing/deletion history.
+- Third-party profanity/toxicity vendors (the `TextFilter` interface leaves a
+  hook, but the default is deterministic and dependency-free).
+- Mobile push notifications.

sandbox_probe/.godot/.gdignore

@@ -0,0 +1 @@
+

sandbox_probe/probe6.gd

@@ -0,0 +1,174 @@
+extends Node
+
+func _ready():
+	print("=== SANDBOX PROBE 6: Corrected Evidence Gathering (Godot 4.6.2) ===")
+	probe_script_loading()
+	probe_os_apis()
+	probe_file_access()
+	probe_network()
+	probe_classdb()
+	probe_expression_engine()
+	probe_engine_singletons()
+	probe_worker_threads()
+	probe_project_settings()
+	probe_allowlist()
+	print("=== SANDBOX PROBE 6 END ===")
+	get_tree().quit()
+
+func probe_script_loading():
+	print("--- Script loading ---")
+	var gd = GDScript.new()
+	gd.source_code = "extends RefCounted\nfunc hello():\n\treturn 42\n"
+	var err = gd.reload()
+	print("GDScript.reload() from source_code err=", err)
+	if err == OK:
+		var inst = gd.new()
+		print("  instantiated, hello()=", inst.call("hello"))
+	var res = load("res://test_script.gd")
+	print("load('res://test_script.gd') = ", res)
+	if res:
+		print("  get_source_code() available: ", res.has_method("get_source_code"))
+	print("  GDScript instance has 'get_ast': ", gd.has_method("get_ast"))
+	print("  GDScript instance has 'get_parser': ", gd.has_method("get_parser"))
+	print("  GDScript instance has 'get_script_method_list': ", gd.has_method("get_script_method_list"))
+	print("  GDScript instance has 'get_script_property_list': ", gd.has_method("get_script_property_list"))
+
+func probe_os_apis():
+	print("--- OS APIs ---")
+	var out = []
+	var exit_code = OS.execute("echo", ["hello"], out)
+	print("OS.execute('echo') exit=", exit_code, " out=", out)
+	print("OS.get_environment('HOME') = ", OS.get_environment("HOME"))
+	print("OS has 'create_process': ", OS.has_method("create_process"))
+	print("OS.get_cmdline_args() = ", OS.get_cmdline_args())
+	print("OS.get_user_data_dir() = ", OS.get_user_data_dir())
+	print("OS.get_executable_path() = ", OS.get_executable_path())
+
+func probe_file_access():
+	print("--- File access ---")
+	var f = FileAccess.open("/etc/hostname", FileAccess.READ)
+	print("FileAccess.open('/etc/hostname') = ", f)
+	if f:
+		print("  content: ", f.get_as_text())
+		f.close()
+	var w = FileAccess.open("/tmp/godot_probe_write.txt", FileAccess.WRITE)
+	print("FileAccess.open('/tmp/...', WRITE) = ", w)
+	if w:
+		w.store_string("probe")
+		w.close()
+		print("  wrote to /tmp OK")
+	var dir = DirAccess.open("/")
+	print("DirAccess.open('/') = ", dir)
+	if dir:
+		var names = dir.get_files()
+		print("  root files count: ", names.size())
+	var res_dir = DirAccess.open("res://")
+	print("DirAccess.open('res://') = ", res_dir)
+	var user_dir = DirAccess.open("user://")
+	print("DirAccess.open('user://') = ", user_dir)
+
+func probe_network():
+	print("--- Network ---")
+	var tcp = TCPServer.new()
+	var bind_err = tcp.listen(0)
+	print("TCPServer.listen(0) err=", bind_err)
+	var http = HTTPClient.new()
+	print("HTTPClient instantiated: ", http != null)
+	var http_req = HTTPRequest.new()
+	print("HTTPRequest instantiated: ", http_req != null)
+	var udp = PacketPeerUDP.new()
+	print("PacketPeerUDP instantiated: ", udp != null)
+	var ws = WebSocketPeer.new()
+	print("WebSocketPeer instantiated: ", ws != null)
+
+func probe_classdb():
+	print("--- ClassDB ---")
+	print("ClassDB.class_exists('OS'): ", ClassDB.class_exists("OS"))
+	print("ClassDB.class_exists('FileAccess'): ", ClassDB.class_exists("FileAccess"))
+	print("ClassDB.class_exists('TCPServer'): ", ClassDB.class_exists("TCPServer"))
+	print("ClassDB.class_exists('HTTPClient'): ", ClassDB.class_exists("HTTPClient"))
+	var class_list = ClassDB.get_class_list()
+	print("ClassDB.get_class_list() count: ", class_list.size())
+	var os_methods = ClassDB.class_get_method_list("OS")
+	print("OS method count: ", os_methods.size())
+	var inst = ClassDB.instantiate("Node")
+	print("ClassDB.instantiate('Node') = ", inst)
+	print("ClassDB has 'class_get_singleton': ", ClassDB.has_method("class_get_singleton"))
+
+func probe_expression_engine():
+	print("--- Expression engine ---")
+	var expr = Expression.new()
+	var err = expr.parse("1 + 2")
+	print("Expression.parse('1 + 2') err=", err)
+	if err == OK:
+		var result = expr.execute()
+		print("  Expression.execute() = ", result)
+	var expr2 = Expression.new()
+	err = expr2.parse("OS.get_environment('HOME')")
+	print("Expression.parse('OS.get_environment') err=", err)
+	if err == OK:
+		var result2 = expr2.execute()
+		print("  Expression.execute() = ", result2)
+	var expr3 = Expression.new()
+	err = expr3.parse("get_environment('HOME')", ["OS"])
+	print("Expression.parse with base_instance err=", err)
+	if err == OK:
+		var result3 = expr3.execute([], OS)
+		print("  Expression.execute with OS base = ", result3)
+	var expr4 = Expression.new()
+	err = expr4.parse("FileAccess.open('/etc/hostname', 1)")
+	print("Expression.parse('FileAccess.open') err=", err)
+	if err == OK:
+		var result4 = expr4.execute()
+		print("  Expression.execute() = ", result4)
+	var expr5 = Expression.new()
+	err = expr5.parse("get_tree().quit()")
+	print("Expression.parse('get_tree().quit()') err=", err)
+	if err == OK:
+		var result5 = expr5.execute()
+		print("  Expression.execute() = ", result5)
+
+func probe_engine_singletons():
+	print("--- Engine singletons ---")
+	print("Engine has 'remove_singleton': ", Engine.has_method("remove_singleton"))
+	print("Engine has 'add_singleton': ", Engine.has_method("add_singleton"))
+	print("Engine.get_main_loop() = ", Engine.get_main_loop())
+
+func probe_worker_threads():
+	print("--- Worker threads ---")
+	var thread = Thread.new()
+	print("  Thread.new() = ", thread)
+	print("  WorkerThreadPool has 'add_task': ", WorkerThreadPool.has_method("add_task"))
+
+func probe_project_settings():
+	print("--- Project settings ---")
+	var settings = ProjectSettings.get_property_list()
+	var relevant = []
+	for s in settings:
+		var name = String(s.name)
+		if "sandbox" in name.to_lower() or "restrict" in name.to_lower() or "security" in name.to_lower():
+			relevant.append(name)
+	print("  Sandbox/security project settings: ", relevant)
+	print("  ProjectSettings has 'application/run/disable_os': ", ProjectSettings.has_setting("application/run/disable_os"))
+	print("  ProjectSettings has 'application/run/disable_file_access': ", ProjectSettings.has_setting("application/run/disable_file_access"))
+	print("  ProjectSettings has 'application/run/disable_network': ", ProjectSettings.has_setting("application/run/disable_network"))
+	print("  ProjectSettings has 'set_setting': ", ProjectSettings.has_method("set_setting"))
+	print("  ProjectSettings has 'save': ", ProjectSettings.has_method("save"))
+
+func probe_allowlist():
+	print("--- Allowlist / static analysis ---")
+	var dangerous_patterns = [
+		"OS.execute", "OS.create_process", "OS.get_environment",
+		"FileAccess.open", "DirAccess.open", "TCPServer", "HTTPClient",
+		"load(", "preload(", "ClassDB", "Engine.get_main_loop",
+		"get_tree().quit", "ProjectSettings"
+	]
+	var test_script = """extends Node
+func _ready():
+	var f = FileAccess.open("/etc/passwd", FileAccess.READ)
+	OS.execute("rm", ["-rf", "/"])
+"""
+	print("  Test script contains dangerous patterns:")
+	for p in dangerous_patterns:
+		if p in test_script:
+			print("    DETECTED: ", p)

sandbox_probe/probe6.tscn

@@ -0,0 +1,6 @@
+[gd_scene load_steps=2 format=3]
+
+[ext_resource type="Script" path="res://probe6.gd" id="1"]
+
+[node name="Probe6" type="Node"]
+script = ExtResource("1")

sandbox_probe/project.godot

@@ -0,0 +1,8 @@
+; Engine configuration file.
+config_version=5
+
+[application]
+
+config/name="sandbox_probe"
+run/main_scene="res://probe6.tscn"
+config/features=PackedStringArray("4.6")

sandbox_probe/test_script.gd

@@ -0,0 +1,4 @@
+extends RefCounted
+
+func hello():
+	return "from test_script.gd"