SESSION FLOW
From invitation to encrypted session
A session starts with an invitation secret, establishes application encryption in the browsers, then tries a Direct WebRTC path before bounded fallback paths.
1. Create and share an invitation
The initiating browser creates the session invitation. Invitations are intended for prompt use and the current interface describes them as lasting about ten minutes.
When an invitation is shared in a URL fragment, browsers do not include that fragment in normal HTTP requests. The recipient still needs to protect the link because anyone who obtains it during its useful window may attempt to join.
2. Establish browser-local protection
The participating browsers derive session protection using the invitation secret and per-connection random values. Application records use AES-256-GCM in the current production path.
Keys and active session state remain in volatile browser memory. Locale and theme are the only current preferences intentionally stored in localStorage.
3. Select the available path
Orylin tries Direct browser-to-browser WebRTC first. If Direct cannot be established, a user-enabled volunteer browser relay can forward bounded ciphertext without receiving session keys.
The public Nostr rescue route is message/control-only. It does not carry files or voice. Voice is available only on a Direct path and pauses when the session is no longer Direct.