Skip to main content

Data Flows

This document describes how data moves through the humuus platform, from user authentication to real-time workshop interactions.

Authentication Flow

Authentication Methods

Device Authentication (Anonymous)

  1. Client generates unique device ID on first launch
  2. Nakama creates account with device ID as identifier
  3. JWT token issued with 30-day expiration (configurable)
  4. Token stored in browser's localStorage
  5. Automatic reauthentication on subsequent visits

Use Case: Quick access for workshop participants without registration barriers

Email Authentication (Persistent)

  1. User provides email/password via registration form
  2. Nakama validates email format and password strength
  3. Account created with email as primary identifier
  4. Verification email sent (optional, configurable)
  5. Session token issued after successful login

Use Case: Facilitators and users who want persistent accounts across devices

Token Management

  • Token Structure: JWT with user ID, device ID, expiration timestamp
  • Refresh Logic: Client automatically refreshes tokens 24 hours before expiration
  • Invalidation: Tokens invalidated on logout or password change
  • Security: Tokens stored with httpOnly flag when possible, cleared on logout

Session Persistence

Workshop Lifecycle

Workshop States

StateDescriptionActions Available
CreatedMatch initialized, waiting for facilitator
LobbyParticipants can join, workshop not startedKick participants, start workshop
ActiveWorkshop in progress, on current nodeProgress to next node, pause
EndedManually terminated by facilitatorView partial results

Real-Time Interaction Flow

Node State Management

Transition Types:

  • Manual: Facilitator clicks "Next" button
  • Automatic: Timer expires or all participants complete the node

Data Persistence Flow

Data Models

Workshop Session

CREATE TABLE workshop_sessions (
id UUID PRIMARY KEY,
workshop_id VARCHAR(255) NOT NULL,
match_id VARCHAR(255) UNIQUE NOT NULL,
facilitator_id VARCHAR(255) NOT NULL,
status VARCHAR(50) NOT NULL,
started_at TIMESTAMP,
completed_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);

Participant Actions

CREATE TABLE participant_actions (
id BIGSERIAL PRIMARY KEY,
session_id UUID REFERENCES workshop_sessions(id),
user_id VARCHAR(255) NOT NULL,
node_id VARCHAR(255) NOT NULL,
action_type VARCHAR(100) NOT NULL,
action_data JSONB,
timestamp TIMESTAMP DEFAULT NOW(),
INDEX idx_session_node (session_id, node_id)
);

File Upload Flow

File Handling

  • Max File Size: 50MB per file (configurable)
  • Allowed Types: Images (jpg, png, gif), PDFs, audio (mp3, wav), video (mp4)
  • Virus Scanning: Optional ClamAV integration for uploaded files
  • Retention: Files kept for 90 days after workshop completion
  • CDN: Files served via CDN with appropriate cache headers

Error Handling & Recovery

Connection Loss

State Reconciliation

When a client reconnects after disconnection:

  1. Send last known state version to server
  2. Server calculates delta (changes since last known state)
  3. Server sends minimal update to bring client up to date
  4. Client merges changes with local state
  5. UI updates to reflect current workshop state

Conflict Resolution

In rare cases where conflicting actions occur simultaneously:

  • Server state is authoritative: Server's view always wins
  • Timestamp-based ordering: Earlier actions take precedence
  • Last-write-wins: For simple conflicts, most recent update is kept
  • Manual resolution: For critical conflicts, facilitator is notified