SimXmil documentation

Architecture overview

SimXmil is a client-first messenger. Keys are born on the device, message bodies are sealed before they touch the network, and the server’s role is limited to routing opaque envelopes and removing them after delivery is confirmed.

The same cryptographic core runs on Android and on the web client, so a conversation started on one platform can continue on the other without a protocol break. Account signup uses email only — for recovery and for stopping mass abuse — not as a tracking identifier for your social graph or message content.

                    ┌──────────────────────────────────────┐
                    │            Your device               │
                    │  Identity key (EC P-256)             │
                    │  Double Ratchet state per peer       │
                    │  Local encrypted message DB          │
                    │  Safety toolkit · offline location   │
                    │  Stego · Prabh lab · Guhya Burn      │
                    └────────────────┬─────────────────────┘
                                     │ ciphertext only
                                     │ (AES-256-GCM envelopes)
                    ┌────────────────▼─────────────────────┐
                    │          SimXmil servers             │
                    │  Account + public identity keys      │
                    │  Transient delivery queues           │
                    │  No message plaintext                │
                    │  No long-term ciphertext archive     │
                    │  Guhya Burn removes account footprint│
                    └────────────────┬─────────────────────┘
                                     │ push / pull ciphertext
                    ┌────────────────▼─────────────────────┐
                    │           Peer device(s)             │
                    │  Matching ratchet + identity keys     │
                    └──────────────────────────────────────┘

The rest of this page walks through each layer: how you create an identity, how two devices agree on keys, how groups share sender material, how backups wrap secrets you control, how the safety tools help you notice a hostile environment, and how Guhya Burn erases local and server footprints when you need a clean exit.

Platforms

An iOS client is actively under development. Feature goals include the same end-to-end encryption model, multi-device linking, and encrypted backups. This page will be updated when TestFlight or App Store builds are available.

Getting started

Install from Google Play when you can. For a sideloaded build, download only from the official site and check the APK signature against the published fingerprint before you install.

First-run flow:

1. Email — create the account with an email address. That address is used for account recovery and to limit spam or mass account creation. It is not required as a phone number, and it is not used to harvest your contact list or to link chats to a carrier identity.
2. Username — choose a public handle. Peers find you by this name.
3. Identity key — the app generates a long-term EC P-256 key pair on the device. The private half is stored encrypted at rest and is never uploaded in clear form.
4. Backup passphrase — set one. Without it, a wiped phone or a reinstall means permanent loss of that identity key and of history that depended on it. The passphrase never leaves the device in usable form.
5. Optional profile — display name and avatar. Avatar uploads are scrubbed of EXIF and similar metadata before they leave the device.

After setup you can open People, start a one-to-one chat, or create a group. The first message in a new conversation triggers the ECDH handshake that seeds the Double Ratchet. From then on every payload rides under its own message key.

Create a profile

Profiles stay thin on purpose. Less stored personal data means less to leak if an account surface is ever abused, and less for the server to hold in the first place.

Fields that matter

• Email — account recovery and abuse prevention only. Not a chat identifier.
• Username — unique, case-insensitive public handle for search and addressing.
• Display name — optional label shown to people who already have a session with you.
• Avatar — optional; metadata stripped before upload.
• Identity public key — published so peers can start ECDH. Private key stays on your devices.
• Backup passphrase — client-side only; wraps keys and history for export you control.

There is no phone-number requirement for the messaging identity. There is no forced government ID or real-name check for core chat. Recovery channels you enable later remain optional and separate from the cryptographic identity.

  First launch
       │
       ├─► Email (recovery + abuse control, not tracking)
       │
       ├─► Choose username
       │
       ├─► generate IdentityKeyPair (EC P-256)
       │         │
       │         ├─ private → encrypted at rest on device
       │         └─ public  → uploaded for peer lookup
       │
       ├─► Backup passphrase  ──► later used by KeyBackup + .gbak export
       │
       └─► optional display name / avatar (metadata stripped)

Add contacts

Discovery is explicit. The app does not silently scrape an address book to build a social graph on the server.

