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 (unless Stealth Mode is on — see below)
- 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 Mode (sealed sender): an opt-in setting under Settings → Security, off by default. When enabled, your device omits the Sender User ID from the envelope entirely and instead seals a signed sender certificate to the recipient's identity key — only the recipient can recover who sent the message; the server cannot. An optional Privacy Pass anonymous token can accompany sealed sends, but the server does not yet require one. Stealth Mode 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 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
- ❌ Device model or OS version
- ❌ IP address logs (your IP is seen by the connection layer but is not persistently stored)
- ❌ Typing indicators or read receipts beyond delivery confirmation
- ❌ Third-party analytics or tracking SDKs
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.
A further mitigation — scheduled encrypted dummy/cover traffic, sent even when you are not actively messaging — is implemented in the client but not yet enabled in production builds pending a battery-impact design decision. This section will be updated when it ships.
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: All client-server communication uses gRPC over TLS 1.3 via a single Envoy proxy endpoint (port 443)
- At rest: Database encryption enabled
- End-to-end: Signal Protocol — X3DH key agreement (X25519) + Double Ratchet with ChaCha20-Poly1305 AEAD
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) |
| 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 content, no IP logs, no usage patterns)
- 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. Children's Privacy
Konstruct is not intended for users under 13 years of age. We do not knowingly collect data from children.
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) |