Questions about secure messaging, QR opening, encryption, device binding, and Tor in Anomonus.
These answers are based on the current product shape in code: mobile secret creation, browser viewing, local decrypt, QR and link-based opening, and optional hardened access controls.
What is Anomonus? +
Anomonus is a mobile-first secret-sharing product. The app creates encrypted secrets locally, and the website acts as a public web surface plus a viewer-first browser flow for opening shared secrets.
What kinds of secrets can the app create today? +
The current app supports five secret types: secret message, secret link, secret location, secret post, and secret party.
Is Anomonus a chat network or a secret-sharing system? +
Based on the current codebase, Anomonus is better described as a private secret-sharing system. It focuses on creating, sharing, opening, and optionally burning encrypted secrets rather than running a traditional live chat feed.
Where does encryption happen? +
The strongest implemented security boundary in Anomonus is local encryption. The mobile app encrypts secret payloads on-device before upload, and the browser viewer decrypts supported secrets locally after fetching ciphertext.
What does chat.anomonus.com actually do? +
chat.anomonus.com is currently the public web surface for the ecosystem. It presents landing and legal pages, and it provides viewer routes that open encrypted secrets in the browser after ticket validation.
Does the website create secrets too? +
No. Based on the current implementation, the website is intentionally viewer-first. Secret creation belongs to the mobile app flow, not the public browser surface.
How does a recipient open a secret in the browser? +
The viewer reads the secret route, keeps the link fragment on the client side, asks the user for a passcode, requests a one-time ticket, fetches ciphertext, and then decrypts the result locally in the browser.
What does the service store? +
From the current code, the backend stores encrypted secret bundles, metadata, ticket and challenge state, and related lifecycle information. The product is designed so the service stores ciphertext rather than readable secret content.
What is the difference between the passcode and the link fragment? +
The passcode is used during ticket issuance and also participates in decryption logic. The link fragment carries additional client-side key material from the share link. Both matter in the supported browser open flow.
What is device binding? +
Device binding is an optional second access boundary. When enabled, the app uses a native device keypair to sign a backend challenge before the ticket needed to open the secret is issued.
Can the browser viewer open device-bound secrets? +
Not through the standard passcode-only browser path. If the backend requires a device-binding challenge, that flow is intended for the mobile app rather than the regular web viewer.
What transport and runtime protections exist in the app? +
The current mobile code includes certificate pinning for the pinned host, Tor-aware routing with bridge modes, biometric app lock, privacy screen behavior, device integrity checks, and secure logout with wipe audit.
What are TTL, max views, and burn-after-read? +
Those are lifecycle controls attached to secrets. TTL can expire a secret after a time window, max views can limit how many times it is opened, and burn-after-read can destroy the secret after successful access.
Does Anomonus support more than ordinary links? +
Yes. The current product supports deep links, QR opening, and PNG steganography, which allows Anomonus links to be hidden inside PNG images and later extracted for opening.
How is identity handled in the app? +
Identity is based on a recovery phrase and native key storage. The app derives deterministic identity material locally, computes a stable hash ID from the public key, and signs login challenges on-device.