GameCult/Heimdall
Watch
9
0
Fork
You've already forked Heimdall
 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions
Heimdall/docs/app-profiles/streampixels.md
Meta Vens 3eaa9ef265 Declare Joystick in the Idunn recipe and document the locked refresh 
Recipe optional_environment gains the Joystick client id and secret file;
service-contract documents the row lock, rotation fail-closed and the 410/502
answers; the StreamPixels profile names Heimdall as sole holder of provider
refresh tokens (F5).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-19 11:15:42 +02:00

2.9 KiB
Raw Blame History

StreamPixels Access Profile

What this file is

This file records how StreamPixels should fit onto Heimdall in docs/architecture.md without turning streamer-audience data into shared auth sludge.

It is a boundary note, not a command to rewrite StreamPixels around Repixelizer.

Public origin

https://streampixels.gamecult.org — this is the allowedReturnOrigins entry Heimdall's built-in streampixels profile carries (src/app-profiles.ts). Corroborated by gamecult-ops/nginx/streampixels.gamecult.org.conf:14 (server_name streampixels.gamecult.org) and StreamPixels' own .env example.

Current repo boundary

The current StreamPixels architecture already makes useful splits:

  • the web app owns the remembered viewer session
  • Heimdall owns provider OAuth exchange, identity resolution and refresh-token custody for Twitch, YouTube and Joystick; StreamPixels never calls a provider token endpoint and holds no provider refresh token. It asks Heimdall for a short-lived access token (managed-credentials/resolve) and treats 410 managed_credential_revoked as "the creator must reconnect"
  • the overlay remains auth-free
  • creator memberships and operator roles are separate from general viewer state

That is already compatible with the shared backbone idea.

What StreamPixels can reuse

  • signed local session mechanics
  • linked-identity and signed OAuth-state patterns
  • provider adapter structure
  • creator/operator capability evaluation
  • grant/invite primitives where they fit

In the service-first Heimdall version, the most likely reusable slice is:

  • provider OAuth authority
  • identity-linking authority
  • managed Twitch/YouTube/Joystick credential custody for creator connections (Joystick is a managed connection only, not a viewer sign-in provider)
  • entitlement refresh
  • shared claim semantics

What StreamPixels should keep separate

  • viewer audience profiles
  • creator memberships tied to streamer spaces
  • creator connector bindings and feature semantics
  • overlay/runtime state
  • audience-facing app data in general

In plain language:

  • Heimdall can authenticate and authorize the control plane
  • Heimdall can also own OAuth flow and token custody for creator-side provider connections when that reduces auth duplication
  • StreamPixels still owns which creator a connection belongs to, what subscriptions or sync flows it drives, and how failures are surfaced
  • StreamPixels audience data stays StreamPixels data

Capability direction

Likely capability families:

  • viewer_access
  • creator_access
  • creator_admin
  • operator_access

These should bind onto the existing StreamPixels creator/operator separation instead of flattening it into one GameCult-member gate.

Invariant

If a future shared access store exists, it must not become the canonical home for streamer-audience identity and product data. That stays with StreamPixels.