GeoLira minimizes retention by data type. Anonymous community records have bounded retention, terminal Telegram delivery rows expire, and private owner data remains user-controlled until deletion or a documented account-retention rule applies.
Exact retention periods for anonymous and operational data
The current retention contract keeps anonymous community check-ins for 30 days, global intentions for 120 days and sacred-place suggestions for 365 days. Terminal Telegram delivery records in DELIVERED or DEAD state are removed after 30 days. These periods are defined in the runtime policy code rather than only in interface copy.
Private owner data and deletion rights
Owner-scoped private data has no automatic TTL in the current contract. The policy provides deletion on user request. Raw IP addresses are not persisted as rate-limit data. For selected anonymous features the system issues a deletion token that lets the holder of the receipt remove their own submission without requiring a public account identity.
Daily purge and browser-versus-server deletion
The nexaearth_privacy_retention_daily scheduler runs the retention process daily and computes cutoffs in UTC. Purging applies to the relevant server tables and only to terminal Telegram deliveries. Clearing localStorage, cookies or browser cache is not a server-side deletion request and may only remove a local receipt or session needed to perform a later operation.
4. Anonymous check-ins, 30 days
The documented technical retention policy keeps anonymous community check-ins for 30 days. Such entries contain limited self-ratings, time and possibly country, not a member's entire Account history. The period supports relevant aggregates and proportionate anti-abuse processes. It must not be misrepresented as a promise that every other GeoLira record disappears after 30 days. Previously published aggregates may not map one-to-one to individual submissions. Deleting an underlying record does not necessarily require deletion of lawful, effectively anonymous statistical results that no longer identify anyone.
5. Global intentions, 120 days
Symbolic global-intention submissions have a separate retention period of 120 days under the current policy. That period does not imply the effectiveness of a practice or require private journal notes to be stored for the same time. Submissions should conform to the form's permitted information and avoid unnecessary details about others. These records may be subject to safeguards against artificial inflation of activity counts. Retention and deletion should reflect the implemented procedure. Users can contact support or use a relevant deletion token where the feature provides one.
6. Place suggestions, 365 days
Suggestions of places can require longer review of sources, coordinates, land-access rules and licences for submitted material. The documented retention policy provides 365 days for this category. That period must not automatically be extended to Account information, messages or support correspondence. An erasure request concerning identifiable data must be handled under applicable law even if the general period has not elapsed. Submissions must not expose private home addresses or protected locations unlawfully. Material presenting risks may be restricted appropriately while an abuse report is assessed.
7. Terminal Telegram deliveries, 30 days
Technical Telegram delivery records can include an operation reference, status, time and outcome. Records in terminal states DELIVERED or DEAD have a documented retention period of 30 days. This is not the same as the time a message may remain within Telegram's independent infrastructure. Incomplete delivery attempts or other internal states can require different handling. Disconnecting the integration may stop future messages without removing all external messenger history. Members should also use the independent provider's privacy and deletion settings.
8. Private data without one automatic TTL
Private journal, dream, synchronicity and correlation records have no single automatic expiration period under the current retention contract. The Account owner has deletion functions for relevant personal records. Removing an underlying record can affect dependent calculations, so exporting information and reviewing dependencies first can be prudent. GDPR duties may require erasure or restriction even when the interface does not provide an automatic expiry date. Other people's rights, safety needs and statutory duties can justify limited retention in particular cases. A private journal should not be advertised as a guaranteed perpetual archive.
9. Backups, logs and device information
Disaster-recovery backups can contain system state needed after an incident, but should not be used for unrestricted access to private content. Restoring an older backup may require previously completed erasure requests to be reapplied appropriately. Security logs and mandatory records follow separate criteria based on their actual purposes. Deleting cookies, localStorage or browser cache removes selected device information, not all server records. Technical logs and recovery copies should follow the configured safeguards and data-minimisation principles. A uniform retention term must not be promised without verifying each system layer.
10. Erasure requests and rights of others
Members can use appropriate Account controls and applicable GDPR rights. Erasure requests should be assessed in light of privacy, legal duties and any rights of other people. Anonymisation or restriction of a necessary event record may be suitable where keeping its full association with an Account is no longer justified. A support request should contain only what is needed to verify authority and scope, never a password. The response should explain the action taken and lawful exceptions if relevant. Competent supervisory authorities and courts remain available as provided by law.