WIP checkpoint: Plan: Discovery — Browse, Search & Home

backend/alembic/versions/0002_add_date_of_birth_to_users.py

@@ -0,0 +1,30 @@
+"""add date_of_birth column to users table
+
+Revision ID: 0002_add_date_of_birth_to_users
+Revises: 0001_initial
+Create Date: 2025-01-01 00:00:00.000000
+
+"""
+from typing import Sequence, Union
+
+from alembic import op
+import sqlalchemy as sa
+
+# revision identifiers, used by Alembic.
+revision: str = "0002_add_date_of_birth_to_users"
+down_revision: Union[str, None] = "0001_initial"
+branch_labels: Union[str, Sequence[str], None] = None
+depends_on: Union[str, Sequence[str], None] = None
+
+
+def upgrade() -> None:
+    """Add date_of_birth column to users table."""
+    op.add_column(
+        "users",
+        sa.Column("date_of_birth", sa.Date(), nullable=True),
+    )
+
+
+def downgrade() -> None:
+    """Remove date_of_birth column from users table."""
+    op.drop_column("users", "date_of_birth")

backend/app/models/user.py

@@ -1,4 +1,7 @@
-from sqlalchemy import Column, Integer, String, Boolean, DateTime
+from datetime import date
+from typing import Optional
+
+from sqlalchemy import Column, Integer, String, Boolean, DateTime, Date
 from sqlalchemy.orm import relationship
 from sqlalchemy.sql import func
 
@@ -12,6 +15,7 @@ class User(Base):
     username = Column(String(50), unique=True, index=True, nullable=False)
     email = Column(String(120), unique=True, index=True, nullable=False)
     hashed_password = Column(String(255), nullable=False)
+    date_of_birth = Column(Date, nullable=True)
     is_active = Column(Boolean, default=True)
     created_at = Column(DateTime(timezone=True), server_default=func.now())
     updated_at = Column(DateTime(timezone=True), onupdate=func.now())
@@ -19,3 +23,15 @@ class User(Base):
     sessions = relationship("Session", back_populates="user", cascade="all, delete-orphan")
     worlds = relationship("World", back_populates="owner")
     assets = relationship("Asset", back_populates="owner")
+
+    @property
+    def is_adult(self) -> bool:
+        """Return True if the user is 18 or older based on date_of_birth."""
+        if self.date_of_birth is None:
+            return False
+        today = date.today()
+        age = today.year - self.date_of_birth.year
+        # Adjust if birthday hasn't occurred yet this year
+        if (today.month, today.day) < (self.date_of_birth.month, self.date_of_birth.day):
+            age -= 1
+        return age >= 18

backend/app/routers/auth.py

@@ -1,10 +1,10 @@
 """Authentication router - login, register, token refresh."""
 
-from datetime import datetime, timedelta, timezone
+from datetime import date, datetime, timedelta, timezone
 
 from fastapi import APIRouter, Depends, HTTPException, status
 from fastapi.security import OAuth2PasswordRequestForm
-from pydantic import BaseModel, EmailStr
+from pydantic import BaseModel, EmailStr, field_validator
 
 from jose import jwt
 from passlib.context import CryptContext
@@ -32,12 +32,24 @@ class RegisterRequest(BaseModel):
     username: str
     email: EmailStr
     password: str
+    date_of_birth: str  # ISO format date string (YYYY-MM-DD)
+
+    @field_validator("date_of_birth")
+    @classmethod
+    def validate_date_of_birth(cls, v: str) -> str:
+        """Validate that the date string is a valid date in YYYY-MM-DD format."""
+        try:
+            datetime.strptime(v, "%Y-%m-%d")
+        except ValueError:
+            raise ValueError("date_of_birth must be in YYYY-MM-DD format")
+        return v
 
 
 class UserResponse(BaseModel):
     id: int
     username: str
     email: str
+    date_of_birth: str | None = None
     is_active: bool
     created_at: datetime | None = None
 
@@ -65,11 +77,44 @@ def hash_password(password: str) -> str:
     return pwd_context.hash(password)
 
 
