EMB-1013 - How Embers Handles Access - Passwords and Invites

Living Document Notice Published 2026-09-22. The evolving architecture and revision notes for this dispatch live in the Stax Digital Garden.

How Embers Handles Access - Passwords and Invites

Overview

Access models break down at operational extremes: rigid systems requiring two-factor authentication for every visitor discourage non-technical family members, while unauthenticated bearer URLs expose private albums to the open web.

Embers eliminates this friction through three isolated access vectors managed by strict role-based permission gates.

                      ┌─────────────────────────┐
                      │    Incoming Request     │
                      └────────────┬────────────┘
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         ▼                         ▼                         ▼
┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐
│  Named Account   │      │   Link + PIN     │      │  Album Password  │
│ (Argon2 Session) │      │ (HMAC + Bcrypt)  │      │ (Bcrypt Session) │
└────────┬─────────┘      └────────┬─────────┘      └────────┬─────────┘
         │                         │                         │
         └─────────────────────────┼─────────────────────────┘
                                   │
                                   ▼
                      ┌─────────────────────────┐
                      │   requireAccess() Gate  │
                      │  [Admin|Contrib|Viewer] │
                      └─────────────────────────┘

The Three Access Channels

1. Named Accounts: Authenticated platform accounts for primary family members and regular contributors. Sessions rely on secure, HTTP-only cookies validated against SQLite session tables.
2. Shared Album Passwords: Suited for family events. Owners set passwords directly on target album records. Visitors visit the album URL, complete an authentication challenge, and receive a signed guest session cookie.
3. Tokenized Invites with PIN Protection: Cryptographically random invite tokens generated for individual recipients. Owners can mandate a numeric PIN challenge, ensuring the media remains protected even if the link is forwarded across unencrypted channels.

Role-Based Permissions

Once an authentication vector is verified, user actions are restricted by a role matrix:

Action	Admin	Contributor	Viewer
Read Photos & Stream Videos	Allowed	Allowed	Allowed
Download Original Source Files	Allowed	Allowed	Configurable
Upload Assets & Append Notes	Allowed	Allowed	Denied
Modify Album Details & Sorting	Allowed	Denied	Denied
Create Invites & Update Passwords	Allowed	Denied	Denied
Delete Media & Destroy Album	Allowed	Denied	Denied

Architectural Invariants

• Deterministic Execution: Operations execute within deterministic memory bounds without external side effects.
• Sovereignty: Storage and state replication guarantee zero unauthenticated telemetry or vendor lock-in.

Invariant Property	Operational Guarantee
System Invariant	Embers rejects all public bearer links and automated facial indexing; access is strictly confined to authenticated household sessions and explicit PIN gates.

# Verify guest access PIN requirement and zero public bearer URLs
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:3000/media/stream/circle_01

---

• Directus Target: embers
• Garden Source Reference: MOC - The Digital Necropolis and Cold Decadal Storage, MOC - Bosun PKM Tools
• Garden Source Reference: [EMB-1013 - How Embers Handles Access - Passwords and Invites](EMB-1013 - How Embers Handles Access - Passwords and Invites), BSN-1001 - The Bosun Architecture Manifesto