This page translates the current app and web code into a public technical story for secure messaging and encrypted sharing: what is encrypted locally, how secrets are opened, and where device or transport controls fit.
Messages, links, locations, posts, and parties are encrypted in the client before upload.
The mobile app turns secret content into encrypted bundles locally, so the service stores ciphertext and metadata instead of plaintext message bodies.
Identity is derived from a recovery phrase and native key storage, then used for challenge-response login.
The app generates deterministic identity material locally, computes a stable hash ID from the public key, and signs login challenges on-device.
The website is built to open secrets in the browser, not to author them there.
Recipients open a share link, enter a passcode, request a ticket, fetch ciphertext, and decrypt locally inside the browser viewer.
Secrets are fetched through short-lived ticket issuance instead of anonymous unlimited reads.
The backend validates lifecycle state before issuing a ticket, consumes that ticket on fetch, and can burn the secret after open when policy requires it.
Some secrets can require a device-held key in addition to the passcode and link material.
When device binding is enabled, the app signs a backend challenge with a native device key before a ticket is granted for the secret.
The mobile client can combine certificate pinning, Tor routing, and bridge modes for the pinned host.
Traffic to chat.anomonus.com can be evaluated for direct, Tor, or blocked paths, with native Tor transport and pinning diagnostics in the client code.
Secrets can move through deep links, QR scans, and PNG steganography instead of one rigid share flow.
The app supports hiding Anomonus links inside PNG images and opening secrets from QR codes, raw links, or extracted hidden payloads.
TTL, max views, burn-after-read, secure logout, and wipe audit are part of the implemented system behavior.
Secret lifetime and device state are treated as first-class controls, with explicit deletion, expiry, and post-delete audit paths in the app.
The mobile app encrypts the secret locally, packages metadata, and uploads the ciphertext bundle to the backend.
The user distributes an Anomonus link, QR code, or PNG-hidden link that carries the secret route and optional key fragment.
The recipient enters a passcode, requests a one-time ticket, and may need device-bound challenge verification for protected secrets.
The browser or app fetches ciphertext with the ticket and performs client-side decrypt, with burn-after-read and lifecycle rules applied after access.