Years ago, I began worrying about my Instagram account. It contained part of our family history: photographs, places, captions, dates, and conversations around them. Losing access would mean losing a way of reading that history, whether the account was compromised or the platform suspended it.
I eventually downloaded an export. That gave me a copy of the data, but it also made me think about everything outside Instagram. Other parts of our life were in email, cloud drives, location services, fitness apps, and personal notes. Each service held a different part of the record.
I want a great-grandchild to be able to learn where we lived, what occupied our attention, and how we understood events in our lives. Some of that information already exists. Some will disappear unless we choose to record it. Some should remain private.
That concern was one of the precursors to FamilyBoon, or Boon for short. The archive is its foundation: a family-owned record connecting documents, photographs, correspondence, places, health records, and personal notes. Keeping copies is the beginning. I also want to understand them together, including the explanations people choose to leave about what they did and why.
In my earlier article, I described the document-based Boon I use for ongoing family work. It keeps original files and Markdown records, with a local search index; I have also tested restoring an encrypted backup. The broader imports, personal accounts, access controls, and succession arrangements in this essay are the product direction I am developing around that working foundation.
Family history starts while we are using it
A family archive can be useful long before anyone inherits it.
Consider a family move as an illustrative example. While it is happening, the family needs agreements, correspondence, dates, and a way to keep track of what remains to be done. Photos record the journey. Messages explain the preparations. A diary entry may describe why the move mattered or how someone felt about it.
Years later, the questions change. Where were we living then? What happened before we left? Why did we choose that place? The same material can help answer them, provided its connections and the explanations behind it have survived.
I want that continuity in Boon. A finished matter stays connected to the people, places, documents, and decisions involved. A future reader can look at the period from a different angle without reconstructing everything from disconnected exports.
An event provides one way to connect material. A person, a place, or an ongoing matter provides another. One photograph can appear in several of those views without several copies of the original. A timeline helps with dates; it is less useful when the question follows a person or a long-running matter across several years.
The family keeps the record. FamilyBoon helps bring material into it, find relevant context, work with it, and save what comes out of that work.
Daily use gives the family a reason to keep the archive current. I am building on material that already helps with life, so keeping it has a purpose now as well as years later.
What people add to the record
It is tempting to imagine that enough data will eventually explain a life. A location trace can show where someone went. A transaction can show what they paid. Neither explains what they were hoping for that day.
Abigail Sellen and Steve Whittaker examined this problem in Beyond Total Capture. Their 2010 critique of lifelogging separates finding information, recalling an experience, reminiscing with others, reflecting on the past, and remembering something we intend to do. Capturing data and supporting those activities are different design problems. A photograph can prompt a memory without containing the experience itself.
Finding an insurance document, remembering a trip, and understanding why a parent made a decision need different interactions, even when they draw on overlapping records. Better search helps with the first. The other two may depend on a conversation that has never been recorded.
Human accounts therefore belong in the archive alongside the material imported from services. A short voice recording about a photograph can explain something its metadata never will. A note written years later can add a different understanding of the same event. Keeping the author and the date allows a future reader to distinguish what someone said at the time from how they remembered it afterwards.
One event, several ways to understand it.
In a study of 66 adolescents aged 14 to 16, Robyn Fivush, Marshall Duke, and Jennifer Bohanek found associations between knowledge of family history and measures of self-worth and identity. It was a correlational study with a small, mainly middle-class sample, so it cannot establish that an archive would improve a child's well-being. For Boon, it supports making room for family stories alongside dates and other metadata.
I want the archive to leave space for an ordinary voice note, an unfinished thought, or two people remembering the same day differently. The application can make these easy to add and connect to their context. It should also let people ignore a suggested question without creating another task they feel guilty about.
Where existing systems meet this idea
The closest project I found is Timelinize. It brings photographs, messages, locations, and other data into a local archive for modern family history. It already connects entities across sources and offers timelines, maps, and conversations. Its files and SQLite database sit in a portable directory. There is a lot of overlap with what I have described, and a practical reason to investigate its approach before writing another set of importers.
Gramps provides a detailed model for people, families, events, places, sources, and citations. Remento helps people record spoken memories and keeps the recordings alongside written stories. Ente documents client-side encryption and recovery access through a trusted contact. These projects approach genealogy, storytelling, and private preservation with different priorities; all provide useful references for parts of Boon.
My starting point is the context a family needs to keep using as life continues. A new document arrives, someone works with it, a decision is made, and the result joins the record. That context can later support a quite different question about the family's past.
That is the direction I am bringing to FamilyBoon. These references come from the projects' published documentation; they give me approaches to investigate and possible work to reuse.
The family keeps the archive
I consider the archive the family's private property. FamilyBoon is the software I am building around it. A family must be able to stop using FamilyBoon and keep the record, including the context it has spent years adding.
The product boundary follows from that ownership. The service supplying FamilyBoon must have no access to archive contents: the locally running application works with the family's files, and content must stay out of the supplier's servers and diagnostics. If the family chooses cloud AI, selected material goes to that provider and leaves the device. The application has to show what is being sent and keep it within the user's permissions. A local model avoids that transfer, at the cost of different hardware and maintenance requirements.
Software comes in. Only selected data goes out.
What has to survive the app
Keeping a folder of files is only part of the job. A future reader also needs to know who supplied an account, which document a conclusion came from, and how the records relate. A backup preserves what was stored; it cannot explain a relationship that only the original application knows how to read.
For the wider archive, I require a way out that preserves both the material and that context:
- Original records and people's accounts must be readable with ordinary tools. A photograph stays a photograph; a note can be opened as text without a running model or a FamilyBoon account.
- Identifiers, links, authorship, dates, and corrections need documented, versioned representations. Changing a folder path must not silently break the relationship between an account and its sources. Changes to those formats need explicit migrations.
- Moving the archive must preserve ongoing matters, their history, and their next steps, along with each person's sharing and succession instructions. Software that reads the archive has to honour those instructions; copying the files does not itself enforce access rights.
- Search indexes and other disposable views must be rebuildable from the retained record. A human correction or an accepted explanation belongs in that record with its sources, even if it first appeared in a generated view.
Timelinize keeps imported files on disk and indexes them in SQLite. The current Boon also uses SQLite for search, while originals and Markdown hold the retained document record. SQLite is useful for querying connections; plain text is convenient for inspection and editing with other tools. The choice depends on which parts can be rebuilt and which contain information someone has added. A database holding irreplaceable relationships needs a documented way to preserve them too.
Readable formats still need care. Stable links, schema changes, migrations, and importers become work I have to maintain. Other tools may read the files without reproducing FamilyBoon's interface. I accept that cost because the family must be able to continue using its record after changing software. Removing FamilyBoon should cost it a convenient interface, while leaving the sources and saved context available.
AI must leave the record checkable
AI can help read a mixed archive, propose connections, find relevant material, and turn it into a useful answer. It can also produce a very convincing explanation for something the sources never establish.
I want three kinds of material to remain distinguishable: original records, accounts supplied by people, and interpretations produced while examining them. A photograph preserves an image. A voice note preserves someone's account. A model's proposed connection between that photograph and a journey remains a proposal, with its supporting evidence, until checked.
Human accounts can be mistaken too. Two people may disagree; someone may revise a recollection. The archive can preserve who said what and when, without turning either account into a settled explanation of the event. A generated family history needs a route back to those sources, including their disagreements.
There is also a risk in how the system asks people about the past. In a 2024 preprint by Chan and colleagues, 200 participants took part in a video-memory experiment with deliberately misleading interviews. The generative-chatbot group gave more false answers on five critical questions than a no-interview control: averages of 1.82 and 0.54 immediately afterwards. That experimental setup gives me a concrete reason to avoid prompts that smuggle a detail into someone's recollection.
If a photograph has no identified people, asking who is in it leaves the answer open. Asking what the person's father said that afternoon invents both a participant and a conversation. The answer then risks carrying the model's assumption into the family's record.
A family has more than one audience
A family archive needs personal spaces as well as shared ones. A shared photograph, a private diary, and a medical record have different audiences. Relationships change, children grow up, and people have their own wishes about what to preserve or pass on.
William Odom and colleagues explored digital inheritance in Technology Heirlooms?, a 2012 qualitative study involving eight families and design probes. Some participants resisted automatic inheritance of social media material: something shared with one audience was not necessarily something they wanted to leave to their family. The study also examined the work of caring for digital materials and the different ways people present themselves.
For Boon, that means a family relationship cannot stand in for permission. Each person needs control over selected records and the conditions under which they can be shared. Those choices need to travel with the archive, including instructions for a future custodian.
Permissions must govern retrieval too. Hiding a diary in the interface achieves little if a family search can still use it to answer questions. Titles, relationships, and generated summaries can reveal information from private sources. A model's answer must respect the access boundaries of the material it draws on.
One possibility further out is a conversational representation of a person after their death. A rich archive may provide material for it, but I have not settled what such an avatar should be allowed to say or how a family should use it. Playing someone's actual words and generating a new statement in their voice have different meanings. Permission to preserve records must not silently become permission to speak on someone's behalf.
Designing beyond the current owner
An archive meant to pass through generations has to survive changes in the people looking after it. The next custodian may have different interests, less technical knowledge, and no memory of the events it describes.
Batya Friedman and Lisa Nathan call the longer design horizon multi-lifespan information system design. Their 2010 research agenda addresses problems that continue beyond one human lifetime. I am applying its combination of lasting commitments and adaptable processes to the family archive: keep family control while allowing the ways of storing, reading, and maintaining the record to change.
The application, importers, storage devices, and models will change. The next custodian needs enough context to understand the record without inheriting every detail of its creator's setup. Documented formats, recovery arrangements, and instructions for who receives which material belong in the product's foundations.
Permanent makes one useful distinction: a legacy contact reports the owner's death, while an archive steward takes responsibility for the archive. Knowing whom to notify and knowing who will care for the record are separate parts of succession.
Devices fail, credentials get lost, and the next custodian may need help with both. Recovery instructions and regular maintenance belong alongside the archive. Boon has to make that care manageable for someone who did not build the system.
Growing from the current Boon
The current document workflows give me a place to start. From there, I am working towards imports that preserve dates, authors, and relationships, alongside a straightforward way for people to add their own explanations. Each new kind of material also has to fit the access and portability requirements.
That brings me back to the Instagram export. I have a copy. I want photographs, captions, and conversations from Instagram to become usable alongside the rest of the family record, with their origins still clear. Someone should be able to find a photograph through the person, place, or episode it belongs to, read the accounts shared with them, and keep that context when they choose another tool.