+def calculate_age(birth_date: date, today: date | None = None) -> int:
+    """Calculate age in years from a birth date.
+
+    Args:
+        birth_date: The person's date of birth.
+        today: The reference date. Defaults to today's date (UTC).
+
+    Returns:
+        Age in whole years as of the reference date.
+    """
+    if today is None:
+        today = datetime.now(timezone.utc).date()
+
+    age = today.year - birth_date.year
+    # Adjust if birthday hasn't occurred yet this year
+    if (today.month, today.day) < (birth_date.month, birth_date.day):
+        age -= 1
+    return age
+
+
 # --- Endpoints ---
 
 @router.post("/register", response_model=TokenResponse, status_code=status.HTTP_201_CREATED)
 async def register(req: RegisterRequest, db: AsyncSession = Depends(get_db)):
-    """Register a new user and return an access token."""
+    """Register a new user and return an access token.
+
+    Requires date_of_birth and rejects users under 18.
+    """
+    # Parse and validate date_of_birth
+    dob = datetime.strptime(req.date_of_birth, "%Y-%m-%d").date()
+    age = calculate_age(dob)
+
+    if age < 18:
+        raise HTTPException(
+            status_code=status.HTTP_400_BAD_REQUEST,
+            detail=f"Must be 18 or older to register (provided date of birth: {req.date_of_birth})",
+        )
+
     # Check if username already exists
     result = await db.execute(select(User).where(User.username == req.username))
     if result.scalar_one_or_none():
@@ -90,6 +135,7 @@ async def register(req: RegisterRequest, db: AsyncSession = Depends(get_db)):
         username=req.username,
         email=req.email,
         hashed_password=hash_password(req.password),
+        date_of_birth=dob,
     )
     db.add(user)
     await db.commit()

backend/pytest.ini

@@ -0,0 +1,3 @@
+[pytest]
+asyncio_mode = auto
+testpaths = tests

backend/tests/test_auth_age_gate.py

@@ -0,0 +1,94 @@
+"""Tests for the 18+ age gate on user registration."""
+
+from datetime import date, timedelta
+
+import pytest
+
+from app.routers.auth import calculate_age
+
+
+class TestCalculateAge:
+    """Unit tests for the calculate_age helper."""
+
+    def test_exactly_18(self):
+        """A person born exactly 18 years ago today is 18."""
+        today = date(2025, 6, 15)
+        dob = today.replace(year=today.year - 18)
+        assert calculate_age(dob, today=today) == 18
+
+    def test_just_turned_18(self):
+        """A person who turned 18 yesterday is 18."""
+        today = date(2025, 6, 15)
+        dob = today.replace(year=today.year - 18) - timedelta(days=1)
+        assert calculate_age(dob, today=today) == 18
+
+    def test_one_day_short_of_18(self):
+        """A person born one day after their 18th birthday is 17."""
+        today = date(2025, 6, 15)
+        dob = today.replace(year=today.year - 18) + timedelta(days=1)
+        assert calculate_age(dob, today=today) == 17
+
+    def test_17_years_old(self):
+        """A person who is 17 years old today is 17."""
+        today = date(2025, 6, 15)
+        dob = date(2008, 6, 15)
+        assert calculate_age(dob, today=today) == 17
+
+    def test_65_years_old(self):
+        """A person who is 65 is correctly calculated."""
+        today = date(2025, 6, 15)
+        dob = today.replace(year=today.year - 65)
+        assert calculate_age(dob, today=today) == 65
+
+    def test_newborn(self):
+        """A newborn is 0."""
+        today = date(2025, 6, 15)
+        dob = today
+        assert calculate_age(dob, today=today) == 0
+
+    def test_birthday_not_yet_this_year(self):
+        """Person born Dec 31, 2000 — on Jan 1, 2025 they are still 24."""
+        dob = date(2000, 12, 31)
+        assert calculate_age(dob, today=date(2025, 1, 1)) == 24
+
+    def test_birthday_today(self):
+        """Person born Dec 31, 2000 — on Dec 31, 2024 they turn 24."""
+        dob = date(2000, 12, 31)
+        assert calculate_age(dob, today=date(2024, 12, 31)) == 24
+
+
+class TestRegisterRequestDateValidation:
+    """Tests for the RegisterRequest date_of_birth field validator."""
+
+    @pytest.mark.parametrize(
+        "dob",
+        [
+            "2000-01-01",
+            "1990-12-31",
+            "2004-02-29",  # leap day
+        ],
+    )
+    def test_valid_dates(self, dob):
+        """Valid YYYY-MM-DD dates pass validation."""
+        from app.routers.auth import RegisterRequest
+
+        req = RegisterRequest(username="u", email="u@example.com", password="p", date_of_birth=dob)
+        assert req.date_of_birth == dob
+
+    @pytest.mark.parametrize(
+        "dob",
+        [
+            "01-01-2000",
+            "2000/01/01",
+            "2000-13-01",
+            "2000-00-10",
+            "not-a-date",
+            "",
+        ],
+    )
+    def test_invalid_dates_rejected(self, dob):
+        """Invalid dates are rejected by the validator."""
+        from app.routers.auth import RegisterRequest
+
+        with pytest.raises(ValueError):
+            RegisterRequest(username="u", email="u@example.com", password="p", date_of_birth=dob)