Ways to connect

• Username search — People tab, exact handle, open profile, start chat.
• QR code — show yours or scan theirs with the in-app camera. Useful when both people are present.
• Invite link — short-lived link from settings or a group invite; recipient opens it in the app and accepts.

Once a one-to-one session exists, further messages no longer depend on the server for key material beyond the initial public identity lookup. The Double Ratchet keeps the conversation moving with per-message keys derived on the endpoints.

Accounts and multi-device

One identity can live on several devices. Each linked device holds the identity material it needs and maintains its own ratchet state with peers. Nothing auto-joins a new handset without either a link code from an already-authenticated device or a successful restore from an encrypted backup you created.

Device Management

Settings → Device Management lists sessions the account currently trusts (rough model, platform, last activity). From that screen you can revoke a device. Revocation stops that device from participating as an authorised endpoint for new ciphertext. If a lost device still holds local history, that history remains under keys the thief does not have your backup passphrase for — but you should still revoke so it cannot receive future traffic.

Moving to a new phone

• Device Transfer — when the old phone is still in your hands. Identity and local history move over a short-lived encrypted channel without writing an unencrypted intermediate file to disk or to the server.
• Backup restore — when the old phone is gone. Install, sign in with email, choose restore, select the .gbak file, enter the passphrase. Then revoke any device you no longer control.

Features map

Core chat is always available and always end-to-end encrypted. The same binary also carries safety and offline utilities so you are not forced to install a second suite of apps in environments where that is awkward or risky.

Create and manage groups

Groups are multi-party rooms built on top of one-to-one crypto rather than a single shared group secret. That makes membership changes and device compromise easier to contain.

Create a group

1. From the chat list or People tab choose New group.
2. Select members from contacts you already have a session with (or invite by username / QR).
3. Set a name and optional avatar (avatar metadata is stripped).
4. On create, your client generates a fresh sender key for itself and distributes that key to every current member by encrypting it under each member’s existing 1:1 Double Ratchet session.

How group traffic flows

  Member A                    Member B                    Member C
     │                           │                           │
     │  senderKey_A ────────────►│                           │
     │  (wrapped in 1:1 A↔B)     │                           │
     │  senderKey_A ─────────────────────────────────────────►│
     │  (wrapped in 1:1 A↔C)     │                           │
     │                           │                           │
     │  group msg under          │                           │
     │  senderKey_A ─────────────┼───────────────────────────┤
     │                           │ decrypt with stored key   │ same

Each member encrypts outgoing group messages with their own current sender key. Recipients look up the key they previously received from that sender. When someone is added or removed, keys rotate. A removed member does not receive the new material and cannot read messages sent after the rotation. Admins can force a rotation from the group info screen if a device is suspected compromised.

Lightweight signals such as reactions and read receipts are treated as delivery-tier metadata — the same design most modern messengers use for those events. They are not packed inside the end-to-end ciphertext of the main message body.

Message lifecycle

Understanding the path of a single message helps when something fails later.

  Sender device
       │
       ├─ 1. Advance send chain → one-time message key (MK)
       ├─ 2. AES-256-GCM seal plaintext under MK
       ├─ 3. Attach ratchet header (index, optional DH public)
       ├─ 4. Upload envelope (ciphertext + routing ids only)
       │
  Server
       │
       ├─ 5. Queue for recipient device(s)
       ├─ 6. Deliver when recipient is reachable
       ├─ 7. On delivery ack → delete envelope + delivery metadata
       │
  Recipient device
       │
       ├─ 8. Locate or derive matching MK (in-order or skip-cache)
       ├─ 9. GCM open; store plaintext under device encryption
       └─10. Ack delivery; server drop already scheduled

If step 8 cannot produce a key, the UI shows an unable-to-decrypt state for that row. The server still deletes its copy after the delivery policy expires; there is no permanent ciphertext archive to fall back on.

Push notifications (Firebase)

Android uses Firebase Cloud Messaging (FCM) so the device can wake when new ciphertext is waiting. The design constraint is strict: notification payloads must not carry message content.

