technical and privacy overview
what veyl stores and can read
private chat, vault, settings, and owner records are encrypted on the client before upload. we relay and store this encrypted content without holding the keys to read it or sign wallet payments. readable account and operational data are separate from that private content.
a server breach can expose public account data, operational metadata, and encrypted records. a stolen vault backup can be attacked by guessing its password offline. argon2id increases the cost of each guess; it does not make a weak password unguessable. stolen secrets, compromised devices, and malicious participants are other ways plaintext can be exposed.
0.85.0 · updated september 30, 2026
data storage
the diagram shows where plaintext is converted into ciphertext. the lists below separate client-held secrets, encrypted server records, and service data the backend can read.
sender deviceplaintext and private keys
encrypt and sign locally
veyl storageciphertext and metadata
route the same ciphertext
recipient devicesdecrypt and verify locally
kept on the client
veyl does not receive these values in plaintext. account credentials and private keys reside on the machine running the sdk, which may be a server operated by someone else.
- vault password and decrypted master seed
- wallet, chat-envelope, chat-signing, notification, vault-signing, and local-cache private keys
- decrypted conversations, media, settings, membership, previews, and private account state
- wallet signer and spending authority
- face id or other local biometric data
stored by veyl as ciphertext
veyl can store, deliver, expire, or delete these records without reading their private contents.
- password-encrypted vault seed backup
- encrypted private account settings and owner chat rows
- encrypted chat epoch history, settings snapshots, messages, actions, and attachments
- encrypted titles, custom pictures, retention settings, membership manifests, and delivery material
- recipient-sealed chat grants and notification descriptors
readable service data
the service processes this data to provide accounts, delivery, security, support, and abuse controls.
- account id, agreement state, username, avatar, and presence
- public chat, notification, vault-signing, and wallet keys
- passkey public records, session generation, credential identity, and revocation state
- push destinations and registered device records
- timestamps, ciphertext sizes, expiry times, opaque ids, row counts, and delivery activity
- network requests, access logs, security events, quotas, and short-lived abuse-prevention signals
- reports, evidence, feedback, and support information deliberately submitted by a user
if the server or application infrastructure is compromised
- copied database or storage
- exposes readable service data, ciphertext, timestamps, sizes, expiry, opaque identifiers, and activity patterns. it does not contain plaintext chat or wallet keys, but a copied password-encrypted vault can be tested against password guesses without contacting veyl or its login rate limits.
- project or application control
- can impersonate application authentication, alter stored state, and target future activity through changed backend or client software. control of authentication alone does not unlock a vault, but malicious client software can steal secrets when you use it. the offline password-guessing risk for copied backups still applies.
- device or participant access
- an unlocked client and an admitted chat participant hold readable data. malware, screenshots, downloads, copied secrets, or deliberate sharing are outside the server-encryption boundary. an agent can read messages addressed to it. whether it stores them or forwards them to a model provider depends on its operator. veyl’s deletion settings do not erase copies held by the agent or its providers.
private chat
notes, direct conversations, and groups use the same encrypted action format. group membership is represented by immutable cryptographic epochs, so changing membership also changes the secrets used after that point.
epoch 1encrypted manifest · 2 members
add member · fresh secrets
epoch 2encrypted manifest · 3 members
remove member · fresh secrets
epoch 3encrypted manifest · 2 members
- message body
- each private action is encrypted once with xchacha20-poly1305 under the current epoch body key and signed once with the actor's stable ed25519 chat identity. authenticated associated data binds the logical chat, epoch, protocol version, content id, suite, and flags.
- sender verification
- the actor and action type are inside the ciphertext. after decryption, the reader resolves the actor's signing key from that message's authenticated immutable epoch manifest and verifies the signature before applying the action.
- membership changes
- one stable random chat id links a chain of immutable membership epochs. adding, removing, or leaving creates a successor epoch with fresh content, settings, state, and delivery secrets. added members receive no earlier epoch secret; removed members receive no successor secret.
- server records
- the backend stores opaque chat state, epoch ids, encrypted settings, one ciphertext per action, encrypted owner rows, and encrypted epoch history. it does not store a readable participant list, sender, title, picture, action type, receipt, reaction, deletion, or retention setting.
- delivery
- initial introductions and grants are recipient-sealed records retained for up to 21 days and can expose authenticated endpoint routing needed for blocking and moderation. established delivery uses recipient-registered opaque capability hashes and overwritten inbox cursors instead of a stored chat-to-member index.
- attachments
- each attachment uses a fresh random file key and an independent opaque address. filename, visible media type, file key, caption, and message relationship stay inside the encrypted action. the service processes ciphertext size, expiry, and public management verifiers. forwards reuse the original encrypted file, so its download activity can be correlated.
- voice-call encryption
- direct calls use peer-to-peer dtls-srtp encryption, including when a turn relay carries the packets. group calls encrypt audio with sframe keys held by admitted, joined participants before sending it through the media relay. relays can route encrypted audio but cannot decrypt it. call admission and signaling are authenticated and encrypted separately from stored chat messages. direct peers can learn each other’s network addresses; participants can record what they hear.
- call metadata and retention
- call services process account authentication, opaque endpoint and room identifiers, network addresses, timing, traffic volume, quotas, and relay resource handles. encrypted discovery and signaling payloads expire after at most two minutes without renewal; revision counters and resource-cleanup state can remain. call-start and call-end notices are encrypted chat records with message retention. these limits do not define how long providers retain access logs or backups.
wallet keys and payment signing
the wallet signer is derived after the vault is unlocked on the device. veyl provides the application and network connection but does not hold the material required to sign a payment.
vault seedencrypted at rest
local unlock and derivation
wallet signerdevice memory
sign locally
signed paymentno private key attached
broadcast
spark and bitcoinexternal network visibility
- vault unlock
- the vault password is processed locally with argon2id. the seed backup is encrypted with aes-256-gcm before upload; veyl does not hold its unlock key. a successful local unlock derives the wallet, chat, notification, vault-signing, and cache material in the account session. password strength still matters if that encrypted backup is stolen.
- payment signing
- wallet actions are constructed and signed by the client-side spark wallet. veyl does not receive the decrypted seed, authenticated wallet access, or authority to spend, freeze, reverse, recover, or move funds.
- external visibility
- spark, bitcoin, internet, device, and hosting providers have their own visibility and retention. a payment published to bitcoin or another public network is observable and cannot be erased by veyl.
message retention and deletion
short retention reduces the readable history available after later access to an unlocked account or device. it also reduces the amount of encrypted message data present to copy during a later server breach.
unsaved message21-day deadline from creation
qualifying reads and chat departure
earlier expiryafter seen by default · optional 24h
hide in chat; schedule cleanup
active cleanupasynchronous ciphertext removal
- default: after seen
- the default is after-seen deletion. in direct chats and groups of up to 32 members, an unsaved message disappears from your device’s chat view when you leave after everyone in that message’s original membership group has seen it. an open chat can keep it visible until you leave. removing hosted ciphertext is a separate step.
- optional: 24 hours
- the optional 24-hour setting starts its timer when a client leaves after those reads and can commit cleanup with no other observed chat connections. it does not start at sending or the first receipt. once stored, the deadline is not extended by later reads or reopening the chat.
- 21-day limit
- new unsaved messages under the after-seen or 24-hour setting have a 21-day deadline from creation, even if unopened. that deadline takes precedence if the 24-hour timer would end later. groups over 32 members do not use read-based expiry; notes also use the 21-day deadline under the default setting.
- shared saving
- saving is shared: any current participant can save eligible messages for everyone, giving them no automatic expiry. any current participant can also unsave or delete messages they can access, or delete the chat for everyone. unsaving sets a fresh 21-day deadline that read-based expiry can shorten. forwarded and view-once attachments cannot be saved.
- attachment retention
- saving or unsaving an original attachment changes its hosted file expiry together with the message. automatic after-seen or 24-hour message expiry does not shorten the independent file deadline: unsaved encrypted files may remain for up to 21 days from upload, or from unsaving. forwards reuse the original file; deleting the original attachment or its chat makes uncached forwards unavailable.
- expiry and active cleanup
- official clients hide expired messages, but open chats, offline clients, or uncertain chat activity can defer shortening the stored deadline until the 21-day limit. database cleanup removes message ciphertext asynchronously, so it can remain fetchable after expiry. expired or deleted media receives no new download grants; existing grants can last up to 15 minutes unless the file is removed sooner. workers remove active file bytes asynchronously, and opaque deletion records can remain.
- provider retention
- deletion from active systems is separate from provider retention. production media storage retains deleted ciphertext for seven days through provider soft deletion. the production message database reports a one-hour version-retention window. these windows do not establish a physical-erasure deadline for every provider backup or log.
- why delete ciphertext
- short retention reduces the private history available to somebody who later controls an unlocked account or device. it also reduces the ciphertext available to copy during a later server breach, limiting exposure to a “harvest now, decrypt later” attack in which encrypted data is stored until future key compromise or cryptanalytic advances make decryption possible.
- account and group deletion
- account deletion removes account, profile, credential, encrypted vault, and encrypted owner records, and deletes notes and direct chats. it leaves group chats for remaining participants: their retained history, including saved messages, is not erased just because one participant deletes their account. a group is deleted when its last participant leaves.
- what deletion cannot revoke
- deletion cannot revoke plaintext or ciphertext already copied by a recipient, an agent or its model provider, content saved outside veyl, provider records retained under their rules, evidence deliberately submitted in reports or support requests, or payments published to a blockchain.