← Back to home

A private space.
Protection, explained.

Trust begins with clarity. Here is how your words and files are protected, where history lives, and what technical information makes a connection possible.

01 · Your words and files

Messages, photos, videos and documents are encrypted before transfer. The server delivers encrypted data without receiving the keys to read its contents. Protection uses AES-256-GCM, X25519 key exchange, HKDF-SHA256, Ed25519 digital signatures and a separate Double Ratchet session for each pair of participants. These are the mechanisms implemented in the app; an independent audit or certification of KOYA is not currently claimed.

02 · A name, without a questionnaire

KOYA does not ask for your phone number, email or identity documents. You use a chosen name and device keys; a pseudonym is welcome. A connection still needs technical information: the server can see IP connections, public identifiers, display names, room, timing and routing. These details do not reveal encrypted message content, but may show who connected and when. KOYA protects conversation content and lets you register without contact details; it does not conceal your IP address.

03 · Who gets access

An invitation is a room access secret, not a public business card. Share it with trusted people through a protected channel. A display name is not proof of identity: confirm who you are talking to through another means. The administrator controls infrastructure and admission policy. The demo-room invitation on this website is public and intended for testing: anyone can join. Do not use the demo room for private or work conversations.

04 · On-device storage

History is stored with SQLCipher. A PIN protects app access; device biometrics are supported. Use a strong PIN and a screen lock. A compromised device, a phone unlocked by someone else, screenshots and exported files sit outside the protection of the encrypted channel.

05 · Temporary server storage

For offline delivery, the server holds encrypted packets in a separate queue that survives server restarts. A packet is removed after recipient acknowledgement or after 24 hours. Limits are 512 packets per recipient and 64 MiB of encrypted frames in total. When the server cannot accept a packet, the client keeps the message locally and retries. HEAVY attachments use separate encrypted storage with sender-selected availability of one day, one week or no expiry within server policy. Incomplete uploads expire after one day; cancelled uploads are removed. Total file reservations are capped at 512 MiB. Server expiry does not remove cached or exported participant copies. Decryption keys are never sent to the server. Routing metadata and infrastructure logs are a separate category of data.

06 · Delivery and deletion

After an initial key exchange, updated clients can receive queued messages without the sender being online at the same time. Once the queue retention period expires, retry requires the sender’s phone and its saved message. Queue capacity, Android restrictions and network outages can delay delivery; the app shows the reason beside the message. Local clearing does not remove copies saved by other participants.

07 · This website

The landing page uses no advertising trackers, analytics, external fonts or personal-data collection forms. Technical web-server logs may include IP address, request time and path. Language switching opens a separate page and needs no cookie. Downloading the APK requires no registration.

08 · Self-hosted delivery

On-Premise places the server and apps on buyer-controlled infrastructure. You manage access; remote support is agreed separately. The website public demo is a separate test environment. Conversations, purchase enquiries and support enquiries are separate processing contexts. Legal duties follow actual activities.