What is sent over FCM

• A minimal wake / “ping” style signal that something is available to fetch
• Routing hints sufficient for the client to know it should sync
• Not message text, media bytes, or decryptable bodies

What happens after the ping

1. The OS delivers the FCM message to the app (subject to battery and system rules).
2. The client authenticates to SimXmil and pulls pending encrypted envelopes over the normal API path.
3. Decryption happens on the device with local ratchet keys.
4. Any user-visible notification text is composed locally after decrypt, or kept generic when content cannot be shown safely.

Even while FCM is in use, message confidentiality does not depend on trusting Google with plaintext. The push channel is treated as an untrusted signalling path. Reducing third-party push dependency further is an active engineering goal; the current path is already content-free by design.

User controls

You can disable notifications in system settings or in-app. Disabling push does not weaken encryption; it only changes how quickly the client learns that new envelopes exist. Foreground sync and manual refresh still apply.

Android permissions

The Android package declares on the order of two dozen permission entries so optional features can request OS capabilities when you use them. That count reflects a rich client (chat media, calls, offline navigation, sensor screens) — not a requirement that every permission be granted for basic encrypted messaging.

Privacy principle

Architecture keeps sensitive capture on the client. Camera frames for QR or photo attach, microphone samples for voice notes or the acoustic safety screen, and location fixes for offline navigation are processed on the device for the feature you invoked. Messaging does not require streaming camera or microphone to SimXmil servers. You choose which capabilities to enable according to your threat model and the OS permission dialogs.

Permission categories

Exact permission names and counts change with Android SDK levels and Play policy. The authoritative list is the manifest in the build you install. Deny any permission you do not need; related features simply stay unavailable until you grant them. The protocol assumes the client may refuse camera, mic, or location and still exchange encrypted text.

Safety toolkit — environment awareness

Several utilities exist to help you notice when the physical environment around the device may be hostile or simply unhealthy for careful work — strong local magnetic fields, unusual acoustic energy, and similar signals that can coincide with surveillance hardware, high-power electronics, or equipment that interferes with sensors and radios.

These screens do not claim laboratory-grade measurement. They use the phone’s built-in sensors, compare against a short baseline, and warn when readings leave the band you calibrated. The goal is situational awareness: you decide whether to move, power-isolate, or stop a sensitive session.

EMF / magnetic field screen

The EMF detector reads the device magnetometer — the same class of sensor the compass uses. It calibrates a quiet baseline, then flags spikes above a sensitivity threshold. Small powered electronics, transformers, speakers, and metal masses disturb the local field enough to show up. No extra dangerous permission is required for the magnetometer on Android; the screen is honest about limits in its info card.

• Calibrate away from obvious magnets and large metal surfaces when you can.
• Elevated readings turn a clear warning colour so you notice without staring at numbers.
• Use it when you care whether something powered is unusually close to the handset.

Acoustic safety screen

The acoustic detector watches microphone energy patterns for sustained or structured levels that stand out from ordinary room noise. It is a local awareness tool, not a product that uploads audio to the server. Mic permission is required only while that screen is active.

How this supports a safer session

• Detect — notice magnetic or acoustic anomalies near the device.
• Warn — UI state that is hard to miss when thresholds are crossed.
• Act — move location, enable power isolation / app lock, avoid sensitive typing, or run Guhya Burn if the situation demands a full exit.

High-frequency or high-power equipment near a user can cause unwanted interference, sensor noise, or simply indicate hardware you did not expect in the room. The toolkit is there so you are not flying blind; it does not replace professional RF survey gear when that is what the job needs.

Related privacy helpers

• Metadata scrubber — strip EXIF and document tags before you share a file.
• Clipboard guard — reduce accidental leakage of secrets into system clipboard history.
• App lock / power isolation — PIN or biometric before the UI unlocks; isolation modes for sensitive sessions.
• Steganography — when you must move a short secret through an image-only channel (see below).

Offline location

When cell towers and data are gone, you can still need a fix, a grid reference, or a nearest place name. The location tool is built for that case.