docs/planning/discovery.md

@@ -0,0 +1,150 @@
+# Discovery — Browse, Search & Home — Plan
+
+> **Status:** Planned
+> **Owner:** Platform team
+> **Feature ID:** `discovery`
+> **Godot version:** 4.6.2 stable
+> **Backend:** FastAPI + SQLAlchemy (async) + PostgreSQL + Redis
+
+## 1. Overview
+
+This document breaks the **Discovery** feature into user stories and
+right-sized implementation tasks. The feature delivers:
+
+- **Home / discover page** — a default listing of experiences a player lands on.
+- **Search** — find worlds by name and by tag.
+- **Categories** — a single category per world plus free-form tags, with
+  filtering.
+- **Simple sorting** — newest, most-played, and trending. Trending starts as a
+  basic **recent-activity heuristic** (weighted recent visits); no real
+  recommendation model for MVP.
+
+Without this, nothing else built (experiences, creator content) is actually
+reachable by a real user. Discovery is the front door.
+
+## 2. Why this matters
+
+The platform's value is *reachable* content. Worlds and creator assets already
+exist in the data model (`World`, `Asset`), but there is currently:
+
+- **No public listing** of worlds (`/api/worlds` requires auth and returns only
+  PUBLIC worlds or your own worlds, ordered by `created_at` only).
+- **No search** by name or tag.
+- **No category/tag metadata** on worlds at all.
+- **No play-count or recency signal** to power "most-played" or "trending".
+- **No client UI** for browsing.
+
+Discovery closes that gap with a small, dependency-free metadata layer plus a
+read-optimized listing endpoint.
+
+## 3. Existing constraints (do not re-build)
+
+- **Auth:** JWT bearer tokens; `get_current_user` / `CurrentUser` dependency in
+  `app/dependencies.py`. Discovery **listing** must work both for anonymous
+  visitors and authenticated users, so it needs an *optional* auth dependency
+  (not `CurrentUser`, which returns 401).
+- **DB:** async SQLAlchemy + Alembic; migration head is `0002_add_date_of_birth_to_users`.
+- **Models:** `World` (id, name, description, owner_id, visibility, created_at,
+  updated_at). `User`, `Asset` (owner_id, is_public) exist. No tags/categories/
+  play-count fields yet.
+- **Routers:** `worlds.py` already owns CRUD under `/api/worlds`. Discovery adds
+  a new read-focused router rather than overloading it.
+- **Redis:** configured (`REDIS_URL`) but unused; **not required** for discovery
+  MVP (Postgres queries are sufficient at this scale).
+- **Client:** Godot 4.6.2, minimal `main_menu.gd`; no networking client, no
+  discovery UI.
+
+## 4. Key design decisions
+
+| Concern | Decision |
+|---|---|
+| Listing transport | REST (`GET /api/discovery/worlds`) — no WebSocket needed for browse |
+| Anonymous browsing | Listing/read endpoints accept **optional** auth; visibility filtering treats anonymous users as "PUBLIC only" |
+| Categories | Single `category` string column on `worlds` (indexed). Free-form for MVP; a distinct-categories list is derived with a `SELECT DISTINCT` |
+| Tags | PostgreSQL `ARRAY(String)` column on `worlds` with a GIN index for `@>` tag containment search |
+| Play count | `play_count` integer (default 0) on `worlds`, incremented atomically on visit |
+| Recency signal | `last_played_at` timestamp on `worlds` + append-only `world_visits` table for the trending heuristic |
+| Trending (MVP) | Weighted score over recent visits: `sum(decay_weight(age))` over the last N days, no ML |
+| Sorting | `newest` (created_at desc), `most_played` (play_count desc), `trending` (score desc) |
+| Pagination | `skip`/`limit` (limit capped at 100), consistent with existing routers |
+| Visibility | Discovery only surfaces `PUBLIC` worlds; never leaks private/friends_only worlds |
+
+## 5. User stories
+
+### US-1 Home / discover feed
+As a player, I can open a home/discover page and see a default list of
+experiences without searching.
+
+**Acceptance criteria**
+- Returns PUBLIC worlds only, newest-first by default.
+- Paginated with a stable total count.
+- Works anonymously and authenticated.
+- Each result includes id, name, description, category, tags, owner, play_count,
+  and created_at.
+
+### US-2 Search
+As a player, I can search experiences by name and by tag.
+
+**Acceptance criteria**
+- Case-insensitive substring search on `name`.
+- Tag search matches worlds containing *any* of the requested tags.
+- Search combines with category filter and sort.
+
+### US-3 Categories & sorting
+As a player, I can filter by category and sort by newest, most-played, or
+trending.
+
+**Acceptance criteria**
+- `category` filter matches exactly (case-insensitive).
+- Distinct category list is available for UI dropdowns.
+- `newest`, `most_played`, and `trending` sorts are supported.
+- `most_played` uses `play_count`; `trending` uses the recent-visits heuristic.
+
+### US-4 Visit tracking
+As a player, opening a world records a visit so counts and trending stay fresh.
+
+**Acceptance criteria**
+- `POST /api/worlds/{id}/visit` increments `play_count` and updates
+  `last_played_at`.
+- Appends a `world_visits` row (world_id, user_id or anonymous marker,
+  visited_at).
+- Idempotent per request; rate-limitable later.
+
+### US-5 Godot client
+As a player, I can browse, search, filter, and sort experiences from the game UI.
+
+**Acceptance criteria**
+- An HTTP API client handles the discovery endpoints (JWT + anonymous).
+- A discover/home screen lists experiences with search, category filter, and
+  sort controls.
+- Results render name, category, tags, play count, and description.
+
+## 6. Task breakdown
+
+Right-sized to 1–3 files / one coherent piece of functionality each.
+
+| # | Task | Story | Depends on |
+|---|------|-------|-----------|
+| 1 | World discovery metadata + visits model & Alembic migration | US-2, US-3, US-4 | — |
+| 2 | World visit tracking endpoint (play count + last played + visit log) | US-4 | 1 |
+| 3 | Browse + search endpoint (name/tag/category, newest + most-played) | US-1, US-2, US-3 | 1, 2 |
+| 4 | Trending sort (recent-activity heuristic over `world_visits`) | US-3 | 3 |
+| 5 | Godot discovery API client (HTTP + optional JWT) | US-5 | 3 |
+| 6 | Godot discover/home UI (feed, search, category filter, sort) | US-5 | 4, 5 |
+
+## 7. Phasing
+
+- **Phase 1 (data + core read API):** tasks 1–3 (metadata, visit tracking,
+  browse/search).
+- **Phase 2 (trending):** task 4 — the only non-trivial query; isolated so it
+  can be tuned without touching the browse surface.
+- **Phase 3 (client):** tasks 5–6, each landing after its backend dependency.
+
+## 8. Out of scope for this feature
+
+- Real recommendation models / personalization (collaborative filtering, ML).
+- Full-text search (Postgres FTS); MVP uses ILIKE substring match.
+- Faceted search with multiple simultaneous category/tag AND-semantics.
+- Featured/editorial curation and admin-curated carousels.
+- Search result relevance scoring beyond the three explicit sorts.
+- Analytics dashboards; `world_visits` is append-only signal, not a BI surface.

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.