# Platform Compliance Assessment Assessed on: 2026-04-13 Updated on: 2026-05-02 Scope: - `Sphinix_Format_Server/chat` - `Sphinix_Format_Server/auth` - `Sphinix_Format_Server/payment` - engine-to-server chat relay and audience interaction surfaces Primary official sources reviewed: - Twitch EventSub subscriptions: https://dev.twitch.tv/docs/eventsub/manage-subscriptions/ - Twitch IRC migration guidance: https://dev.twitch.tv/docs/chat/irc-migration/ - Twitch Community Guidelines: https://safety.twitch.tv/articles/en_US/Knowledge/Community-Guidelines - YouTube API Services Developer Policies: https://developers.google.com/youtube/terms/developer-policies - Kick Public API scopes: https://docs.kick.com/getting-started/scopes - Kick webhook headers and validation: https://docs.kick.com/events/webhooks - Kick public key API: https://docs.kick.com/apis/public-key - Kick webhook payloads: https://docs.kick.com/events/webhook-payloads ## Executive Summary The current server direction is closer to compliant on YouTube than on Twitch because YouTube chat is already treated as an API-driven ingestion path and the server now applies room scoping, filtering, moderation, and rate limiting before relaying messages into the engine. The biggest compliance gap is Twitch chat ingestion. Twitch's current developer guidance recommends upgrading chatbots from IRC to EventSub for reading chat messages and the Twitch API for sending chat messages. Any long-term Twitch production path in this project should therefore move away from legacy polling-style or IRC-first ingestion and toward EventSub webhook or WebSocket subscriptions with verified signatures, explicit OAuth scopes, and documented subscription lifecycle handling. ## Twitch Assessment ### Official constraints that matter here - Twitch recommends Chat on EventSub over IRC for reading chat messages. - EventSub webhooks require HTTPS callbacks on port 443, a verification handshake, and request signature verification using the shared secret. - Webhook subscriptions use an app access token. WebSocket subscriptions use a user access token. - Subscription types may require prior user authorization scopes. - Twitch expects active moderation and use of moderation tools for hateful conduct, harassment, and abuse. - Spam, scams, malicious conduct, viewership tampering, and deceptive automation are prohibited. ### Impact on this codebase - `chat/twitch_ingest.py` should be treated as a transition layer, not the final production ingestion strategy. - The server should not depend on raw chat scraping, unofficial endpoints, or undocumented Twitch interfaces. - Chat data relayed to rooms must remain moderated before it becomes engine-visible or gameplay-visible. - Any viewer-impact mechanic must avoid deceptive engagement inflation or fake platform-side actions. - If this project ever sends Twitch chat messages, it should use the supported Twitch API path with the correct scopes instead of IRC message sending. ### Compliance posture Current status: - Room-based chat separation is aligned with least-privilege fanout. - Server-side filtering, classification, and rate limiting reduce abuse risk. - This repo does not yet implement the recommended EventSub replacement path for Twitch chat ingestion. Required next actions: 1. Add EventSub subscription management for Twitch chat and notification events. 2. Add webhook signature verification and callback challenge handling. 3. Persist broadcaster authorization status and required scopes per room. 4. Document moderator/broadcaster consent requirements before subscribing to room chat events. 5. Avoid storing unnecessary chatter lists or off-platform identity joins unless there is a clear disclosed use. Risk rating: - Production Twitch chat ingestion: High risk until EventSub replaces older ingestion assumptions. ## YouTube Assessment ### Official constraints that matter here - Clients must be honest and transparent about data use. - If user authorization is used, the client must request only scopes it actually needs. - Clients must provide clear privacy policy and consent/revocation flows. - Clients must not use undocumented APIs, must not misrepresent identity, and must not mask access patterns. - Write actions must be clearly user initiated and must not silently alter user-provided values before submission. - Abuse, automation, manipulation, and misuse of the service are prohibited. ### Impact on this codebase - `chat/youtube_ingest.py` should stay within official YouTube API usage only. - The server must not scrape live chat pages or use browser automation as an API substitute. - Any broadcaster-connected functionality must explain what data is read, why it is read, and how to disconnect. - If the project later supports YouTube write actions, those actions must be explicit, user initiated, and transparent. ### Compliance posture Current status: - The current architectural direction can remain compliant if it continues using official API-backed live chat retrieval. - Room-based isolation and moderation are positive compliance controls. - Privacy-policy and consent UX are still documentation and product gaps, not just code gaps. Required next actions: 1. Keep YouTube ingestion on official API surfaces only. 2. Add explicit consent and disconnect surfaces for any authorized broadcaster integration. 3. Add a user-facing privacy policy and terms references in the server/admin surfaces before public rollout. 4. Define data retention windows for cached chat payloads, user IDs, and moderation evidence. 5. Keep API credentials server-side and never embed them in client or engine distributables. Risk rating: - Current API-driven YouTube chat ingestion: Medium risk, mostly around privacy, disclosure, and operational policy completeness. ## Kick Assessment ### Official constraints that matter here - Kick integrations should use OAuth 2.1 and request only the scopes required for the enabled feature. - Chat ingestion should use Kick event subscriptions for `chat.message.sent` rather than browser scraping, cookie reuse, or undocumented chat sockets. - Kick webhook requests include message ID, subscription ID, signature, timestamp, type, and version headers. - Webhook signatures should be verified against Kick's public key, using the signed payload shape documented by Kick. - Replayed webhook messages should be rejected or ignored using the message ID and timestamp. ### Impact on this codebase - `kick_events` is the compliant source kind for Kick chat. It receives signed webhooks and then enters the same server-authoritative moderation, filtering, rate limiting, dedupe, and room fanout path as other platforms. - The engine must continue to consume Kick chat through the content-platform server feed. It should not connect directly to unofficial Kick chat transports. - Kick app/user tokens must remain server-side. The room source stores only the subscription binding and broadcaster ID needed to route events. - The minimum scope for this path is `events:subscribe`; `user:read` and `channel:read` are only needed when the product performs account/channel lookup or consent display. Do not request `chat:write`, moderation, or stream key scopes for read-only chat ingestion. ### Compliance posture Current status: - Kick chat can be configured as a webhook-backed room source. - Kick webhook signatures are verified with RSA/SHA-256 using Kick's public key before ingestion. - Kick webhook message IDs are deduplicated after signature validation to avoid replay processing. - Kick messages are moderated before they reach engine gameplay. Required next actions: 1. Add user-facing Kick consent/disconnect UX before public creator onboarding. 2. Persist broadcaster OAuth grants, refresh status, and revocation state if user access tokens are used instead of app tokens. 3. Keep Kick write/moderation scopes out of the default flow until explicit, user-initiated write or moderation features exist. 4. Document Kick data retention alongside Twitch and YouTube in the product privacy policy. Risk rating: - Current webhook-backed Kick chat ingestion: Medium risk, mostly around consent UX, token lifecycle, and policy documentation completeness. ## Cross-Platform Requirements For This Project These requirements apply regardless of platform. ### 1. User consent and disclosure - Broadcaster-facing auth flows must disclose exactly what the integration reads and why. - The product should expose a disconnect or revoke path. - Privacy policy links should be available from the auth/admin path that enables integrations. ### 2. Moderation before gameplay impact - Chat should be filtered and rate limited before it influences engine state. - Profanity, hateful conduct, spam, scams, and malicious link patterns should be blocked or downgraded. - The current room relay direction is correct and should remain server-authoritative. ### 3. Minimize retained identity data - Store only the identifiers needed to operate the room integration. - Do not retain full chat logs indefinitely by default. - Separate moderation evidence retention from gameplay event retention. ### 4. No deceptive engagement mechanics - Do not simulate platform-native views, followers, likes, raids, subscriptions, or other platform metrics as if they were real. - Engine-side audience simulation must remain clearly internal and must not be reported back to platforms as real engagement. ### 5. Credential handling - All API secrets and OAuth tokens must stay server-side. - Tokens should be scoped narrowly and refreshed using official flows only. - Tokens and secrets should be redacted in logs and admin surfaces. ## Repo-Specific Engineering Checklist Recommended implementation checklist for this repository: - `chat/twitch_ingest.py`: replace legacy ingestion assumptions with EventSub-first chat subscriptions. - `chat/routes.py`: add verified Twitch webhook callback routes if webhook transport is used. - `auth/*`: persist broadcaster grants, scopes, revocation state, and last verification time. - `chat/service.py`: keep room-level filtering, moderation, and source configuration as the single authoritative ingestion gate. - `admin/routes.py`: expose broadcaster integration status, granted scopes, and disconnect controls. - `docs/*`: publish privacy-policy and integration-disclosure docs before public deployment. ## Current Pass / Fail Snapshot Pass: - Server-mediated room chat relay - Pre-engine filtering and moderation - Rate limiting and duplicate suppression - Separation of source config from engine-facing feed delivery Partial: - YouTube platform compliance depends on staying strictly inside official API usage and adding user-facing disclosures - Logging and retention controls need clearer policy documentation Fail or not yet implemented: - Full Twitch/Kick broadcaster consent and revocation UX - Formal public privacy-policy and terms links for platform integrations ## Recommendation The safest production plan is: 1. Treat YouTube API ingestion as the only currently defensible live-chat platform path. 2. Upgrade Twitch integration to EventSub before advertising Twitch chat support as production-ready. 3. Use Kick `kick_events` webhook ingestion only; do not ship an unofficial Kick websocket/scraping reader. 4. Keep all gameplay-affecting chat as server-authoritative, room-scoped, moderated, and rate-limited. 5. Ship written privacy-policy and integration-disclosure surfaces before public creator onboarding. ## Notes This assessment is an engineering compliance summary, not legal advice. Some conclusions above are inferences from official platform documentation applied to this repo's current architecture. In particular, the recommendation to avoid long-term Twitch IRC-style ingestion is based on Twitch's current migration guidance favoring EventSub for chat-reading workloads. ## Payment and Infrastructure Compliance Addendum (2026-09-12) Payment, data-retention, lawful-disclosure, and infrastructure assurance are now documented separately so this platform-integration assessment does not disclose implementation details or mix unrelated control domains. See: - `docs/infrastructure_assurance_overview.md` - `docs/payment_compliance_and_provider_controls.md` - `docs/data_retention_legal_hold_and_disclosure.md` - `docs/security_audit_and_blue_team_records.md` These documents describe control objectives and evidence boundaries. They do not make source code immune from lawful compulsory process and do not claim certification or legal compliance beyond the evidence actually established.