1. Introduction
Konstruct is a privacy-first, end-to-end encrypted messenger built on the Signal Protocol. This policy explains exactly what data we collect, why we collect it, and what we do not collect. We have designed Konstruct from the ground up to minimize the data we hold about you.
Core Principle: We collect the absolute minimum data necessary to route encrypted messages. Your message content is end-to-end encrypted — our servers cannot read it, and we do not attempt to.
2. Information We Collect
2.1 Account Identifier
Konstruct requires no phone number, email address, password, or real name.
- User ID: A unique opaque identifier derived mathematically from your device's cryptographic Identity Key. It is a random-looking string with no connection to your real identity.
- Username (optional): A display name you may choose to add. This is entirely optional and can be changed or removed at any time.
No personally identifiable information is required to create an account or use Konstruct.
2.2 Cryptographic Key Bundle
To enable the Signal Protocol key exchange, your device generates and uploads the following public keys to the server. Your corresponding private keys never leave your device and are stored in the iOS Keychain.
| Key | Type | Stored on server | Purpose |
|---|---|---|---|
| Identity Public Key | X25519 (long-term) | Yes, permanently | Authenticates your device; used in X3DH handshake |
| Signed PreKey | X25519 (medium-term) | Yes, rotated periodically | Used in X3DH key agreement |
| One-Time PreKeys (OTPKs) | X25519 (ephemeral) | Yes, until consumed | Consumed one-per-session for Perfect Forward Secrecy |
| Private keys | — | ❌ Never | All private keys remain on your device only |
The server tracks how many One-Time PreKeys remain and requests your device to replenish them when the supply runs low. Once an OTPK is used to establish a session, it is permanently deleted from the server.
2.3 Pending Message Queue
When you send a message, it is encrypted on your device before transmission. The server stores encrypted messages only until the recipient's device confirms delivery via a cryptographic receipt (ACK). After confirmed delivery, messages are permanently and irrecoverably deleted from our servers.
What is stored in the pending queue (until delivery):
- Encrypted message payload (opaque binary blob — we cannot read this)
- Sender User ID is omitted on the sealed-sender path (always on for eligible traffic — see Stealth below); only recipient-recoverable sealed cert travels instead
- Recipient User ID
- Message ID (UUID)
- Timestamp
- Message sequence number (required for the Double Ratchet algorithm)
- Ephemeral public key (part of the Signal Protocol ratchet step — not a secret)
If your device is offline, messages queue on the server until your next connection. If a message remains undelivered for an extended period, it may be discarded.
Stealth (sealed sender): always on for eligible user traffic (messages, receipts, call signaling, etc.; a few control paths are excluded by design). Your device omits the Sender User ID from the envelope and seals a signed sender certificate to the recipient's identity key — only the recipient can recover who sent the message; the server cannot. Privacy Pass anonymous tokens can accompany sealed sends for anti-spam; server-side token enforcement is still rolling out. Stealth does not hide message timing, size, or your IP address from the network layer.
2.4 Contact Relationships
When you add a contact (via QR code or invite link), the server stores a record of that relationship to determine message routing and stream subscription. This allows Konstruct to notify you when a known contact comes online and to subscribe you to their message stream.
2.5 Push Notification Tokens
To deliver real-time message notifications when the app is in the background:
- Apple APNs device token: Stored on the server and used solely to send a "new message" wake-up signal.
- Apple PushKit VoIP token: Stored separately and used solely to wake the app for an incoming voice/video call invitation. Like the APNs token, it carries no message or call content.
- No message content is ever included in push notifications. The notification contains only a generic signal that causes your device to connect and fetch the encrypted message, or — for calls — to present the incoming call.
2.6 Session Authentication
- Session token: A short-lived token stored in Redis (in-memory cache) to authenticate your gRPC connection. Expires automatically when you disconnect or the token expires.
2.7 Voice and Video Calls
Voice and video calls are end-to-end encrypted. Call setup — the WebRTC session description (SDP) and ICE connectivity candidates — is exchanged over the same end-to-end-encrypted message path as your chats, so our servers cannot read it. Call media (audio/video) uses WebRTC's DTLS-SRTP; because the media-encryption keys are exchanged and authenticated inside that end-to-end-encrypted signaling, the media is encrypted end-to-end between the two devices — neither our servers nor any relay we use can decrypt it.
To connect a call, the two devices exchange candidate network addresses (standard WebRTC ICE) to find a direct path. When a direct connection is not possible, encrypted media is relayed through a TURN server: the relay forwards only encrypted media it cannot read, but it does see the participants' network addresses. This connection metadata is necessary to route the call and is not linked to message content. Incoming calls are woken via the PushKit VoIP token described in 2.5; the push carries no call content.
2.8 Media Attachments
When you send a photo, video, file, or voice message, the attachment is compressed and encrypted on your device (AES-256-GCM under a fresh per-file key) before it is uploaded. The decryption key travels only inside the end-to-end-encrypted message to the recipient — it is never sent to, or held by, the media server. The server stores only the opaque encrypted blob, identified by a random media ID, and cannot read its contents.
Encrypted media objects are automatically deleted after approximately 7 days from upload (independent of whether they were downloaded); the recipient's device fetches and decrypts them within that window. We store no plaintext media and no media metadata beyond the encrypted blob and its ID.
2.9 What We Do NOT Collect
The following are explicitly not collected or stored:
- ❌ Phone number
- ❌ Email address
- ❌ Password
- ❌ Real name
- ❌ Message content (end-to-end encrypted — we cannot access it)
- ❌ Message history (deleted after delivery)
- ❌ Location data
- ❌ Typing indicators or read receipts beyond delivery confirmation
- ❌ Third-party analytics or tracking SDKs
2.10 IP Addresses and Connection Metadata
Connecting to any online service exposes your IP address to its servers at the network layer — this is unavoidable, and Konstruct is no exception. However, we do not store your raw IP address. For anti-abuse we derive a salted, one-way hash of the connecting address and use only that tag — never the raw address — to enforce per-address rate limits (for example, limiting device registrations and proof-of-work challenges). The hashed tag, not your real IP, is what appears in our rate-limit state and operational logs; the raw address is not written to our databases, and we keep no raw IP-to-account mapping.
We do not use your address, or its hashed tag, to build behavioural profiles, link it to your message content, or share it for advertising. In the interest of honesty: a salted hash reduces exposure rather than perfectly anonymising it — because the IPv4 address space is small, a party holding the secret salt could still test candidate addresses. It removes the raw address from everything we store; it is not a guarantee that your network origin can never be determined by our infrastructure.
If you want to keep your network address off the path entirely, route your connection through VEIL (our obfuscation transport), a VPN, or Tor — though the endpoint that terminates your connection still sees the apparent source address of that connection.
3. Traffic Analysis Protection
Konstruct implements message padding (rounding ciphertext to fixed size buckets) and randomised send-timing jitter to make it harder for a network observer to infer message size or exact timing from your connection. These mitigations are active by default and require no configuration.
We deliberately do not send scheduled dummy/cover traffic. Constant cover traffic needs an always-on connection and timed sends, which drains battery and data on a phone that is mostly asleep — a mobile client cannot sustain it, and forcing it would trade real usability for marginal metadata hardening. Padding and send-jitter (above) are our mobile answer; constant cover traffic could only ever run on an always-online desktop client and remains a possible desktop-only option, never a mobile promise. We would rather ship no cover traffic than claim one that isn't running.
Separately, VEIL is Konstruct's network-level transport obfuscation layer (obfs4 / WebTunnel pluggable transports, with a veil-front honest-front HTTPS layer in rollout). It helps your connection blend in with ordinary HTTPS traffic when direct TLS is throttled or blocked, but it is a censorship-circumvention mechanism, not a metadata-hiding one — it does not by itself prevent a network observer who can already see your connection from inferring message timing or size.
4. Anti-Spam: Proof of Work
To prevent message spam without requiring account registration, Konstruct requires your device to perform a small Proof of Work computation before sending each message. This is a client-side computation that imposes a negligible cost on legitimate use but makes large-scale spam computationally expensive. No personal data is involved.
5. How We Use Your Data
| Data | Purpose |
|---|---|
| User ID | Authenticate your device and route messages |
| Public key bundle | Enable Signal Protocol E2EE key exchange |
| Pending message queue | Hold encrypted messages until delivery |
| Contact relationships | Route messages and stream subscriptions |
| APNs token | Deliver background push notifications |
| PushKit VoIP token | Wake the app for incoming call invitations |
| Session token | Authenticate gRPC connection |
We do not use any collected data for advertising, profiling, analytics, or any purpose beyond operating the messaging service.
6. Data Storage and Security
6.1 Infrastructure
- Hosting: Self-hosted VPS (Amsterdam, Netherlands)
- Persistent storage: PostgreSQL database (account data, key bundles, contact relationships)
- Ephemeral storage: Redis (session tokens, pending message queues)
- Jurisdiction: Netherlands / European Union — GDPR applies
6.2 Encryption
- In transit: Client–server messaging uses a gRPC bidirectional stream over QUIC when available, with automatic fallback to gRPC over HTTP/2 + TLS 1.3 (Envoy / edge on port 443). Control and auth RPCs use the same encrypted transport stack
- At rest: Database encryption enabled
- End-to-end: Signal-Protocol-based — X3DH / PQXDH key agreement (X25519 combined with the post-quantum ML-KEM-768) and a Double Ratchet with ChaCha20-Poly1305 AEAD. Sender authentication uses hybrid Ed25519 + ML-DSA (post-quantum) signatures. Media attachments are encrypted with AES-256-GCM under a per-file key.
6.3 What Is Stored on Your Device
Your device stores the complete message history locally in encrypted storage (iOS data protection). This includes:
- Full conversation history
- Media attachments
- Contact list and display names
- Crypto session state (Keychain)
- Draft messages
This data is under your control. Deleting the app removes all local data permanently.
6.4 Data Retention
| Data type | Retention |
|---|---|
| Pending messages | Deleted immediately upon confirmed delivery (ACK) |
| Media attachments (encrypted) | Auto-deleted ~7 days after upload (by object age, regardless of download) |
| One-Time PreKeys | Deleted from server upon consumption |
| Session tokens | Deleted on disconnect / expiry |
| APNs token | Retained until account deletion or token update |
| PushKit VoIP token | Retained until account deletion or token update |
| User ID + username | Retained until account deletion |
| Signed PreKey | Replaced when rotated; old key deleted |
| Contact relationships | Retained until contact is removed or account deleted |
7. Data Sharing and Third Parties
We do not sell, rent, or share your data with any third parties for any commercial purpose.
7.1 Infrastructure Providers
- VPS hosting provider (Netherlands): Provides the physical server. Has no access to application data or encryption keys.
- Apple APNs: Receives only your device push token and a generic notification signal (no message content). Subject to Apple's privacy policy.
7.2 Legal Compliance
We may be required to disclose data if compelled by a valid legal order from a competent authority. However:
- We cannot decrypt your messages (end-to-end encrypted)
- We hold minimal metadata — no message content, no raw IP addresses (only salted hashes for anti-abuse, see Section 2.10), and no behavioural or usage profiling
- We will notify affected users unless legally prohibited from doing so
8. Your Rights
8.1 Anonymous Use
You can use Konstruct with no personally identifiable information. Your User ID is a cryptographic hash with no connection to your identity.
8.2 Access to Your Data
You may request a copy of any metadata associated with your account at any time by contacting us at the address below.
8.3 Account Deletion
You can delete your account from within the app settings. Upon deletion:
- Your User ID, username, and public key bundle are permanently deleted from the server
- Your contact relationships are removed
- Your APNs and PushKit VoIP tokens are removed
- Any pending undelivered messages are discarded
- Deletion is completed within 24 hours
Messages previously delivered to recipients are stored locally on their devices only and are outside our control after delivery.
8.4 Username
You can add, change, or remove your username at any time from account settings.
9. Minimum Age
Konstruct is intended for users 16 years of age and older, consistent with the app's 16+ App Store age rating. It is not directed to, or intended for, anyone under 16, and we do not knowingly collect data from anyone under 16. Because Konstruct holds only the minimal routing metadata described above and no message content, the data associated with any account is limited by design. If you believe someone under 16 is using Konstruct, contact us (Section 12) and we will act accordingly.
10. Federation (Planned)
Konstruct is designed with federation in mind. When federation is available:
- Your messages may be routed through other independently-operated Konstruct servers
- Each server operator is responsible for their own privacy policy
- End-to-end encryption remains fully intact across federated servers — federated servers handle only the same encrypted payloads as the origin server
Federation is not currently active. This section will be updated when federation is introduced.
11. Changes to This Policy
We will notify users of material changes through:
- An in-app notification
- An updated "Last Updated" date on this document
Continued use of Konstruct after changes constitutes acceptance of the revised policy.
12. Contact
For privacy questions, data access requests, or concerns:
- Email: maxim.elis@icloud.com
- Website: konstruct.cc
Summary
| No phone number or email required | End-to-end encrypted (Signal Protocol) |
| Fully anonymous use supported | Messages deleted after confirmed delivery |
| No tracking or analytics SDKs | Traffic obfuscation built in |
| Private keys never leave your device | Minimal metadata only |
| No third-party data sales | GDPR jurisdiction (EU, Netherlands) |