Data Retention Policy

Version: retention-2026-10-29-v1. Effective date: 29 October 2026.

Legal operator and grievance officer: Sunny Shashikant Solanki. Correspondence address: 38 Shreejinagar Society, Godhra, Gujarat, India. Support, privacy, grievances, child-safety reports and account-deletion requests: sunnysolanki6359@gmail.com.

Account, profile and registration records

Profiles, avatar choices, private preferences, activities and activity messages have no general automatic expiry currently implemented. Successful completion removes the registration-draft row through the supported client flow; interrupted drafts and separate appearance drafts can remain. When eligibility is enabled, its records store the current declaration version and server time against the account; a supplied birth date is processed for validation, not saved in the profile or declaration table. Provider logs are separate.

Private registration selfies and avatar images

The mandatory registration selfie is stored privately and has no implemented general expiry. The current account-completion check depends on its referenced object being present. Removing metadata alone does not remove image bytes. Support can receive withdrawal/deletion concerns; no automated selfie-free alternative is claimed. Static bundled character art is application content, not a user's private selfie. Advanced uploaded preview generations have their own Storage lifecycle and can remain pending cleanup.

Location, activities and chats

Device location used for map centering is distinct from saved activity venues. Activity coordinates and content remain social records; an activity ending or a member leaving does not itself erase them. Sender deletion can cascade their messages; deleting an activity can remove associated conversation and participation records, including contributions from other members. Copies or moderation snapshots can have separate retention.

Friendships, notifications and authentication

Friendship, invitation, participation, block, notification-event and device-token records have no general automatic expiry currently established. Auth/account deletion uses applicable database cascades and separate Storage cleanup. Some legacy actor/activity references in other members' notification payloads remain a known cleanup limitation of the current production deletion implementation. Do not interpret a removed account row as proof that every reference or provider-held byte is gone. Push delivery remains disabled.

Moderation evidence, decisions and appeals

Configured cleanup-eligibility thresholds are 180 days for evidence, 180 days after case closure or 365 days from creation for open cases, 365 days for audit records, and 180 days after review for reviewed appeals. Restrictions, pending appeals and lawful preservation holds can defer cleanup. These thresholds require actual authorized purge execution and verification; they are not guaranteed maximum retention periods. Free text can remain identifying after an account-reference field is nulled. Necessary lawful holds require authorized handling and review.

Deletion requests and support messages

The monitored shared contact receives support, privacy, grievance and deletion requests. Account deletion does not automatically remove inbox, sent-mail, trash or provider backup copies. No automated support-mail expiry is claimed. Request only information necessary to assess ownership and the issue; do not send passwords, verification codes, identity documents or private selfies unless a separate lawful and secure process is specifically established.

Backups, logs and incomplete uploads

Encrypted recovery snapshots and offsite copies are separate from live account data. They are not rewritten automatically by an account deletion. No automatic backup rotation, offsite version/trash purge or universal provider log period is promised. Before a restored copy is returned to service, applicable erasure, restriction and access-revocation decisions must be reconciled.

Resumable-upload session expiry and empty object listings do not establish physical fragment erasure. Provider-specific cleanup evidence is still required for the pending deletion upgrade. A quarantine period used in testing is not a maximum fragment-retention promise. The coordinated A2 replacement is not deployed to production.

Requests about continued retention

Contact the privacy/grievance address to request applicable access, correction, erasure or withdrawal and to ask about a pending deletion. Technical failures, outstanding ownership checks and lawful retention exceptions must be explained; unresolved work must not be reported as completed. This policy describes current behavior without inventing automatic cleanup schedules.