Abyssal

Secure and Ephemeral chat application

Chat behavior Text and media messages can reply to any message still present in the current RAM buffer. Tap the reply icon beside a bubble, then send text, a file, an image, a video, or a bundled GIF. Reply envelopes contain only the original message ID inside the encrypted payload. They do not copy the original plaintext, filename, or sender. If the original expires, the reply renders Original message unavailable instead of extending the original content's lifetime. Tapping an available reply preview scrolls to and briefly highlights the original message. The composer automatically cancels a reply if its target expires before send. Every bundled reaction has a :filename: shortcut, such as :fire:. Picker and shortcut sends use the same encrypted attachment path and render in equal-size inline frames on Android and web. Type @ to complete a connected username, or tap a sender name to mention them. Mentions and replies to one of the current process's own message IDs receive recipient-only attention styling. The composer remains editable while reconnecting, but send and attachment actions stay disabled until the WebSocket is connected so a local bubble is not mistaken for a relayed message. The chat initially opens at the latest active message and follows new messages only while the user remains near the bottom. Direct messages appear under DIRECT. Select a peer in the live presence rail to ask the relay for a canonical private conversation; guessed DM identifiers are rejected by the relay. Direct headers display a symmetric safety number derived from both identity keys. Both participants see the same number and should compare it through a separate channel; an exact user confirmation is required before direct sends, attachment access/export, or network read receipts. Direct composers choose retention for each text, GIF, or attachment: Never, 5s, 10s, 30s, or 1m. Never means retained only for the current client/relay RAM lifetime; restart, wipe, logout, or process loss still removes it. Room creators may set any after-read timer to 0 for no read-triggered expiry. Room policy is locked for participants, including text and media-specific timers; a sender cannot extend it from the composer.