Data Retention & Memory Ethics

Why memory ethics matters

Most systems collect data because they can. Then they keep it because it’s “useful.” Then, without meaning to, they become a permanent memory of people who never asked to be remembered forever.

This project is different in purpose. It’s a practice-support relay — a steady lane where people show up, sometimes quietly, sometimes intensely, sometimes for five minutes, sometimes for an hour, sometimes after a long break. That kind of lane needs enough memory to keep continuity honest… but not so much memory that it becomes surveillance.

So we work from a simple stance: ethical memory is bounded memory. We keep what is needed to run the relay, keep the system safe, and keep your experience steady — and we aggressively limit the rest.

Stewardship-first retention

“Stewardship First” isn’t only about design and uptime — it’s also about data. Retention rules are part of the product’s character. They decide whether a system is a quiet tool, or an attention business wearing a friendly mask.

Our retention philosophy is built on four ideas:

• Minimum necessary — if we don’t need it, we shouldn’t store it.
• Time-bounded — raw detail should expire; long-term history should be aggregated.
• User-respectful — export/delete should be practical, not performative.
• Readable trust — the rules should be public and stable, not hidden in code.

This is also why we avoid ads and ad-tech: tracking systems tend to expand retention “because it improves targeting.” See Why we don’t use ads.

The four layers of memory

It helps to think of data in layers. Not everything should live forever in the same place. We separate memory into layers so we can keep the relay reliable while still letting detail fade.

• Device memory — small local settings and cached values to keep the PWA fast and resilient.
• Hot storage — the current operational database used for active features and recent history.
• Archive storage — a JSON “off-boarding archive” that removes user detail from hot storage while preserving your export.
• Aggregated history — non-identifying rollups that keep community totals meaningful without keeping raw detail forever.

Ethical retention means pushing data down the stack over time: from raw detail → to rollups → to expiry.

Retention rules at a glance

The exact durations are published so they remain readable. Here is the policy intent in plain English. (If implementation ever differs, implementation is a bug — the policy is the contract.)

• Session detail: stored short-term for accuracy, debugging, and continuity; then rolled up and/or archived.
• Totals and aggregates: kept longer because they are not identifying in the same way raw logs can be.
• Operational logs: kept briefly for security and reliability, then purged.
• IP-derived location: approximate only (city/country/timezone), minimised and time-bounded.
• Email (if you opt in): stored only for the purpose you agreed to, with unsubscribe and deletion pathways.
• Exports: available in JSON; deletion removes personal data while preserving non-identifying aggregates.

For the broader privacy overview, see Privacy & GDPR (Plain English).

What we store for sessions

To run a relay, the system needs to know when a session starts, when it ends, and what totals should be credited. A typical session record may include:

• Anonymous user ID (UID) so the session can be attributed to the correct account/device.
• Start/stop timestamps in UTC for consistent time handling.
• Duration and counters to compute personal totals and community presence.
• Minimal integrity markers (e.g., whether the session was resumed after a pause) to prevent double-counting.

We do not need (and do not want) detailed behavioural telemetry about how you move through screens. The aim is continuity, not profiling.

From raw detail to aggregates

The most important retention decision is what happens as time passes. A system that keeps raw logs forever quietly becomes a permanent biography. A stewardship-first system lets detail fade and keeps only what remains meaningful without being invasive.

Our approach is:

• Short-term: keep recent session detail to ensure totals are accurate and to resolve support issues.
• Medium-term: roll up older session detail into daily/weekly/monthly aggregates.
• Long-term: keep non-identifying aggregates (community totals) without keeping personal raw logs forever.

This keeps the relay stable while reducing the “memory footprint” the system holds about any one person.

Exact retention targets

Below are the default retention targets we publish as policy. If we change them, we will update this page and date-stamp it. If you prefer stronger minimisation, you can request off-boarding archive + deletion at any time.

• Session event detail (hot storage): retained for a limited operational window, then rolled up and/or archived.
• Daily/monthly aggregates: retained longer because they support continuity while being less revealing than raw session logs.
• Approximate location (city/country/timezone): stored as derived fields to support community totals, not as precise tracking.
• Operational logs: kept briefly for security and uptime, then purged.
• Backups: time-bounded retention, not indefinite.
• Off-boarding archive JSON: created on request (or admin off-boarding) so your data can be exported and removed from hot storage.

