Create in the mobile app
Anomonus is mobile-first for authoring: the app creates encrypted messages, links, locations, posts, and party payloads locally before upload.
Secure secret messaging app with a viewer-first web flow
Secure secret messaging, QR code sharing, and browser decrypt built around local encryption.
Anomonus is a mobile-first encrypted sharing system for secret messages, private links, locations, posts, and parties. The app creates encrypted secret bundles on-device, and chat.anomonus.com opens supported secrets in the browser after ticket validation and local decrypt.
Five secret types
Ticketed browser open
Optional device binding
Tor and pinning in app
System posture
Implemented
The public site now explains the actual product instead of abstract security branding.
The copy is aligned to the mobile app, the viewer-only website model, the ticket flow, and the native security controls visible in the current Anomonus codebase.
5
secret types in the app
8
core security layers
1
pinned backend host
0
plaintext uploaded by design
Product surfaces
What the current product actually does.
The public website should be grounded in the real Anomonus system: app-side secret creation, browser viewing for supported routes, and multiple share or reveal paths.
Open in a browser viewer
chat.anomonus.com is a viewer-first web surface that requests a ticket, fetches ciphertext, and decrypts in the browser for supported flows.
Share through more than one path
The product supports deep links, QR codes, and PNG steganography so recipients are not locked into a single opening path.
Core flows
More than a message page, less than a generic dashboard.
The codebase shows a focused product: create encrypted secrets, share them through multiple paths, and open them with layered access controls rather than broad social networking mechanics.
Private text and link exchange
Create secret messages and HTTPS links with passcodes, lifecycle controls, and optional burn behavior.
Locations, posts, and parties
The app extends beyond text into encrypted locations, richer posts, and RSVP-enabled party secrets.
Identity, transport, and concealment
Native identity keys, optional device binding, Tor transport, and stego workflows all exist in the current product surface.
Security layers
Eight implemented behaviors that define how Anomonus works.
These are not abstract promises. They are the concrete layers visible in the current mobile app and web viewer architecture.
01
Encrypt before upload
Client-Side Secret Encryption
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.
02
Native-backed identity
Hash-Based Identity
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.
03
Browser decrypt
Viewer-First Web Opening
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.
04
Access gating
One-Time Ticket Access
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.
05
Second factor for secret access
Optional Device Binding
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.
06
Pinned host plus Tor
Transport Hardening
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.
07
QR and stego ready
Multiple Open and Share Paths
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.
08
Retention boundaries
Lifecycle and Wipe Controls
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.
Trust architecture
Explain the real system boundary: app creation, web viewing, local decrypt.
The strongest trust story here is factual. The product already exposes a clear split between authoring, access control, transport hardening, and browser-side reveal.
Secrets are encrypted before storage
The app performs secret encryption locally, so the service is designed around storing encrypted bundles plus metadata rather than readable secret bodies.
The web is intentionally viewer-first
The current website opens secrets and serves legal/public pages. It is not presented as a full authenticated dashboard or browser creation studio.
Access can be layered beyond a passcode
Ticket validation, link fragments, and optional device-binding challenge flows add explicit control boundaries around secret retrieval.
Delivery lifecycle
How a secret moves from the app to a recipient.
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.
Next step
Move from landing-page copy to product-level detail.
Use the protocols, trust, transparency, and architecture pages to see how the current Anomonus app and website actually fit together.