Frequently Asked Questions

During registration, the app receives a cryptographic Proof of Work challenge from the server and solves it — this prevents automated bot registrations. At the same time, several cryptographic key sets are generated on-device: long-term identity keys, signed prekeys, and one-time prekeys (including post-quantum ML-KEM-768 keys). Only the public parts of these keys and the PoW result are sent to the server. Private keys never leave your device. Your identity is these keys — there's no password to steal or recover.

Not yet. In conventional messengers, "sign out and back in" means entering a username and password. Here your identity is the cryptographic keys stored on your device — without them, you can't authenticate. Deleting the app is equivalent to losing your account.

In Settings you can generate a seed phrase — a sequence of words that can reconstruct your private keys. It works the same way as a recovery phrase in crypto wallets. Write it down and keep it somewhere safe — this is the only way to transfer your account to a new device.

The system is designed so that a stranger cannot simply start messaging you. To start a conversation, one of you shares a QR code or an invite link and the other scans or follows it. Those are single-use and expire in twelve hours — a link that has been accepted once cannot be accepted again. Separately, you may switch on discovery in settings and be findable by username; that is off by default, so unless you turn it on, an invite is the only way in.

It's an intentional design choice. In most messengers, knowing someone's phone number or username is enough to start flooding them with messages. Here, mutual consent is baked into the architecture — not just declared in a privacy policy.

A code can be accepted only once, so a shared link lets in at most one person, and a link that has already been used does nothing at all. It also stops working twelve hours after it was created. If someone does get in, you will see a new conversation and can block them immediately.

All messages are encrypted on the sender's device before transmission and can only be decrypted on the recipient's device. The server sees only an encrypted stream and routes it — it cannot read the content. Key establishment uses X3DH extended with post-quantum key agreement (PQXDH): the sender encapsulates an ML-KEM-768 secret to the recipient's Kyber prekey and it is mixed into the ratchet, which is what limits "record now, decrypt with a quantum computer later". One honest detail: the contribution is applied after the first message, so message zero of a new conversation is protected classically and everything from the second message on is not. Messages then use Double Ratchet, which rotates keys with every message, so compromising one key exposes neither past nor future messages.

Very little, and none of it is you. To route a message the server needs an opaque account id for the recipient, the size of the ciphertext and the time it arrived; it also holds your public keys and a push token. That is the list. It does not see the content, your name, your avatar, your contact list — or, on the sealed-sender path that is always on, who sent the message. Delivered messages are not kept. A username is optional, is not used for routing, and is stored only as a keyed hash for the sole purpose of letting people find you — and that lookup is off until you switch discovery on, so by default an account cannot be found by name at all.

