NETWORK PATHS
Direct first, with bounded fallback
Orylin attempts Direct WebRTC first. Fallbacks preserve encrypted messaging availability but intentionally narrow file and voice capabilities.
The Direct path
A Direct path lets the two browsers exchange WebRTC data without routing application payloads through the Orylin service. It is the preferred path for messages, files and voice.
Direct does not mean invisible: peers and network intermediaries still process the addressing and transport metadata needed for the connection.
The bounded volunteer relay
A participant may explicitly enable their browser to help relay encrypted traffic. The relay forwards opaque ciphertext, has no session keys, is single-hop and is limited by protocol budgets.
The current relay file limit is 2 MiB. The design does not turn a volunteer browser into an open proxy, and arbitrary destinations are not exposed.
Public rescue and capability changes
If the browser paths fail, the current public Nostr rescue path can carry encrypted messages and coordination events. External relays may observe or retain encrypted event metadata.
Files are not sent over public Nostr rescue, and voice is never relayed there. The interface should make every path change and capability reduction visible rather than silently pretending the session is still Direct.