It uses the platform LocationManager path (GPS / GNSS, network, passive) without requiring proprietary Play Services. When satellites are visible, you can still get coordinates with no internet. When a network is available, an optional map layer can load; when it is not, the offline gazetteer, grid helpers, and compass / magnetic declination math still work from bundled data and sensors.

• Coordinates and accuracy — lat/lon, altitude, speed, provider, fix time.
• Grid reference helpers — offline conversion utilities for field notes.
• Magnetic declination — true vs magnetic bearing support from device models.
• Offline gazetteer — nearest place-style lookup from local data when the network is down.
• Mock-location awareness — the UI can surface when a fix looks mocked so you do not trust a spoofed point blindly.

Location permission is requested only for this tool and related navigation helpers. Fixes are for your on-device use; they are not streamed to SimXmil as a continuous tracking feed.

Steganography

Use this when you must move a short secret through a channel that only accepts ordinary-looking images. Prefer normal end-to-end chat when both sides are on SimXmil.

Embed

1. Open Steganography from Utilities.
2. Pick a cover image with natural texture (flat solid colours are a poor carrier).
3. Enter the secret text.
4. Choose a strong passphrase. It is not stored; you must supply the same string to extract.
5. Run Embed. The client derives a 256-bit key with PBKDF2-HMAC-SHA256 (120,000 iterations, random 16-byte salt), seals the payload with AES-256-GCM, prefixes magic GUHYA2 + length + CRC32, then writes bits into RGB least-significant bits of an ARGB_8888 bitmap and exports a PNG sized for typical chat limits.

Extract

1. Extract mode → select the PNG → enter the passphrase.
2. If magic, length, CRC, and GCM tag validate, plaintext is shown. Otherwise you get a specific failure.

Security properties

• An observer who only sees the image does not get the secret. Even LSB extraction still faces AES-256-GCM under your passphrase-derived key.
• Salt is unique per embed; iteration count is intentionally slow.
• CRC plus the GCM tag catch corruption and many accidental recompression failures.
• Re-saving as JPEG, heavy crop, or aggressive social-network recompression can destroy the payload. Keep the original PNG while the secret still matters.

  passphrase ──► PBKDF2 (120k, random salt) ──► AES-256 key
                                                      │
  secret text ──► AES-256-GCM ──► ciphertext+tag ─────┤
                                                      │
                         magic + length + CRC + payload bits
                                                      │
                                         LSB embed into PNG pixels
                                                      │
                                                 shareable PNG

Prabh V1 lab

Prabh V1 is the in-app diagnostics and self-repair surface for when a device or session is unhealthy and you need more than a vague error toast.

What you see

• Section health report: crypto stores, database, network, identity key presence, ratchet integrity flags.
• Recent client-side error log with timestamps.
• When logged in, optional server health score and per-check OK/FAIL lines.
• Robot version string so support can match behaviour to a known build.

What Auto-heal does

Heal runs safe repairs only: rebuild transient caches that can be regenerated from durable state, clear corrupted skip-key entries within bounds, re-check database integrity flags, trigger controlled re-sync where appropriate. It does not silently rotate or overwrite the long-term identity private key — that would orphan old messages. Identity changes remain explicit (restore from backup or confirmed rotation).

After heal finishes, the lab refreshes the report. If the real problem is a missing passphrase or a revoked device, the lab says so instead of inventing a fix. Open it from Settings → Advanced / Diagnostics → Prabh V1 lab.

Guhya Burn — full footprint wipe

Guhya Burn is the deliberate exit hatch. When you need the account and the local evidence of it gone, Burn is the path — not a soft logout.

What happens on the device

After the server-side burn step succeeds, the client runs a full local wipe. That includes:

• Session tokens and realtime connections reset
• Local encrypted database removed
• Identity key material cleared from secure storage
• Chat list, group admin, pin, theme, FCM, onboarding, app-lock, and related preferences cleared
• Internal cache, files, and code-cache directories wiped
• External cache when reachable
• Explicit garbage collection hints so residual in-memory structures are less likely to linger in RAM