If you want these targets represented as an on-page “Retention Table” later, I can format a compact HTML table that matches your site styles and stays WCAG-friendly.

IP addresses and geo caching

To show a meaningful relay across time zones, the system may derive an approximate city/country/timezone from your IP address. We do this to avoid requesting precise GPS location.

Stewardship-first constraints apply here:

• Approximate only — city/country/timezone, not street-level location.
• Minimise repeats — use caching at the network-block level (e.g., /24) so we don’t re-query excessively.
• Time-bounded — IP-derived signals should not become a long-term tracking record.
• Operational purpose only — relay totals + abuse prevention, not profiling.

If you don’t want location-derived grouping applied to your profile, you can request removal of those derived fields in a deletion request.

Operational logs and security signals

Every online service needs minimal logging to remain reliable and safe. Logs help detect abuse, diagnose outages, and ensure integrity. But logs also carry risk if they become long-term shadow biographies.

Our stance:

• Collect less — avoid logging sensitive payloads unless necessary for debugging.
• Keep briefly — logs should be time-bounded and routinely purged.
• Restrict access — admin-only access, least privilege.
• Separate concerns — operational logs are for reliability/security, not product marketing.

For the uptime and health-check approach, see System Integrity & Uptime.

Backups are not forever

Backups exist to recover from disasters and mistakes. They are not a reason to retain personal data indefinitely.

Stewardship-first backup policy means:

• Time-bounded — backups have a retention window and expire.
• Purpose-limited — recovery and safety, not analytics or profiling.
• Access-controlled — restricted administrative access.

In practice, deletion requests remove your data from live storage first, and then expire out of backups as the backup window rolls forward.

Export, delete, archive, restore

We treat export and delete as real user controls, not symbolic “contact us and hope” gestures. The system supports:

• Export — provide a JSON bundle for a UID (and linked account identifiers, if any).
• Off-boarding archive — archive a user’s detail to JSON and remove it from hot storage.
• Restore — restore from the archived JSON if you return and explicitly request restoration.
• Delete — remove personal data from live systems, while preserving non-identifying aggregates needed for continuity.

This design supports two truths at once: individuals should be able to leave cleanly, and communities can still keep honest totals without keeping a personal biography forever.

Aggregates and what remains after deletion

When people ask, “If I delete my data, does everything disappear?” the honest answer is nuanced. A relay has communal history — and not all history is personal data.

Our goal is to delete what is about you in an identifying way (your UID-linked records, your profile fields, your exports), while preserving non-identifying aggregates that represent the community’s continuity as a whole.

Think of it like this: if a stadium scoreboard says “Team total: 10,000 minutes,” it isn’t a biography of any one runner. It’s an aggregate signal that the relay remained alive.

How to request export or deletion

If you want a JSON export or deletion/off-boarding archive, the process should be simple:

• Identify your account — provide your UID (if you have it) or the email used for authenticated login.
• Choose the action — export, archive, delete, or archive + delete.
• Verify — we may ask for reasonable verification so we don’t hand data to the wrong person.
• Complete — export is delivered as JSON; deletion removes personal data from live storage and expires from backups over time.

The privacy overview is here: Privacy & GDPR. If you want to support the project without ads, see: Support.

What we will not do

Some lines protect trust. Retention rules aren’t just technical — they define what kind of place this is. So we make these commitments explicit:

• No surveillance advertising and no selling attention.
• No indefinite raw logging “just in case” it becomes useful later.
• No quiet expansion of retention without updating the public contract.
• No data-as-a-weapon culture — the point is encouragement, not leverage.

If you ever see drift — if something starts to feel like an attention trap — treat it as a bug and tell us.

Change log and transparency

Trust grows when behaviour is stable and readable over time. If we change retention rules, we will update this page with a date and a short summary of what changed and why.

Tip: The reliability side of transparency lives here: System Integrity & Uptime.

FAQ

Do you keep everything forever?

No. Ethical retention means time-bounded detail and longer-term aggregates where appropriate. If you want to leave cleanly, you can request archive + delete.

If I delete my data, will the community totals change?

We aim to delete personal, identifying records while preserving non-identifying aggregates that represent the relay’s continuity.

Can I get a copy of my data?

Yes. Exports are delivered in JSON so they remain usable and transparent.

Is this connected to ads?

No. We don’t use ads or ad trackers. See Why we don’t use ads.