All documents
Español

Privacy Policy

Version 1.9

Heartvault — Privacy Policy

Version: 1.9 Effective date: 2026-08-04 Contact: [email protected]

A note on tone: Heartvault is run by one person (Shagy) for ~200 people maximum. It is not a corporation, has no business model, and is not VC-funded. We've written this in plain language because that's what we'd want to read. Specifics are accurate; jargon is kept where it has to be.

What's live vs. what's planned

In the spirit of saying only what's true: most of the protections described below are built and live; a few are planned but not built yet. We label the not-yet-live ones inline as "Planned" so you're never told a feature protects you before it actually does.

If you're reading a published copy, anything marked "Planned" was not live as of the version date at the top. Ask us (section 12) for the current status anytime.

1. Who we are

Heartvault is operated by Shagy, an individual person, in the United States. The service runs at heartvault.net. Email is handled at heartbeatcreations.com; yellowduck.uk is a legacy name. There is no corporation behind Heartvault. It is — and is meant to stay — a small invite-only network for a family and a tight circle of close friends.

If you need to reach us about anything in this policy, see section 12.

2. What we collect

2.1 From you, when you sign up and use Heartvault

2.2 Automatically, as you use the site

2.3 From the Heartvault Android companion app (optional)

If you install the Heartvault Android app and pair it with your account, the app may send:

Live tracking and geofencing are device-side controls — you choose whether each is on, and you can turn each off independently at any time.

2.4 Via third parties on your behalf

2.5 What we deliberately do NOT collect

3. Why we collect it

We use the legitimate-interest basis (GDPR Article 6(1)(f)) for the minimal data necessary to provide the service you've signed up for. For optional features (location, the companion app), we rely on your consent (GDPR Article 6(1)(a)), which you can withdraw at any time.

4. Who can see what (visibility within Heartvault)

Heartvault operates on a three-tier circle. More trust means more access — not the other way around.

TierWhoDefault access
HouseholdThe immediate people under one roofLive presence, household map, shared grocery / chores / calendar, chore-allowance system
Family / friendsWider invited circle, after a friend request is acceptedJourney visibility (friends-only by default), profile, tagged check-ins
BlockedUsers you have blacklistedLess or nothing

Defaults are private. You opt in to wider visibility, not the other way around. Specifically:

If you change a visibility setting, future entries pick up the new default. Already-shared content does not retroactively change visibility unless you delete or re-tag it.

5. Who else gets access (third parties and the operator)

5.1 The superadmin

Heartvault has a "superadmin" role for site administration. Today, Shagy is the only superadmin. The superadmin can technically read most data on the server — this is true of any self-hosted application's operator, and we disclose it because saying otherwise would be misleading.

In practice:

5.2 Service providers in the loop

5.3 What we do NOT do

5.4 Push notifications (only if you opt in)

Push notifications are off by default. If you turn them on, you'll get a brief alert that names who messaged you — for example, "New message from [name]" — when a new direct message arrives. The alert names the sender, but never contains the message text or a preview.

How it works — a live connection to Heartvault's own server, nothing more. While you have Heartvault open, your browser holds an open connection to Heartvault's server (a standard web technique called Server-Sent Events), and the server sends the alert down that connection. There is no separate push program and no third-party push company — no Google Firebase, no Apple Push, and no self-hosted push daemon. As with all of Heartvault's traffic, the signal travels over Cloudflare (§5.2), which carries only the sender's name and the generic alert — never your message content. Because delivery rides your live connection, no device push-token is stored with any third-party service. You can turn notifications off at any time. (If we ever add an option to show message content or a preview in notifications — or ever route notifications through an outside push provider — we will update this policy and ask before enabling it.)

5.5 When other members are minors

Accounts that indicate a minor (under 18) will be labeled in the interface so other members know they are messaging a young person (this in-interface label is Planned — see the status box at the top; until it ships, treat it as forthcoming). Heartvault does not monitor the content of personal messages; we rely on members to behave appropriately. If we become aware of apparent child sexual abuse material, federal law (18 U.S.C. §2258A) requires us to report it to the National Center for Missing & Exploited Children (NCMEC).

5.6 What we do with your message content

Heartvault encrypts message bodies (and any attached location) at rest on the server using strong, industry-standard encryption (AES-256-GCM) under a key bound to the server's operating environment. This is not end-to-end encryption. The household server is a trusted server: it holds the keys to your messages, decrypts them in memory when it needs to (see below), and re-encrypts them when it stores them again. We tell you this directly because end-to-end has a specific, stronger meaning — and Heartvault does not meet that bar today.

The server reads message content for two purposes only:

No routine human access. The operator's administrative view of Heartvault does not show message contents during normal operation; it shows only metadata (who messaged whom, when). The only path by which a human can read your messages is a moderation-access endpoint restricted to the superadmin, requiring a stated reason, and every access is recorded — actor, target, conversation, reason, client IP, timestamp — in an append-only audit log that is never deleted. The endpoint refuses to serve content if the audit row cannot be written, so no human read can happen without leaving a permanent record.

Standing principle: we don't routinely read your messages; a logged moderation-access path exists for safety, and every access is recorded. The direction we are moving in long-term is end-to-end encryption — where translation happens on the recipient's device and the server can't read content at all — but that's a future change. Until it ships, the above is the honest picture.

6. Security

Heartvault takes reasonable, industry-standard security measures to protect your data — in transit, at rest, and at access time. We don't publish the specifics of our defenses, both because that practice is more useful to attackers than to users, and because the truer measure of a security posture is responsible handling of issues when they arise.

Material security incidents: if Heartvault experiences a security incident that materially affects your data, we will notify affected users within a reasonable period (consistent with applicable breach-notification law) and describe what happened, what was affected, and what to do.

