Tootsie Tales is a private, encrypted family app. It turns a child's photos, videos, audio and letters into a timeline organized by the child's real age, shared only with the family the parents invite. It runs as native apps on iPhone and Android, and it is designed around a single, non-negotiable idea: a child's story belongs to their family, and to no one else. This paper explains both why we built it this way and how the architecture actually delivers on that promise.
Tootsie Tales is currently pre-launch and available through a waitlist. This document describes the product as it is built today, including its honest limitations. It is published by Francis Gregori Munis Soluções Web e Mobile (Empresário Individual), CNPJ 35.654.676/0001-83, Brazil.
1. Why a child's story deserves a private home
For most of a generation, the default place to keep a child's earliest years has been public social media. It is convenient, and it is free, but the trade is steep. The moments you post become training data, ad-targeting signals and permanent records held by companies whose business is attention, not memory. A child who never consented ends up with a public profile before they can spell their own name.
The alternative most families fall back on is scattered chaos: photos spread across camera rolls, cloud backups and group chats, with no shared home and no clear owner. The memories survive, but they are fragmented and quietly exposed to whichever platform happens to hold them.
Tootsie Tales exists to offer a third option: a calm, private, family-only space where a child's story is gathered in one place, organized by the age they were when each moment happened, and readable only by the people who love them. The rest of this paper is about the engineering that makes that promise real rather than merely stated.
2. Design principles
Every decision in Tootsie Tales traces back to a small set of principles.
- Privacy by design. Content is encrypted on the device before it ever leaves it. Privacy is the default state of the system, not a setting you have to find and switch on.
- Family-only by construction. Access follows the family, not the network. People outside a child's circle cannot browse, discover or even confirm that the child exists.
- Data minimization. The server keeps only the metadata it genuinely needs to enforce access and organize the timeline. Everything sensitive stays encrypted and unreadable to us.
- Ownership. The keys belong to the family. We hold ciphertext and authorization records, not the ability to read your memories.
- Longevity. A child's story is meant to last decades. The design favors durability and portability of the underlying data over lock-in.
3. How Tootsie Tales is built
The system has three parts: the mobile app, a backend API, and object storage for media.
- Mobile app. Built with Expo and React Native, shipping as native apps for iOS and Android. This is where all encryption and decryption happen, because it is the only place your keys ever exist in usable form.
- Backend API. A stateless Go REST API hosted on Railway with a PostgreSQL database. It stores authorization metadata and opaque ciphertext, and it enforces who is allowed to do what. It never holds a decryption key.
- Media storage. Encrypted media lives in Cloudflare R2, an S3-compatible object store.
The direct-to-storage media path
One architectural choice matters enough to call out on its own: media bytes never pass through our API server. When your device needs to upload an encrypted photo or video, the API issues a short-lived presigned URL, and the device transfers the encrypted bytes straight to Cloudflare R2. Downloads work the same way in reverse. The API brokers permission; it never touches the content itself.
Authentication is handled by Firebase Authentication, supporting email and password sign-in plus Google and Apple sign-in. The backend simply verifies the Firebase identity token on each request and remains stateless, with no server-side sessions to manage or leak.
4. The private vault: end-to-end encryption explained
This is the heart of Tootsie Tales. We call it a blind vault, and it rests on one guiding invariant: the server never receives a decryption key or readable content. It stores authorization metadata and opaque ciphertext, and nothing more.
Encryption on the device, before upload
All sensitive content is encrypted on your device with AES-256-GCM before anything is uploaded. Large media is not encrypted as one giant blob; it is packaged in a chunked container format using 1 MiB chunks. Each chunk carries its own nonce and its own authenticated additional data that binds the file header, the chunk's index and an end-of-file marker. In practice the format actively resists tampering, reordering of chunks and silent truncation: an attacker cannot cut a video short, shuffle its pieces or splice in foreign data without the decryption failing.
Envelope encryption and the Group Key
Tootsie Tales uses envelope encryption. Every media object gets its own random 256-bit Content Encryption Key (CEK) that encrypts the actual bytes. That CEK is then wrapped (itself encrypted) by the child's 256-bit Group Key, or, for entries marked private, by the user's personal key.
The unit of sharing and of encryption is the child: one child equals one private group with one Group Key. That Group Key is generated on the owner's device at the moment the child is created, and it is never stored on our server in any usable form. Because the CEKs are wrapped by keys we never hold, the ciphertext we store is opaque to us by construction.
What is end-to-end encrypted
The following are encrypted on the device and can never be read by our servers:
- All media bytes, including the original, the thumbnail and the blurred preview.
- Entry captions and entry locations.
- Comment text.
- Letter titles and letter bodies.
- The encrypted key-backup bundle used for recovery.
What is stored as plaintext metadata
To enforce access and organize a timeline, some metadata has to be readable by the service. We want to be transparent about exactly what that is:
- The child's name, birthday and gender.
- Membership roles and family relationships.
- Each entry's kind, audience and dates.
- Tag names, album titles and letter delivery dates.
- Media technical metadata: kind, size, content type, and an on-device moderation attestation.
- Growth records as a metric, value and unit.
- Account data: email, display name, photo and subscription state.
This metadata is genuinely readable by the service, and we do not pretend otherwise. It is the minimum needed to run the app: to know who may see what, to place moments on the correct age-based timeline, and to deliver letters on their intended date. The content those records point to stays encrypted.
5. Family, roles and invitations
A child in Tootsie Tales is a small, private group. There are three roles, shown in the app in plain language:
- Admin (owner). Manages the child, the members and the invites. Owners can post.
- Family member (member). Can view and can post.
- Fan (viewer). Can view only.
Access is enforced centrally on the server, and it is strict at the edges. To someone who is not a member, a given child does not appear to exist at all: the server returns a plain "not found", rather than a "you lack permission" that would confirm the child is there. Non-members cannot even learn that a child is in the system.
How keys reach family without the server seeing them
Sharing a child means distributing the Group Key, and the challenge is doing that without our server ever seeing it. There are two paths:
- Invite link. The Group Key rides in the URL fragment, the part after the "#". Browsers never send the fragment to servers, so the key reaches the recipient's device without touching ours.
- Keyless email invite. The Group Key is encrypted specifically to the recipient's public key (X25519) and relayed as an opaque bundle. We pass the bundle along, but we cannot open it, because only the recipient holds the matching private key.
6. The timeline and data model
Tootsie Tales is entry-centric. The spine of the app is a timeline of entries (moments and diary notes), each of which can carry media (photo, video or audio), a caption, an optional location, tags, likes and comments. Around that spine sit a few richer object types:
- Milestones, marking the firsts and the moments worth remembering.
- Letters, which are time capsules with a future delivery date, so a parent can write something today that is delivered years from now.
- Growth records, which capture height and weight over time.
What makes the timeline feel different is that it is organized by the child's real age rather than by an anonymous upload date. A moment is not just "March 2026"; it is "the week she turned eleven months old". The story reads the way a family actually remembers it.
7. What we can and cannot see
The clearest way to describe a privacy system is to state plainly what the operator can and cannot see.
We can see the plaintext metadata described in section 4: the child's name, birthday and gender; roles and relationships; entry kinds, audiences and dates; tag names, album titles and letter delivery dates; media technical metadata; growth metrics; and account data. We need these to run the service.
We cannot see any media, any caption, any location, any comment, any letter, or any key. These are end-to-end encrypted. Even in the worst case, a breach of our database or of the object storage, those fields yield only ciphertext. There is no decryption key on our side to steal, because the keys live only on family devices.
8. Recovery and the honest trade-off
End-to-end encryption creates a real question: if we cannot read your keys, how do you get back in on a new phone? The answer is a 10-word recovery phrase. It carries about 110 bits of entropy and is drawn from the standard BIP-39 word list. To be clear, this is not a blockchain seed; it is simply a well-tested way to represent a strong secret in words a person can write down.
That phrase is stretched with Argon2id, a memory-hard function configured to use 64 MiB of memory, into a key that encrypts a backup bundle of your keys. The bundle is stored on our server only as opaque ciphertext. On iPhone, the unlocking secret can also sync privately through iCloud Keychain, so restoring on a new Apple device can be seamless. On Android, the recovery phrase is currently the way to restore on a new device.
Keys live in the device's secure keystore and are device-bound. They are not synced to our cloud, with the single exception of the optional iOS recovery secret via iCloud Keychain.
The honest trade-off: because only your family holds the keys, if you lose your recovery phrase and have no other signed-in device, your encrypted content cannot be recovered by anyone, including Tootsie Tales. There is no back door, and a back door for us would be a back door for an attacker too. This is the real cost of true privacy. Please store your recovery phrase somewhere safe.
9. Safety, moderation and durability
Encryption is the foundation, but it is not the whole of safety. Several protections work alongside it:
- TLS in transit for every connection between the app and the backend.
- Centralized server-side authorization, so access rules are enforced in one place rather than trusted to the client.
- On-device content moderation that runs before encryption and upload. Because the server only ever sees ciphertext, it cannot scan content; instead the check happens on the device and the server records only an attestation that it ran.
- Screenshot protection within the app.
- Per-IP rate limiting to blunt abuse and automated attacks.
- Strict handling of secrets throughout the system.
For durability, content is kept in managed cloud storage. Any backups the storage provider keeps contain only ciphertext for the encrypted fields, so resilience never comes at the expense of the privacy guarantee.
10. Current limitations and what is ahead
Because this is a real, pre-launch document, we would rather name our limitations than hide them.
- Data retention. There is currently no fixed retention schedule. Content is kept until you delete it.
- Data export. There is no one-click export feature yet. Portability requests are handled manually for now.
- Android recovery. Cross-device recovery on Android currently depends on the recovery phrase, without the iCloud Keychain convenience that iOS offers.
These are honest gaps, and they sit on the roadmap. None of them changes the core guarantee: your content stays encrypted and unreadable to us.
11. In summary
Tootsie Tales is a small idea carried out carefully. A child's story is gathered into one private place, organized by the age they actually were, and shared only with invited family. The media, captions, locations, comments and letters are encrypted on the device with AES-256-GCM, wrapped by a Group Key we never hold, and stored as ciphertext we cannot read. We keep the minimum metadata needed to run the service, and we say plainly what that is. The family holds the keys, which is the source of both the privacy and the responsibility that comes with a recovery phrase. That is the whole promise: a lasting, private home for the people who matter most.