This is the harder part. The server can still observe that someone delivered ciphertext to device B (recipient, time, size). With always-on Stealth (sealed sender), it does not learn who sent that ciphertext — see the next question. Censorship protection partially obscures the network path. Full anonymity at the routing layer (hiding from the recipient's side and from network-level IP/timing correlation too) is a problem of a different order of magnitude and isn't solved today.

No — the sender field is left out of the envelope, and this is always on for ordinary traffic (messages, delivery receipts, call setup, profile sharing). There is no switch to forget. Your device seals a signed sender certificate to the recipient's key: the recipient can open it and verify who wrote, the server cannot. A few internal paths — keep-alives, syncing your own devices, session housekeeping — still carry a sender by design.

It is worth being precise about what is being hidden, because it is not an identity. The server never had one: an account here is a keypair and an opaque id, with no phone number, email or real name attached, so there is nothing to link to a person in the first place. What sealed sender removes is the last link between two of those ids — who wrote to whom. The network layer is a separate matter and is covered above: timing and IP remain visible, and that is where a well-resourced observer works.

Honest limits: Stealth hides the sender identity from the server, not message timing, size, or your IP address — those remain visible at the network/transport layer. Privacy Pass tokens can ride along for anti-spam; server-side enforcement is still rolling out, so treat token-based rate control as maturing, not finished.

No — none. No analytics, no usage metrics, no behavioural events, no crash phone-home, no advertising identifiers. Not "collected and anonymised" — not collected. The app has no third-party trackers (no Firebase, Crashlytics, Sentry, Amplitude, Segment); its only external dependencies are transport/media infrastructure and an on-device ML library. Production builds also write no diagnostic logs to disk and expose no debug or log-export screen. When we need logs to fix a bug, it is you who taps "share" in a beta build — never a silent upload.

Your Display Name and avatar live on your device; they are not part of your public profile and nobody can look them up. When you start a new conversation the other person sees only a generated pseudonym, deterministic — always the same for a given ID. To show them your real name and photo, open their profile and tap "Share Profile": both travel over the encrypted channel. One exception: if you send a contact request, your username and Display Name are attached to it so the recipient can tell who is asking. The server stores that snapshot encrypted at rest, under a key the server itself holds — it is not end-to-end encrypted, and your avatar is never included.

A blank name would be awkward — you'd see featureless rows in your chat list with no way to tell contacts apart. The generated name is stable: "Quick Falcon" is always "Quick Falcon" for that ID, on any device.

Yes. Display priority: Display Name (if they shared it) → username → generated name. So if someone registered with @john, you'll see that, not "Peaceful Whale".

• Sending being encrypted on your device
• Sent it left your device and the server accepted it
• Delivered the recipient's device decrypted it and sent back a confirmation
• Queued it has not gone out yet — the app keeps trying by itself; tap if you would rather not wait
• Failed it was rejected for a reason retrying will not fix, so nothing happens automatically; tap to try again

There is no "read" status, and that is deliberate: a read receipt would tell the sender when you opened the app, which is a fact about you that the message does not need. "Delivered" is an encrypted receipt from the recipient's device — not the server saying it forwarded something.

Yes, editing is supported. After changes, the message is marked as "edited". The edit propagates to the recipient's device through the same delivery mechanism as regular messages.

Notifications are delivered through Apple Push Notification Service (APNs). A stable internet connection is required. If the phone is in airplane mode, behind a VPN with aggressive filtering, or Apple decided the push was "low priority" — the notification may be delayed or not arrive at all. When the app opens again, messages sync automatically.

There is a censorship-protection mode that changes how the app reaches the network when a direct connection is blocked. In Settings it is a single control with three positions — off, automatic, on — and automatic is the default: the app uses a direct connection while it works and switches only on demonstrated failure. There is nothing to configure and no addresses to enter; setup happens in the background. The implementation is open source, so the design can be reviewed by anyone.

By default it is automatic — a direct connection is faster, so the app uses it while it works and switches only when it demonstrably fails. You can also force it on or off. What we deliberately do not publish is which techniques are live and where they currently do or do not get through: a public, up-to-date status report is free feedback for whoever is doing the blocking, and the app itself shows none of it either, for the same reason.

Messaging stops until it returns. The alpha runs on a single trusted server, and there is no second path today — no relays, no peer-to-peer, no other instance to fall back to. Anything encrypted stays encrypted and nothing is lost; it simply will not move. Making that untrue is what the roadmap is about, and none of it has shipped.

Yes — unconditionally. Sending messages, receiving messages, E2EE, and all security features will never go behind a paywall. Donation-only models have historically proved fragile for privacy projects, so Konstruct plans a mix: voluntary donations, optional premium features (larger file transfers, extended history, custom themes — never security features), and B2B hosted instances for organizations. The core will always be free.

No ads, data resale or telemetry — the flip side is that Konstruct runs on voluntary donations. They go directly to development and the server. Prefer Monero (XMR) if you care about privacy — unlike Bitcoin its chain isn't public. Always cross-check an address against the project repository before sending, in case a page is tampered with.

• Monero (XMR) — recommended:
  496i5qvPzRtJPQjiPXnLvEGutjHFth4pWDQaJwbbMreyaTYg4qfbo48MXrTnYH32MHiAn5GcSEN1c48EYBvVkrx9Pi5BWvn
• Bitcoin (BTC):
  bc1q5cthgu6k9utg9hk2mx2xshdtsrhvu54ysmqhmm
• Ko-fi — convenient but not private, the processor knows your identity:
  ko-fi.com/construct_msg

P2P mode is planned, not yet implemented — all traffic currently goes through the central server. The target design: when both users are simultaneously online and connected to a Konstruct server, the server will signal them to upgrade to a direct peer-to-peer QUIC connection. Once established, the server exits the message relay path — traffic flows directly between devices. If either side goes offline, delivery falls back to the server.

For this, the app has Lockdown Mode. When enabled, notifications only come from people who were in your contacts at activation time. Messages from new senders are still saved — they just won't disturb you. Useful if you're a public figure and want to temporarily close off from new contacts.

If a suspiciously high number of messages arrives from a single sender in a short time (more than ~10 in 30 seconds), the client automatically shows a warning and mutes notifications from them. You can then allow them (if it was a glitch) or block them. Importantly: this is receiver-side protection and works regardless of what client the attacker uses.

A session is an established encrypted channel between two devices. It's built on one-time keys that can't be reused, and keys rotate with every message. If the app was inactive for a long time, the device was reinstalled, or state desynchronization occurred — the session may stop decrypting incoming messages. In this case, automatic session healing kicks in: the app renegotiates keys and restores the channel in the background. Usually the user notices nothing — messages just start arriving again.

Sync between multiple devices (phone + desktop) is in development. The desktop app exists as a prototype. Since identity is tied to keys rather than a server account, multi-device support requires a separate key-binding mechanism — we're working on it.

Live messaging is a gRPC bidirectional MessageStream — one long-lived stream for heartbeats, inbound messages, and delivery receipts — not request/response polling. On current iOS builds the production path is QUIC (construct-transport); if QUIC is blocked or the handshake fails, the client falls back to gRPC over HTTP/2 + TLS 1.3 automatically. End-to-end encryption is independent of the transport: the wire only carries sealed ciphertext.