What happens on the server

The burn request removes the account footprint the service is designed to hold for that identity: public account records, delivery state tied to the account, and related server-side session material. SimXmil does not keep a recoverable backup of your message content after a completed burn. Message bodies were never stored as plaintext on the server; post-burn, the account is not sitting on a quiet archive of old ciphertext either.

What Burn is not

• It is not a substitute for a .gbak you made earlier if you still want history on a new device. Burn is destruction, not migration.
• It cannot erase copies of messages that already landed on peer devices. Those peers still hold what they decrypted under their own keys.
• It cannot erase screenshots, exports, or files you already saved outside the app.

Use Burn when the priority is that your devices and the service no longer hold your identity and local state. If you might need the history later, export a .gbak first and store the passphrase offline — then burn if you still need the wipe.

  Guhya Burn
       │
       ├─► Server: remove account footprint / sessions
       │         (no retained content archive by design)
       │
       └─► Client wipeEverything()
                 ├─ DB, identity keys, session
                 ├─ prefs, caches, media dirs
                 ├─ FCM / lock / isolation state
                 └─ GC hints for residual RAM

Encryption model

The messaging path is a Signal-style construction using ordinary, well-studied primitives rather than a custom cipher suite.

• ECDH on P-256 (secp256r1) — initial agreement between identity keys and each Diffie–Hellman ratchet step.
• Double Ratchet — DH ratchet plus symmetric chain ratchet so each message gets a unique message key.
• AES-256-GCM — seal of message bodies and media (12-byte IV, 128-bit tag).
• HMAC-SHA256 — one-way chain and root derivation with domain-separation labels.
• Encrypted storage on device — identity material and local database; export paths add a passphrase wrap you control.

Servers see ciphertext and short-lived routing data. They do not hold private identity keys or per-message keys. A complete server breach does not yield historical plaintext.

ECDH in practice

Elliptic-curve Diffie–Hellman lets two parties compute the same shared secret without sending that secret across the network. SimXmil uses it in three places.

Identity ECDH

When you open a conversation for the first time, your device combines your identity private key with their published identity public key. They do the mirror operation. Both sides land on the same shared secret, which seeds the root key of the Double Ratchet for that peer.

Ratchet ECDH

As the conversation continues, each side occasionally generates a fresh ephemeral EC key pair, performs ECDH against the peer’s latest published ratchet public key, and mixes the result into the root key. That step provides forward secrecy and a measure of post-compromise recovery at the session level.

Group distribution

Group sender keys are not broadcast in the clear. Each copy is wrapped under the existing one-to-one session with that member, so group key distribution inherits the same ECDH-backed transport security.

Private keys stay on the device. Only public keys travel, encoded as JWK maps so Android and the web client stay interoperable on the same account.

  Alice identity priv ──┐
                        ├── ECDH ──► shared secret ──► seed RK
  Bob   identity pub  ──┘

  Later:
  Alice ephemeral priv ──┐
                         ├── ECDH ──► mix into RK, advance chains
  Bob   ratchet pub   ──┘

Double Ratchet, formal view

Each step is an HMAC-based derivation:

• RK, CK = KDF_RK(RK, DH(dh_self, dh_remote)) — once per DH ratchet turn.
• CK, MK = KDF_CK(CK) — once per message; chain step is HMAC-SHA256 with labels such as "msg" and "chain".
• ciphertext = AEAD_Encrypt(MK, plaintext, associated_data) — AES-256-GCM.

Because the chain KDF is one-way, holding a message key does not let an attacker walk backward to earlier keys. That is per-message forward secrecy.

Late and out-of-order delivery is handled by caching skipped message keys up to a fixed maximum distance. When a delayed packet arrives, the client uses the cached key once and discards it. Keys that were never cached and are already past are gone for good.

  RK ──DH step──► RK' ──► new send CK / recv CK
                    │
                    └─ per message:
                         CK ──► MK₀
                         CK ──► MK₁
                         CK ──► MK₂  ...
                         (one-way; MKᵢ does not reveal MKᵢ₋₁)

