Data lifecycle

Message retention and deletion

Silent Key uses temporary message timestamps, defensive hiding and administrative cleanup. Those are related processes, not identical events.

Seven-day expiry timestamp

When a new message is created, the client assigns an expiresAt timestamp seven days in the future. Conversation screens compare that value with the current time and exclude expired messages from the active view.

Administrative cleanup

The current maintenance design does not depend on paid Firestore TTL. An authorized administrator can query messages whose expiry time has passed and delete them in bounded batches. Running bounded operations reduces the chance that one huge cleanup exceeds browser, network or Firestore limits.

Conversation summaries after deletion

A conversation document stores preview metadata so chat lists can show the latest message and unread state without loading every message. When cleanup or an admin deletes messages, Silent Key reloads the remaining messages and rebuilds that summary. If no active message remains, it clears the preview text, preview timestamp, last sender and unread counts.

The conversation document itself remains. Participants therefore continue to see an empty connection rather than losing the contact because the history expired.

Defensive preview hiding

A stale preview can exist temporarily when cleanup has not run, a network request fails or an older deployment wrote incomplete metadata. The chat list performs an additional expiry check and hides previews that are known to be expired. This is a display safeguard, not a substitute for server deletion.

Deletion by users and administrators

“Delete for me” hides a message from one participant’s view where supported. “Unsend” changes the shared message state within the configured time window. Administrative deletion removes a message record from Firestore. Clear-all maintenance deletes message records while deliberately preserving the conversation connection.

What retention cannot control

Practical expectation

Treat seven days as the normal in-app message lifetime, not as a forensic guarantee that every representation disappears globally at one exact millisecond. Users should keep their own copies of information they need and avoid sending information that cannot safely be copied.

Device clocks, offline state and delayed writes

The interface compares timestamps with the device clock, while Firestore also supplies server timestamps for important records. A badly incorrect device clock, a tab that remains offline or a delayed synchronization can make local timing appear unusual. Refreshing after network recovery lets the application reconcile with Firestore, but it cannot guarantee that every device shows the change simultaneously.

Persistent browser caching may keep locally synchronized data for offline use. Signing out and clearing site data can remove local application state from a device, but server records remain governed by the service’s deletion process. Shared or public computers should not be treated as private merely because a message has expired in the main view.

Sponsored Partner

Workspace & Creator Essentials

Discover minimalist mechanical keyboards, artisan keycaps, and ergonomic desk accessories from our partner TwinCraft.