NETWORK PATHS
Direct first, with limited fallback
Orylin tries Direct WebRTC first. Fallback keeps encrypted messaging available but disables or limits file and voice features.
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.
A volunteer relay, one hop
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 carries messages only
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 shows each path change and capability reduction; a fallback session is not presented as Direct.