Draft Realm Chat legal and conduct contract

CHANGELOG.md

@@ -6,6 +6,15 @@ full engineering record.
 
 ## [Unreleased]
 
+- Drafted the next Alpha Terms, Hegemony Social Contract, and Privacy Notice
+  for a future persistent Realm Chat, including explicit conduct, reporting,
+  moderation, history, and privacy boundaries. Chat remains disabled pending
+  owner and qualified legal review, server authority, release gates, and a
+  separate activation record; this draft collects no chat data.
+- Blocked independent production deployment of the review-only agreement on
+  both Pages and SpacetimeDB, pinned the proposed Privacy Notice text digest,
+  and removed duplicated agreement-version literals from migration and local
+  full-stack QA so rollout drift fails closed.
 - Prepared an optional **Enable Admission Alerts** step after a confirmed access
   request. It remains fail-closed behind a default-off release gate until the
   owner-controlled signed notification canary is complete, and never affects

docs/design/realm-chat-v1-contract.md

@@ -0,0 +1,163 @@
+# Realm Chat V1 contract
+
+Status: **proposal only; disabled**
+
+Policy version: `2026-08-03-realm-chat-policy-v1`
+
+Realm channel: `realm:genesis-001`
+
+This document fixes the product, authority, privacy, and moderation boundaries
+for the first Warpkeep chat implementation. It does not activate chat, publish a
+database, seed a channel, or authorize a client entry point.
+
+## Release gates
+
+Realm Chat must remain unavailable until all of these are complete:
+
+1. The project owner and a qualified legal reviewer approve the proposed Terms,
+   Social Contract, Privacy Notice, persistence language, moderation process,
+   and an explicit age/minor-participation policy.
+2. A later additive SpacetimeDB PR implements and verifies the private archive,
+   caller-bounded views, reducers, indexes, and report records.
+3. A later client PR implements the portrait and desktop experiences without
+   creating browser-side identity, sequence, or time authority.
+4. Operator moderation procedures, evidence handling, release checks, and a
+   tested kill switch exist.
+5. A separate activation record names the reviewed versions, exact deployment,
+   seeded channel, canary evidence, rollback owner, and timestamp.
+
+Merging this contract alone must not make a chat control visible or callable.
+The client-side `false` constant is documentary defense in depth, not an
+activation mechanism. Server channel state remains authoritative.
+
+The proposed V5 agreement is also marked `review-only-rollout-blocked`.
+Warpkeep's production Pages validator and canonical SpacetimeDB publisher must
+reject deployment/publication under that status. Read-only publisher dry runs
+remain available for compatibility evidence. A later reviewed rollout may change it to
+`production-approved` only when the exact legal approval and a coordinated
+browser/module compatibility proof are recorded. This prevents an automatic
+V5 Pages deployment from meeting a still-V4 production module and failing every
+player's entry-agreement handshake.
+
+## V1 product boundary
+
+- One admitted-Realm channel only: `realm:genesis-001`.
+- No direct messages, guild channels, trading chat, links with rich previews,
+  attachments, voice, or cross-Realm federation.
+- Mobile uses a full-screen portrait surface. Desktop uses a bounded dock.
+- Recent messages are live; older retained messages are paginated.
+- A player can locally mute another sender for the current browser session.
+  Local mute is not a server punishment and does not alter other players' view.
+- A report attaches to one exact message and preserves its relevant context for
+  private review. A report never triggers automatic punishment.
+
+Comparable games commonly separate world/guild audiences and provide reporting
+from the relevant player or message surface. See the official
+[Forge of Empires chat overview](https://support.innogames.com/kb/ForgeOfEmpires/en_DK/963),
+[Forge of Empires reporting flow](https://support.innogames.com/kb/ForgeOfEmpires/en_DK/964),
+[Travian messaging overview](https://support.travian.com/en/articles/11-interacting-with-other-players),
+and [Travian report guidance](https://support.travian.com/en/articles/121-i-think-a-player-is-violating-game-rules-what-can-i-do).
+Warpkeep V1 deliberately starts with fewer channel types.
+
+## Server authority and visibility
+
+The browser supplies only intended message text and an operation request. The
+server derives the admitted sender FID, public-profile reference, channel,
+sequence, authoritative time, and any visibility state. It validates the exact
+current entry agreement and active channel before accepting a message.
+
+The future permanent message archive must be private. Clients must not be able
+to subscribe to or enumerate the full archive, report records, moderator notes,
+or internal enforcement state. A bounded recent projection may expose up to 128
+permitted messages. A caller-specific paginated history view may expose at most
+50 permitted messages per request and must use indexed lookups. SpacetimeDB
+documents that private tables are unavailable to clients and that views can
+filter private rows by caller; that is the required later authority pattern:
+[table access permissions](https://spacetimedb.com/docs/tables/access-permissions/)
+and [views](https://spacetimedb.com/docs/functions/views/).
+
+Messages form persistent Realm history and have no routine gameplay expiry.
+That is not a promise of immutable public display or universal physical
+retention. Authorized moderation, safety, privacy, legal, service-integrity, or
+Realm-reset work may restrict, tombstone, anonymise, or erase a record. Provider
+backup lifecycles may differ from active database state.
+
+## Candidate limits requiring owner review
+
+The following are implementation candidates, not approved live limits:
+
+- 500 Unicode scalar values;
+- 2,048 UTF-8 bytes;
+- 8 lines;
+- 2 seconds between accepted messages;
+- 10 accepted messages per rolling minute;
+- 60 accepted messages per rolling hour; and
+- rejection of the same normalized body from one sender within 60 seconds.
+
+The authority PR must define normalization, Unicode handling, counting windows,
+retry responses, and adversarial tests before these numbers become enforceable.
+
+## Conduct and moderation
+
+Good-faith criticism of Warpkeep, its maintainer, rules, or features is allowed.
+The project may still restrict disruptive conduct contextually, including
+political or controversial discussion that overwhelms the game's shared space.
+The maintainer exercises broad good-faith judgment but does not claim to make a
+definitive legal determination.
+
+High-risk categories include credible threats or incitement; doxxing, stalking,
+or targeted harassment; sexual exploitation or child sexual abuse material;
+terrorism or instructions for serious harm; fraud, phishing, malware, account
+compromise, or illegal trade; non-consensual intimate content; unlawful hate or
+discriminatory abuse; and attempts to obtain or publish non-public personal or
+authentication data.
+
+A warning is not required or guaranteed. Internal reasons remain private. Where
+safe and applicable, the affected player should receive a brief understandable
+notice that does not expose reporters, personal data, security methods, or an
+active investigation. The Alpha does not promise a formal appeal system; it
+offers a private reconsideration/legal-contact route without limiting rights
+available under applicable law. Knowingly false, retaliatory, or abusive reports
+may themselves affect access. Security research reported through the repository
+[Security Policy](https://github.com/ael-dev3/Warpkeep/security/policy) remains
+protected and distinct from ordinary chat moderation.
+
+## Privacy boundary
+
+If activated, the feature processes message body, verified FID, public profile
+link, server time and sequence, recipients or visibility scope, report data, and
+private moderator decisions. It uses these records to deliver shared Realm
+communication, prevent abuse, investigate reports, protect the service, enforce
+the agreement, and meet applicable legal obligations. It does not sell them or
+use them for advertising.
+
+The Privacy Notice must identify providers and processing locations, retention
+and exceptions, lawful bases where applicable, and available access,
+rectification, erasure, restriction, objection, portability, and complaint
+rights. The EDPB's small-business guidance emphasizes an identified legal basis,
+data minimisation, transparent purposes, security, storage limits, and procedures
+for individual rights: [data protection basics](https://www.edpb.europa.eu/sme/learn-the-basics/data-protection-basics_en),
+[lawful processing](https://www.edpb.europa.eu/sme/be-compliant/process-personal-data-lawfully_en),
+and [individual rights](https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_ga).
+
+The exact normalized visible Privacy Notice text is integrity-pinned alongside
+the Terms and Social Contract even though the notice is not treated as blanket
+consent.
+
+The age/minor-participation policy is intentionally unresolved. This contract
+sets no age threshold. Activation is blocked until the owner and qualified legal
+reviewer approve the applicable policy and any required parent/guardian, notice,
+consent, or access measures.
+
+## Planned PR sequence
+
+1. Legal/product contract (this PR; disabled).
+2. Additive SpacetimeDB authority and generated bindings.
+3. Client portrait/mobile and desktop-dock experience.
+4. Desktop/accessibility/abuse QA.
+5. Operator moderation and release integration.
+6. Separate, evidence-backed activation record.
+
+Each PR must remain independently reviewable. No implementation PR may weaken
+the legal gate, expose the permanent archive, or collapse private moderation
+records into public game state.

docs/legal/2026-08-03-realm-chat-entry-agreement-v5.md

@@ -0,0 +1,63 @@
+# Proposed Realm Chat entry-agreement V5
+
+Status: **owner and qualified legal review required; do not activate chat**
+
+Entry-agreement bundle `2026-08-03-hegemony-entry-agreement-v5` proposes these
+exact public documents:
+
+- Alpha Terms revision `2026-08-03-v5`;
+- Hegemony Social Contract version
+  `2026-08-03-HEGEMONY-SOCIAL-CONTRACT-V4`; and
+- Privacy Notice revision `2026-08-03-v6` (notice only, not blanket consent).
+
+Normalized visible `<main>` text digests proposed for review:
+
+- Terms: `dede7757c3be767b7a87e89e2c68817e9390cde91fabcf38246756afacdf51bd`;
+- Social Contract: `85941d066dd39f5be069d640f1419491e6fc0f691d01c292bfc3ed995c249110`;
+- Privacy Notice: `79bd17b795b399391ed0f6f84f2c7ff35fdb3ae64bf4ca17e3df0ad67d7b361f`.
+
+The proposed agreement explains a future persistent Realm Chat, prohibited
+high-risk conduct, contextual moderation, good-faith criticism, reports, local
+mute, reconsideration, and the unresolved age/minor-participation policy. The
+Privacy Notice conditionally discloses the message, identity, recipient,
+reporting, moderation, provider, retention, and individual-rights data flows.
+
+## Consequence of approval
+
+The Terms and Social Contract wording changes materially. If this bundle is
+approved, merged, and deployed as the current agreement, every Keeper must make
+a fresh unchecked acceptance before authenticated entry. Earlier acceptance
+evidence remains immutable historical evidence and cannot satisfy the V5 entry
+gate.
+
+The bundle change does not itself activate chat. This PR intentionally contains
+no chat table, reducer, binding, UI, seeded channel, database publication,
+operator action, or production-state claim. `WARPKEEP_REALM_CHAT_CLIENT_ENTRY_ENABLED`
+remains `false`. Chat activation requires the later PR sequence and a separate
+activation record described in
+[`docs/design/realm-chat-v1-contract.md`](../design/realm-chat-v1-contract.md).
+
+The candidate bundle remains `review-only-rollout-blocked`. Both the production
+Pages validator and canonical SpacetimeDB publisher must fail closed on live
+deployment/publication under that status; read-only publisher dry runs remain
+available for compatibility evidence. Promotion to `production-approved` requires a later reviewed change
+that records the exact approval and proves a coordinated browser/module rollout;
+otherwise V5 browser code could auto-deploy against a still-V4 module and deny
+Realm entry to every player.
+
+## Required approval record
+
+Before merge, the owner and qualified legal reviewer must explicitly resolve
+and approve:
+
+- exact version identifiers and final visible wording;
+- the age/minor-participation policy;
+- persistence, deletion, tombstone, anonymisation, and backup language;
+- prohibited-content and good-faith-discretion language;
+- report handling, moderator notice, reconsideration, and evidence access;
+- privacy purposes, lawful bases, recipients, locations, retention, and rights;
+  and
+- a private legal/privacy contact path suitable for production use.
+
+This repository record is project-authored engineering documentation, not a
+legal-compliance certification or substitute for qualified legal advice.

public/privacy/index.html

@@ -30,7 +30,7 @@ <h1>Privacy Notice</h1>
             why it is used, where it goes, and the limits of retention and deletion.
           </p>
           <p class="legal-page__version">
-            Alpha Privacy Notice revision 2026-08-02-v5 · Last updated 2 August 2026
+            Alpha Privacy Notice revision 2026-08-03-v6 · Last updated 3 August 2026
           </p>
           <p class="legal-page__notice">
             This is a factual, project-authored Alpha notice, not a legal-compliance certification
@@ -97,8 +97,8 @@ <h2 id="data-sources">3. Data, sources, and purposes</h2>
                 authenticates, and requests entry, SpacetimeDB stores private, immutable evidence
                 containing the verified FID, exact entry-agreement bundle version, and acceptance
                 time. The Alpha Terms incorporate Hegemony Social Contract version
-                <code>2026-07-19-HEGEMONY-SOCIAL-CONTRACT-V3</code> in entry-agreement bundle
-                <code>2026-07-31-hegemony-entry-agreement-v4</code>; the published browser policy
+                <code>2026-08-03-HEGEMONY-SOCIAL-CONTRACT-V4</code> in entry-agreement bundle
+                <code>2026-08-03-hegemony-entry-agreement-v5</code>; the published browser policy
                 cryptographically binds the exact visible Terms and Social Contract texts to their
                 reviewed hashes. This evidence is used to enforce the current entry agreement and
                 preserve an audit trail. It is not a public projection and does not contain the
@@ -184,6 +184,20 @@ <h2 id="data-sources">3. Data, sources, and purposes</h2>
                 units: non-transferable, non-redeemable, without cash value, and subject to
                 correction or reset.
               </li>
+              <li>
+                <strong>Realm Chat, if activated:</strong> Realm Chat is not active in this release.
+                It must remain disabled until the owner and legal review gates are complete. If it
+                is later activated, SpacetimeDB will process the message body, channel, server-owned
+                sequence and time, the sender's verified FID and public profile link, intended
+                recipients or visibility scope, message reports, and private moderator decisions.
+                The browser will not be trusted to choose the sender FID, authoritative time, or
+                sequence. Other admitted players may receive recent Realm messages and the sender's
+                public Farcaster presentation. A caller may request their permitted retained
+                history; the permanent archive, report records, and moderation reasons will not be
+                exposed as one public subscribable table. A local mute will exist only in the
+                muting player's current browser session and will not change server records or what
+                other players can see.
+              </li>
               <li>
                 <strong>Operations:</strong> Warpkeep emits a closed list of generic security and
                 availability event names. Application logs are designed not to contain FIDs,
@@ -286,6 +300,10 @@ <h2 id="retention">5. Retention and deletion limits</h2>
                     <td>Daily Mark receipts and Mark account</td>
                     <td>No fixed Alpha deletion schedule yet. Private daily-grant receipts and balances may remain for replay protection, correction, security, and audit. Only privacy-bounded aggregate figures become public game state.</td>
                   </tr>
+                  <tr>
+                    <td>Realm Chat messages, reports, and moderation records, if activated</td>
+                    <td>Realm Chat is currently disabled and does not yet collect these records. If activated after review, messages are intended to form persistent Realm history without routine gameplay expiry. They may still be removed from ordinary player view, restricted, tombstoned, anonymised, or erased for moderation, safety, privacy, legal obligations, service integrity, or a Realm reset. Reports and moderator decisions remain private and may be retained while needed to investigate abuse, enforce rules, resolve disputes, and meet legal obligations. Provider backup lifecycles may differ from active records.</td>
+                  </tr>
                 </tbody>
               </table>
             </div>
@@ -313,6 +331,13 @@ <h2 id="recipients-transfers">6. Services, recipients, and locations</h2>
               that host still receives ordinary request data such as the connecting IP. These
               independent services handle data under their own terms and privacy notices.
             </p>
+            <p>
+              If Realm Chat is activated, admitted recipients receive the permitted live and
+              historical message views described above, and authorized moderators may receive the
+              exact reported message, report context, and related private records. Reporters do not
+              receive another player's private moderation outcome. Warpkeep does not sell chat or
+              report data and does not use it for advertising.
+            </p>
             <p>
               These are global online services, so information may be processed in multiple
               countries, including outside the country where you live or access the Alpha. The
@@ -338,6 +363,12 @@ <h2 id="choices-rights">7. Your choices and rights</h2>
               you live, work, or where you believe an infringement occurred, when applicable.
               Contacting the project first is welcome but does not remove any complaint right.
             </p>
+            <p>
+              Realm Chat's age and minor-participation policy is unresolved. The project must not
+              activate it until the owner and qualified legal reviewer approve an age policy and
+              any required parental, guardian, notice, consent, or access measures. No age threshold
+              is asserted by this draft.
+            </p>
           </section>
 
           <section aria-labelledby="automation-finance">