Privacy, memory control, and offline resilience — backer inquiry
| Date | Monday, May 18, 2026 |
| Source | Email — Indiegogo pre-launch inquiry |
| Sender | Prospective backer (anon) |
| Status | drafted (awaiting founder review before reply) |
| Topic | Privacy · Sovereignty · Offline |
| Channels used | (none yet — email reply pending) |
Questions
How is A Friend’s memory handled in terms of privacy and control — is the data stored locally, in the cloud, and can users fully view or delete what it remembers?
If the device loses internet access, or over time services change, what core functions will still work reliably without relying on external servers?
Answer 1 — Memory, privacy, and control
A Friend is built privacy-first. That sentence is the easy one, so let me say what it concretely means rather than wave at it.
A Friend’s memory does live in the cloud — there is no local-only mode at this stage. We chose this honestly, because the experience we are designing (continuity across the device, the app, and the relationship layer) needs server-side coordination to feel coherent. We would rather say “cloud-required” out loud than ship something with hidden network dependencies.
What changes that into a privacy-first product, instead of just another cloud product, is who controls the data once it is there.
You own the memory A Friend builds about you:
- You can view it. Every memory A Friend retains will be visible to you in plain readable form, in the companion app.
- You can delete it. Individual memories, topics, time windows, or the whole memory store — selective and full deletion both supported. Account-deletion is full memory-deletion; no silent retention.
- You can export it. A portable export of your memory, in a format you can take with you, so you are not locked into our infrastructure.
On where data routes: the default model stack is the privacy-safer combination. If you opt into premium-performance features like our best voice models — some of which are only available from US-based providers — the UX tells you which jurisdiction the data flowing through that model will pass through. You decide. We disclose.
We do not sell user data. We do not use it to train models for third parties. And the defaults always err on the side of less collection rather than more — performance-premium features are opt-in, not opt-out.
There is still UX work to do on the granular consent layer (how you opt into each routing decision without click-fatigue) and on the deletion-window SLA (how fast a delete actually propagates through caches and backups). Those are open questions we are working through honestly rather than hiding behind boilerplate.
Anchored in: V01 Privacy by default · V02 User data sovereignty · V05 Model-choice with data-locality.
Answer 2 — Offline resilience and service longevity
The honest scope first: A Friend is a cloud-paired experience. Conversation depth, memory updates, and personalization need our service to be reachable. If you are off the grid for a hike, the device will not pretend to have an opinion about your week.
That said, the device is not dead without internet. By design, a defined subset of behavior keeps working:
- The visor expressions — stored locally, the LED face can cycle through cached states.
- Touch and motion response — capacitive feedback and sleep/wake based on motion are local.
- Cached recent moments — audio output for recent memory, within a defined local storage budget.
- An explicit “offline mode” indicator — so the device tells you when it is operating in reduced-scope, rather than failing quietly.
For the longer-term concern — what happens if services change over time — the commitments are:
- No remote-bricking, ever. The device hardware is yours regardless of what happens to our cloud.
- A stated minimum operational period for cloud services post-ship. We will publish this number on the campaign page; the exact figure is being finalized and will not be vague.
- Open data-export, including before any service wind-down. You will always be able to take your memory out — whether for migration, archival, or just because.
- A documented graceful-degradation path for the day services ever sunset. The device falls back to the offline-scope above. It does not become a paperweight.
- Spare-part availability and repair documentation for a stated minimum period — the hardware is designed to be reparable where structurally feasible.
The specific numbers — minimum operational years, deletion-window SLA, local-storage budget for cached audio, spare-part guarantee window — are the next layer we are working through. We would rather state them once and stand by them than promise them now and walk them back.
Anchored in: V03 Cloud-required, transparently · V04 Offline resilience scope · V06 Hardware longevity · V07 Honest scoping.
Close
If any of the open numbers above are the dealbreaker for you, please ask and I will tell you what we are converging on — we would rather have the harder conversation now than have you back something on a softer version of the story.
Thank you for considering A Friend.
Original (verbatim — email body)
Thanks for confirming.
As someone considering backing the project, I just had a couple of quick questions that would help me understand it better from a user’s perspective:
How is A Friend’s memory handled in terms of privacy and control, is the data stored locally, in the cloud, and can users fully view or delete what it remembers?
If the device loses internet access or over time services change, what core functions will still work reliably without relying on external servers?
Looking forward to your insight.
— Email received 2026-05-18 via Indiegogo pre-launch inquiry channel.
Values anchored in this answer
- v01-privacy-by-default — Privacy is the default state, not a feature toggle. Less data collection, opt-in performance-premium.
- v02-user-data-sovereignty — View, delete, export memory at any time. Account-deletion is full memory-deletion.
- v03-cloud-required-transparently — Honest about cloud-required architecture, not buried in fine print.
- v04-offline-resilience-scope — Defined subset works without internet: visor, touch/motion, cached recent moments, explicit offline indicator.
- v05-model-choice-with-data-locality — User chooses which models, with per-feature data-locality disclosure.
- v06-hardware-longevity — No remote-bricking, spare-part availability, hardware outlives service-sunset.
- v07-honest-scoping — We will publish specific numbers (operational period, SLA, storage budget) and stand by them, not vague promises.
Cross-channel reuse
Where this answer can or has been used:
- Email reply — slight personalization on opening, body verbatim
- Campaign FAQ page — condensed version, both questions visible in TOC
- IG DM auto-reply seed — short-form 2-sentence-each version derived from this body
- Indiegogo public comment reply — if same question appears publicly
- Press / interview — answer #1 is full-position-shaped, reusable verbatim
- A Friend website FAQ — once live, becomes the canonical public-facing version
- Sub-Q seed — “what happens to my memory on account-deletion” deserves its own granular FAQ once the deletion-SLA number is set
Status log
- 2026-05-18 captured via email inquiry channel
- 2026-05-18 drafted answer via /afriend-distribution (goal-driven FAQ scaffold first entry)
- (awaiting) founder review and approval before email reply send
- (awaiting) open-questions in Values resolution → answer refresh if material changes