Group sender keys

A single shared group secret is hard to revoke cleanly when membership changes. Instead each member has their own sending key, distributed pairwise over existing 1:1 sessions.

• Member generates or rotates a sender key.
• For every other member, the key is encrypted under the 1:1 Double Ratchet session and sent.
• Outgoing group messages from that member use the current sender key.
• Recipients decrypt with the copy they stored when distribution succeeded.
• On leave, join, or forced rotation, new material is issued; excluded members never receive it.

Metadata and footprint deletion

Content secrecy is incomplete if the server keeps permanent logs of who talked to whom under stable identifiers. SimXmil is built so the server does not retain user content and does not keep long-lived message archives that could be decrypted later.

• Message bodies — encrypted on the sender. The server only handles ciphertext. Plaintext is not available to operators even while an envelope sits in a delivery queue.
• Delivery metadata — routing identifiers and queue entries exist only as long as needed. After the client acknowledges receipt, the server deletes the envelope and associated delivery records.
• Undelivered traffic — purged when it cannot be delivered inside the retention window. Status is learned on the client, not from a permanent server archive of content.
• Local tombstones — on-device markers so a re-sync does not resurrect a message you already deleted. Tombstones do not carry plaintext.
• No server full-text index of bodies — the server never had the plaintext to index.
• Guhya Burn — removes the remaining account footprint when you choose a full exit (see above).

Even if an encrypted blob is briefly present while a recipient is offline, after successful delivery the design goal is automatic removal of that footprint. The main content was never readable on the server; after deletion the ciphertext is gone as well.

Post-quantum roadmap (ML-KEM)

Production sessions today rely on classical ECDH. A future large-scale quantum computer would threaten the discrete-log assumption behind that curve. The planned answer is hybrid:

• Keep ECDH + Double Ratchet for compatibility and classical security.
• Add an ML-KEM (module-lattice key encapsulation, Kyber-class) share in parallel so session material is derived from both secrets.
• An adversary who records ciphertext now and later obtains a quantum machine still fails if the ML-KEM component holds.

Until hybrid ships, practical defences remain short-lived message keys, forward secrecy from the ratchet, deletion of ciphertext after delivery, and Guhya Burn when you need the account gone.

Backups and the .gbak format

Backups let you move phones or survive a wipe without teaching the server your plaintext. The file is useless without the passphrase you chose. A server-side Guhya Burn does not preserve a copy of this file for you — if you want recovery, you keep the .gbak yourself.

On-disk layout

• Magic: four ASCII bytes GBK1
• 16 bytes random salt
• 12 bytes random IV
• AES-256-GCM ciphertext (JSON bundle + authentication tag)
• Inside: backup metadata, wrapped identity key material, local message rows

Passphrase handling

The passphrase is stretched with PBKDF2-HMAC-SHA256 at a high iteration count (on the order of 210,000 rounds for the full file export path). Salt is unique per export. The passphrase is never uploaded in a form the server can use to unwrap the file. Lose it and the backup is gone by design.

Create

1. Settings → Backups / Export
2. Choose a high-entropy passphrase; store it offline
3. Save the .gbak file somewhere only you control

Restore

1. Install, sign in with email
2. Choose restore → select file → enter passphrase
3. On success, revoke devices you no longer trust

  .gbak file
  ┌────────┬────────┬────────┬──────────────────────────┐
  │ GBK1   │ salt   │  IV    │ AES-256-GCM(ciphertext)  │
  │ 4 B    │ 16 B   │ 12 B   │ JSON bundle + tag        │
  └────────┴────────┴────────┴──────────────────────────┘
         ▲
         │  passphrase ── PBKDF2 ──► file key

Key verification

Public keys on a server can be swapped by an active network attacker in the worst case. Safety numbers close that gap when you verify them out of band.

1. Open the conversation → info → Key Verification.
2. Compare the number or QR with your contact face to face, or over a channel where you already trust the identity.
3. If they match, mark verified. The client stores that fact locally and can alert you if the key changes later.

