MAVYRRetention Matrix
Last updated 2026-10-09
How to read these periods
The periods below distinguish when data becomes unusable from when stored records are removed. Scheduled deletion may take longer during an outage. A valid preservation obligation can extend the retention of covered data. Server expiry does not delete copies on other participants’ devices.
Messages: 24-hour server window
Encrypted message history becomes unavailable for synchronization 24 hours after the message timestamp. Expired history is checked for removal every hour; in normal operation, storage removal can therefore follow expiry by up to one hour. Delivery does not trigger immediate deletion.
Two exceptions matter: room state, including membership and room names, is excluded from this message expiry, and the messaging engine retains its final event in a room even after hiding it from users. The 24-hour setting is therefore not a promise that every record disappears after one day.
Your encrypted local history can remain on your device after server expiry. A device that stays offline beyond the server window may miss messages.
Invitations and sign-in
- Invitation codes: valid for creating one account and no more than two hours. Creating a code reserves one of three lifetime places; an unused expiry returns that place once no account creation remains pending. If the result is uncertain, the place stays reserved until the native registration state is reconciled. Creating an account permanently consumes the place, regardless of whether mandatory two-factor setup is subsequently finished.
- The temporary issuer-to-code-hash reservation is removed when consumed or released, unless preservation is required. The aggregate used-place count stays with the account, without recipient identifiers. Native code records are removed by cleanup after use or expiry once no registration is pending. Legacy issuance counters do not establish which old codes actually created accounts; the new policy uses a recorded one-time transition window without restarting it on each deployment.
- Authentication challenges: valid for ten minutes, with bounded attempts. Expired or completed challenges are removed by cleanup.
- Approved sessions: ordinary approval lasts up to 24 hours. If you choose to remember a device, approval lasts up to 30 days since authenticated renewal. Expired or revoked approval cannot be renewed without signing in again. Expired gateway authorization records are removed by cleanup; native device and token records have a separate lifecycle.
- Authenticator secret and backup-code hashes: retained while that enrollment protects the account. A used backup code cannot be reused.
- Password verifier, account identifiers, profile and plan entitlement: retained while the account exists; they are not part of hourly message expiry.
Devices, rooms and recovery
The separate device-access policy retains the account identifier, current selected device identifiers, known device identifiers and selection flags while the account exists. Known device identifiers remain after native device removal to prevent reuse from bypassing an explicit exclusion. The policy contains no device names or selection history and is removed with the associated account record.
Device registrations and public keys remain until device removal or account administration removes them. Room membership and other room state are retained separately from message history; leaving or archiving a conversation does not purge all server room state.
Encrypted key backups remain until removed through recovery or account administration. They can outlive the encrypted message bodies. The current service does not apply a blanket 24-hour expiry to these categories.
Local vaults, crypto state and encrypted history remain until removed on the device. Clearing local data does not by itself delete the server account. Account deletion is currently handled by the operator; there is no automatic inactive-account deletion schedule.
Connection and operational records
The messaging engine is configured to expire its user-IP records after one hour through its background cleanup. It receives an internal gateway address in this deployment; the public connection still reaches the reverse proxy. Other native device and security records are separate categories.
An additional hourly job clears stored device IP/User-Agent fields and removes native user-IP and daily-visit rows. These operational rows can be recreated between runs. Device identifiers, names and last-active timestamps are retained with the device. Cleanup stops when the preservation state is active or cannot be verified; downtime can delay deletion. Existing database snapshots follow their separate expiry.
Public MAVYR HTTP access logs are disabled. The service’s persistent operating-system journal and rotated administrative authentication logs use a 24-hour expiry checked hourly. Active blocks against repeated administrative login attacks can last up to seven days.
Provisioning records, login-accounting files and records on shared infrastructure do not currently have a verified common time limit. The 24-hour journal rule must not be read as a service-wide limit on every operational record.
Notifications
Browser push subscriptions expire no later than 30 days after renewal, the approved session expiry, or an earlier expiry set by the browser. Expired or disabled endpoint and delivery-key records are checked for deletion hourly. A valid preservation duty can defer deletion but does not restore notification access.
Disabling notifications removes the native pusher immediately when the service is reachable. For an inactive device, the messaging engine may retain an opaque routing identifier until its next attempted notification is rejected. This identifier does not contain the browser endpoint, message text or private message keys.
A generic alert sent to the platform push service has a requested delivery lifetime of five minutes. The platform controls its own operational records under its privacy terms.
Aggregate delivery diagnostics use one-hour observation windows in memory. An expired window is cleared on the next update or status check, and a service restart clears all counters. There is no stored notification history in these diagnostics.
Prepared billing retention
Paid checkout remains disabled. The prepared billing store makes checkout records eligible for deletion seven days after checkout expiry, so delayed payment notifications can still be matched to their original checkout. Webhook event hashes expire after 90 days; payment proofs expire 400 days after their paid period ends. Removal occurs during cleanup, subject to a valid preservation duty and operational interruptions.
The latest subscription state and the payer eligibility record remain while the account exists. They do not create a history of subscription-state changes. Account-linked billing records are removed with the associated account record, subject to applicable preservation handling. The cumulative payer counter is not reset by account deletion; unrelated event hashes expire separately.
The original account-creation timestamp used for plan calculation remains while the account exists. Monthly allowance boundaries are derived from that timestamp or the applicable paid plan period; unused allowance does not create a carried-forward record.
A configured preservation hold, or failure to determine its state, stops routine billing cleanup. It does not extend a paid entitlement. These local technical lifecycles do not determine how long the payment provider must retain its own financial records.
Cancellation requests and receipts
An unresolved cancellation declaration, or one whose receipt email has not been accepted for delivery, is not automatically deleted. It remains available for contract review and receipt delivery. The record is separate from an account, so deleting an account does not silently erase an unresolved cancellation.
After the request has been marked resolved and its receipt sent, deletion follows the explicitly configured retention period measured from resolution. No period has been activated for this release; submission remains disabled until the operator sets it together with the email configuration. We do not apply the hourly message expiry to contract declarations.
A valid preservation duty pauses deletion. The email delivery service and the recipient mailbox hold their own copies under their respective policies; local deletion does not erase those copies.
Database backups
Database snapshots are created every twelve hours on encrypted storage. Each snapshot expires after 24 hours and is checked by the hourly cleanup. A snapshot can contain a record already removed from the live database, so that record can remain in a backup for up to an additional snapshot lifetime.
A backup does not extend a message’s normal availability in the app. Restoration must account for expired records and applicable erasure requests before data is returned to ordinary use.
Support and legally required preservation
Support correspondence is kept while needed to resolve the request or meet a specific legal obligation; no fixed service-wide support period has yet been established. Preserved data and legal case records are retained for the period required by the applicable request and any remaining lawful purpose, with restricted access.
A preservation instruction does not automatically authorize disclosure. Once the applicable obligation ends, covered data returns to the relevant deletion process unless another documented obligation applies.