Direction: end-to-end encryption for personal message content is on the development roadmap. Until it ships, message content is protected by the measures above but is readable to the operator if abuse-handling requires.

If you have a specific security concern (e.g., evaluating Heartvault for a child's account, or comparing against another service), contact us — see section 12.

7. How long we keep your data — the vault

Heartvault is a family vault: things you put in on purpose stay until a person deletes them. Things the machine produced along the way age out automatically. Concretely:

When you delete something, deletion is immediate. Heartvault hard-deletes it right away — there is no recoverable "soft-delete" copy kept in active systems, and no grace window. After deletion, the only remaining copies are in disaster-recovery backups, which rotate out within about 30 days. (An earlier draft planned a 14-day soft-delete recovery window; that plan is withdrawn — it was never built, and it is not currently planned. Deletion is immediate and final.)

Total maximum retention after deletion: about 30 days (backup rotation only).

Expedited erasure on request: because deletion is already immediate, the main thing left to accelerate is backup purging — if you require faster removal (for example, under GDPR Article 17 "right to erasure" or a comparable state law), contact us (section 12) and we will accelerate backup-purge timelines as far as backup mechanics allow.

8. Your choices and rights

You can, at any time:

How these rights are fulfilled — honestly. The self-service controls just above (edit, delete your own content, visibility, disable location) are live now. The formal data-subject rights — account deletion, data export, correction, restriction, right-to-know — are fulfilled manually: you contact the operator (section 12) and Shagy handles it by hand, promptly. For a network this small that is a valid method, and it is the honest current state: there is no in-product self-service account-deletion or data-export tool today.

Planned (no committed date): two self-service tools — a one-action account deletion (which will also remove your messages from shared conversations — by design) and a data export (a machine-readable JSON bundle). Until they ship, every formal right below is exercised by contacting us, and we will not describe these tools as existing.

8.1 If you are an EU, UK, or Swiss resident (GDPR / UK GDPR)

You have additional rights:

Contact us (section 12) to exercise any of these. We will respond within 30 days.

8.2 If you are a California resident (CCPA / CPRA)

You have the rights to:

Contact us (section 12) to exercise any of these.

8.3 Other US state laws

Residents of states with similar comprehensive privacy laws (Colorado, Virginia, Connecticut, Utah, etc.) have substantially similar rights. We honor those rights via the same contact path.

9. Children's privacy

Heartvault may include children under 13 as part of a household in the future. Right now, under-13 sign-ups are declined: if the date of birth given at signup indicates an age under 13, the account is not created and no data about that person is stored. The parental-consent approach described below is built but currently switched off — it stays off, pending legal counsel, until Heartvault is ready to enroll children. When it is turned on, the following approach applies, to comply with the US Children's Online Privacy Protection Act (COPPA):

If you are a parent and want to review the data we hold about your child, change consent, or delete the child's account, contact us (section 12).

10. International users

Heartvault is operated from the United States. Everything you put into Heartvault — your messages, photos, location, profile — is stored and processed on a server located in the United States. Cloudflare, the service provider through which your traffic flows, processes data in the United States and the European Economic Area and participates in the EU-US Data Privacy Framework and its UK and Swiss extensions (see https://www.cloudflare.com/privacypolicy/).

If you live outside the United States, using Heartvault means your personal data leaves your country and travels to the United States, where it is protected by the safeguards described in this policy (encryption, no sale, no ads, no data brokers, logged access) — but where the laws that protect it are United States laws, which may differ from your country's.

We ask for this consent explicitly, not silently — and we record it. When you create your account, the onboarding agreements include a separate, recorded acceptance of this international transfer — shown in your language and logged alongside your other agreements (the record captures the document version, the exact text you saw, your chosen language, and the time you accepted). Some countries — for example El Salvador, under Decreto 144 — legally require an express, individualized transfer consent, and this recorded acceptance is how we meet that bar. You can withdraw at any time by requesting deletion of your account (§8). The canonical consent texts below are the exact wording that step uses.

Cláusula de consentimiento (es): "Heartvault opera desde los Estados Unidos. Tus datos personales — mensajes, fotos, ubicación y perfil — se almacenan y procesan en un servidor ubicado en los Estados Unidos. Si vives fuera de los Estados Unidos, al usar Heartvault tus datos se transfieren a los Estados Unidos, donde se protegen con las salvaguardas descritas en nuestra Política de Privacidad (cifrado, sin venta de datos, sin publicidad, sin intermediarios de datos, acceso registrado), bajo las leyes de los Estados Unidos. Acepto de forma expresa esta transferencia internacional de mis datos personales. Puedes retirar tu consentimiento eliminando tu cuenta en cualquier momento."

Consent clause (en): "Heartvault operates from the United States. Your personal data — messages, photos, location, and profile — is stored and processed on a server located in the United States. If you live outside the United States, using Heartvault transfers your data to the United States, protected by the safeguards in our Privacy Policy, under United States law. I expressly accept this international transfer of my personal data. You can withdraw consent by requesting deletion of your account at any time."

11. Changes to this policy

If we change this policy in a material way, we will post the updated version and highlight what changed.

Your original acceptance of this policy is recorded at sign-up (§10). Planned (not built yet): an in-app step that shows you a material change on your next login and asks you to acknowledge it before continuing, recorded the same way. Until that ships, we notify you of material changes by posting the updated version with changes highlighted, rather than by a forced next-login acknowledgment.

Minor wording fixes (typos, clarifications) will be applied without an explicit acknowledgment step but will appear in the version history below.

Version history:

12. Contact

For privacy questions, deletion requests, parental review requests, complaints, or anything in between:

Responses come from the operator (Shagy) personally.