A sudden safety-number change after you verified is a stop sign. Re-verify before you continue with anything sensitive.

Account and password security

• Email — recovery and abuse prevention; not a substitute for the cryptographic identity and not a phone-based tracker.
• Login password (when used) — hashed server-side with a high-cost KDF; cleartext is not stored.
• Identity private key — on your devices only, encrypted at rest, except inside a passphrase-wrapped backup you export.
• Backup passphrase — recovery root of trust you store offline.
• Session tokens — bound to devices where possible; revocation invalidates them.
• App lock — local PIN or biometric gate; does not replace full-disk encryption.
• Guhya Burn — when you need local + server footprint removed rather than a soft sign-out.

Unable to decrypt

That banner means the client could not produce a valid message key for the ciphertext it received.

1. Missing identity key after reinstall — restore from .gbak, or start fresh sessions and ask peers to resend.
2. Out-of-order delivery on an old client — update to a build with skip-key support.
3. Group sender key never arrived — leave and rejoin, or ask an admin to rotate keys.
4. Device revoked — sign in only on a device you still control, or restore from backup.
5. Corrupt local ratchet state — Prabh V1 Auto-heal, then re-sync. Do not delete the identity key unless you have a backup.
6. Wrong account on the device — ciphertext for another identity will never open.

The protocol is strict on purpose. If the correct key is gone, the plaintext is gone. That is the cost of real forward secrecy.

Verify the app binary

• Google Play — official listing; Play signing is the primary trust path for most users.
• Official APK — download only from the domain published on the SimXmil site; check the certificate SHA-256 fingerprint before install.
• In-app integrity — where the platform allows, the client warns if the environment looks modified.
• Package name — confirm the installed package matches the official identifier (historical Guhya names still refer to this app).
• Updates — prefer Play auto-update; re-check signatures on every sideloaded APK.

Troubleshooting

When contacting support, send the Prabh V1 version string and a redacted health report. Never send private keys, passphrases, or message content.

Glossary

FAQ

Is SimXmil free?

Yes. Core messaging and end-to-end encryption are free. Optional plans may cover extended storage; encryption is not paywalled.

Do I need a phone number?

No. Signup uses email for recovery and abuse prevention. Email is not used to track chats or to require a carrier identity.

Can servers read my messages?

No. Bodies are encrypted on the device. The server relays ciphertext and deletes delivery metadata after acknowledgement.

What is Guhya Burn?

A full wipe of local state (including RAM-oriented cleanup) plus removal of the account footprint on the server. No recoverable content archive is kept for you after a completed burn.

What if I lose my phone?

Revoke it from Device Management on another session, or restore from your own .gbak with the backup passphrase.

Does anything work without internet or towers?

Offline location (GNSS when available), gazetteer, compass/grid helpers, and local EMF/acoustic safety screens work without a network. Messaging still needs connectivity.

Why “Unable to decrypt”?

Missing identity key, missing group sender key, revoked device, or an old client without skip-key support. See the dedicated section.

Is the protocol post-quantum ready?

Today: ECDH P-256 + Double Ratchet + AES-256-GCM. Roadmap: hybrid ML-KEM.

How are keys stored?

Identity private keys stay on devices except inside passphrase-wrapped backups you export. Login passwords are hashed server-side.

Do pushes include message text?

No. FCM is a content-free wake ping. Bodies are fetched and decrypted on the device.

Why so many Android permissions?

Optional features need optional OS capabilities. Grant by need. Camera and microphone are for on-device features and media you choose to send as ciphertext — not continuous server-side capture.

Is iOS available?

Coming soon. Android and web are available now.

About the SimXmil name

SimXmil is the current public name of the messenger previously shipped as Guhya. Accounts, encryption, package lineage, and server infrastructure are the same product under a new brand. Older screenshots, package names, and support threads that say Guhya still refer to this application — including Guhya Burn, which keeps that historical name in the product.

API reference, self-hosting notes, and a longer protocol whitepaper will land here as they are published. If a workflow you need is still thin, name the path and the docs can be extended around it.