Common questions

Membership is not the same as having an account: signing up puts you in a queue, and the keeper of the archive has to let you in before a single photograph is drawn for you. Until then you see the waiting screen, and if they turn you down you see a closed door.

That check is asked again on every request rather than once at the sign-in page. Every page in the app resolves which archive you are in before it queries anything, and the route that serves the actual image files asks the same question before it hands over a single byte — a photograph's URL is not a key to it. Downloads go further and are keyed by id, so an id belonging to another archive is a “not found” rather than a file.

Two models run over every photograph as it arrives, both on this archive's own computer: the first finds the faces in it, the second turns each face into 512 numbers — an embedding — which land close together for two pictures of the same person and far apart for two different people. What that produces is a group of faces that resemble each other, with nothing written on it.

The full account, and a diagram of a face becoming numbers becoming a name somebody typed, is in Faces below.

Two of the ten run without anybody asking, both as a photograph arrives: one describes it, and one makes that description searchable. The other eight wait for a press or a typed search — a caption suggested, a scan enhanced, an occasion named, a search understood.

Every job, the company it goes to, what it keeps and how to switch it off is in What the AI does below.

Five companies, in one breath: Anthropic reads the photographs and most of the words, OpenAI turns those words into numbers so a search can match by meaning, Topaz Labs enhances a scan when somebody presses the button, Google matches a place name to a real address, and Mux is what plays a video at all.

The AI work runs under zero data retention — the picture or the words go, the answer comes back, and neither is kept. Enhancement, video and maps sit outside that: a photograph sent to be enhanced is held for seven days, a video's playing copy is kept for as long as the video is here, and the map companies keep what their own terms say. Which job sends what is in What the AI does below.

People. Any member can say something under a photograph and answer the questions on a person's page — several relatives can answer the same question, and you can edit or delete your own answer afterwards. Captions, dates, places, who is pictured, events, albums and pets are an archivist's to set.

The file itself. The camera or the scanner writes the date and time the picture was taken, the coordinates it was standing on, the make and model of the camera, and how many pixels across it is. A scan carries one thing more: the day the scanner's clock read, which is the evening somebody sat at the desk and not a claim about the photograph.

The face scan. Groups faces that resemble each other, and stops there. The names come from somebody working through Review → Faces.

The AI. A description and a handful of searchable words on every upload, and — only when asked for — suggested captions, a name for an occasion, and a paragraph about a public place.

Google. Turns an informal place name into a real address, and says what ground a photograph's coordinates were standing on. The nearest town to those coordinates is worked out here instead, from a list of the world's towns that ships with the app.

Each of those has one place it happens. Uploading is the Add photos button, and every delivery you have sent up is listed under Your uploads. Comments sit in the Info pane of an open photograph, under the picture. The questions — and the memories written under them — are on the Overview tab of a person's page.

That is narrower than it sounds, and here is what makes it enough: if you know something about a photograph you cannot change yourself — the year, the porch it was taken on, which cousin is on the left — say it in a comment or tell whoever keeps the archive. That is how it gets in, and it is how most of what is written here arrived. What each room is for is in The guide.

The files sit in private storage that nothing is served from directly — every image on every page has come through the app's own route, behind the membership check.

Share is honest about this rather than quietly making a hole in the gate: sharing a photograph either hands the file itself to your phone's share sheet — bytes you could already download — or copies a link, and the app tells you as it copies that the link opens for members of the archive. Public links are a feature somebody may eventually want, and they are deliberately not built.

A private corner would be a second class of access, and the whole design of the gate is that there is exactly one. So the rule is the blunt one: if something should not be seen by everyone the keeper of the archive has let in, it should not be put here.

Some of it, on purpose, and it is worth knowing which half. The activity feed under Admin records what people do to the contents — what was uploaded, edited, tagged, filed and deleted, and who did it. A shared archive needs an answer to “who moved that” which isn't asking around at Christmas.

What is kept out of it is everything that is only about you: your favorites, the marks you leave on photographs that need work, which people and places you have lately visited, and what you have said to the Curator. Comments are the obvious exception in the other direction — they are written to be read, and they sit under the photograph with your name on them.

The Curator is worth saying out loud, because a conversation feels like it evaporates and this one does not. Every message you send it, and every reply it gives, is written down and kept, so the panel can pick the thread back up on your next visit. They are filed against your name and nobody else's — there is no screen, for a member or an archivist or an owner or an admin, that shows somebody else's chat — and “Start over” hands you a clean sheet rather than burning what came before.

An owner keeps the roster: they see everyone who has asked to join along with their email addresses, and they are the ones who let somebody in or turn them down.

An admin gets the back room — the log of what the background jobs have done, the archive-wide activity feed, the buttons that run a job by hand, and the ledger of every AI run and what it cost. An admin is also the only one who can say how a photograph was made — a scan, an enhancement, something a model drew — because that is a claim about the photograph rather than a note filed beside it. Neither role is a wider view of the photographs themselves: every member already sees all of those, the answer to how one was made included.

Both are files that ship with the app and run on its own server. No embedding, no crop of a face, and no name is sent to an outside service at any point: the comparison is arithmetic done next to the database. The photograph itself does go out, faces and all, and the AI section below says exactly when. This is also the cheapest job in the whole app, which is why it runs on every photograph and never asks.

Photographs, and only photographs. Video used to be read the same way — a dozen stills pulled from each one and put through the same detector — and that was taken out, because a digitised tape gave back more half-resolved strangers than Review could be worth: the people in front of the camera, and a row of unresolvable ones behind them, every one of which arrived as another group to name or dismiss. A video is not scanned at all now, and voice recordings never were.

That distinction is the whole design. A name only ever comes from a person typing one on Review → Faces.

Once a group has been named, faces that arrive later and land in that group are tagged with that name automatically — that is what makes naming one group worth doing. But the archive has never learned a name on its own, and there is nothing in it that could tell you who a stranger is.

A group that is wrong takes not them? and the name comes off it; a group that is a statue, a reflection or somebody's shadow takes not a person and stops being offered. Naming two groups with the same name is how you tell it that a face fifteen years apart is one person, and the profile gathers them under the one name.

One person reliably owns several groups, and that is the tuning rather than a fault: the threshold is set one notch tighter than the last setting measured clean, because putting two groups together is a click and pulling a contaminated group apart is not.

Detection runs on every photograph as it is uploaded — not on video, per the answer above — and it is what makes anybody findable in an archive of thousands.

What you can do: untag yourself from a photograph, dismiss a group so it is never offered for naming again, and delete a photograph — which takes its faces and their embeddings with it in the same transaction, along with the file. If a per-person opt-out matters to you, it is a reasonable thing to ask the keeper of the archive for; it is recorded here as absent rather than as impossible.

It is stored beside the photograph it came from, it is never compared against anything outside this archive, and there is no service on the other end of it. The model itself is a public one — the numbers it produced about your family are not.

Photographs do leave this archive, faces and all, to be described by an outside company. Nothing that says who is in them ever does: no name, no fingerprint of a face, no link to any other photograph.

Nearly every one of those trips is made under a setting that keeps neither the picture nor the answer. The ones that are not are named below, and one of them keeps a copy for seven days.

Two jobs run on their own when a photograph arrives — one describes it, the other makes that description searchable. Everything else happens only when somebody presses a button or types a search. The face scan is separate from all of it: it runs on the archive's own server, on every upload, and sends nothing anywhere. Nothing any of these jobs writes ever replaces what a person typed.

The part that actually recognises a face. When a photograph arrives, this archive's own computer finds the faces in it and turns each one into a string of numbers — a kind of fingerprint, whose only useful property is that two of them taken from the same person land close together. Those numbers are what let the archive say “this is the same child as in these other forty photographs”.

That work runs here, on this archive's own machine, using files that ship with the app. No fingerprint of a face, no crop cut out around one, and no name is sent to any company, at any point, for any reason. The whole photograph is, and the next part says when. There is nothing held anywhere else that could be used to pick your child out of somebody else's photographs.

It also never decides who anybody is. It groups faces that resemble each other and stops; a name only ever arrives because a person typed one.

The photographs themselves — and a photograph of your children has your children's faces in it. There is no way around that sentence, so here is exactly when it happens.

Every photograph is sent once, as it is uploaded, to Anthropic, to be described so that it can be found by searching later. That one runs on its own, without anybody asking. What goes is the picture and nothing else: no names, no ages, no relationships, nothing the archive knows about who is in it.

Three more send a picture only when somebody deliberately does something. A search that asks about something only the picture can settle sends the few dozen it has already narrowed down. Pressing Enhance sends that one photograph to Topaz Labs. And pressing “Suggest a few” for a caption sends that one photograph to Anthropic — this is still the job that sends the most alongside a picture, and it is worth being plain about what that means: it sends who is tagged, how they are related, and whereabouts in the frame each tagged person is and how large their face is. But it never sends a real name — everybody tagged is swapped for a numbered stand-in first, so a caption suggestion is the one moment where a company is told “the child on the left is Person 2's daughter”, and the real name is filled back in here, before a suggestion is ever shown. Nothing else here sends that much alongside a picture, and nothing does it unless somebody presses the button.

Two things follow that are worth saying rather than leaving to be discovered. Nothing here treats a photograph of a child differently from any other. There is no separate rule, no age check, no exclusion — a family archive is mostly photographs of children, and the archive does not pretend to sort them.

And there is no way to exclude one person, or one photograph, from any of this. The switches are archive-wide and belong to whoever runs it. A per-person opt-out is a reasonable thing to want and a reasonable thing to ask the keeper of the archive for; it is recorded here as absent rather than as impossible.

AI analysis goes through the Vercel AI Gateway with zero data retention required on every model request. This applies to descriptions, captions, searches, conversations, and the numerical representations of text used for search, including analysis of older photographs. Requests go only to providers covered by the Gateway's zero-retention agreements, which also prohibit using those requests to train their models.

This limits what the provider keeps after processing; the photograph or words still have to be sent for the job to work. The archive keeps the resulting descriptions and other answers so you can use them here.

Pressing Enhance sends the photograph directly to Topaz Labs, which keeps it for seven days, outside that guarantee. Video hosting and maps are separate services: Mux keeps a copy of each video so it can play, and Google receives place names and map requests. Their retention is governed by their own terms. Zero retention for AI analysis does not mean that everything outside this archive keeps nothing.

What this archive does control is how little goes out in the first place, which is why the jobs are drawn as narrowly as they are: nothing is sent that could have been worked out here, enhancement never runs unasked, and the job that runs on its own sends the picture without a single name attached.

These are the reason a photograph uploaded with every job above switched off still arrives with its faces found and its thumbnails made.

Four things nothing here is able to do, and the reason each one holds.

Whoever runs the archive can switch these off, and they go off for everybody rather than photograph by photograph. There is also a separate switch for the one job that runs on its own, so that new photographs stop being described while everything else carries on.

A job that is off fails quietly and on purpose. With describing off, a photograph still uploads, still gets its faces, still gets its thumbnails, and still appears everywhere it should — it simply arrives without a description, and a search then finds only the words people typed themselves. With enhancing off, the button is gone. With the address lookup off, a place is filed under the name you gave it and nothing more.

Video is the one real loss, and it is worth being plain about. The company that plays video is not adding something to a video — it is what plays it at all. With it off, a video still uploads, still keeps its original file safe, and can still be downloaded, but it never plays inside the archive: it sits at “Processing…” instead.

A switch for one person rather than for the whole archive does not exist today. If that matters to you it is a reasonable thing to ask the keeper of the archive for; it is recorded here as absent rather than as impossible.

What is recorded is which job it was for, which company answered, and how much of it there was. The enhancement page under Admin says which photograph, who pressed the button, and what it cost. The rest is recorded where whoever runs the archive can read it, though not on a page in here.

Describing older photographs uses the same protected service and standard prices as describing a new upload. The archive gives up the cheaper batch option because it requires photographs to be kept. Guessing a date costs nothing at all, because that work happens here.

It will, sometimes — a description that misses the joke, a searchable word that is nearly right, a caption that reads like a stranger wrote it. Because everything it writes is an addition rather than a replacement, the fix is simply to edit it.

Dates are where this is taken most seriously, because a wrong one is contagious — everything sorted by time inherits it. Nothing any of these jobs writes ever touches a date.

Everywhere a date can be entered — the upload desk, the photograph's details panel, the bar that appears when you select several photographs — there is a second field beside the exact one for exactly this, and the two are exclusive: a photograph carries a real date or a phrase, never both. The phrase is kept as the words you gave it, and those words are what every screen shows — the archive never rounds “Summer 1975” into a date and prints that back at you.

Vaguer is fine too. “The seventies” is a real answer and better than nothing — a photograph with any phrase on it counts as dated, not undated, because somebody wrote something down.

A month and a year land on the first of that month; a year alone on January 1st; the seasons on a fixed day apiece — Spring on March 19th, Summer on June 20th, Fall or Autumn on September 21st, Winter on December 20th; and the named holidays on their own days — Christmas December 25th, Valentine's Day February 14th, and Easter, which really moves from year to year, pinned to April 5th. The stand-in day is a shelf position rather than a claim: the photograph still reads “Summer 1975” everywhere it appears, and the one place the day itself is shown is the “Sorted as” line under More details, where it is named as the stand-in it is.

The date filters read the same placement, so “Christmas 1985” turns up under a December filter and a 25th filter, and “Spring 1972” under March. The honest edge of that: a photograph dated just “1975” sits on January 1st, so it answers a January filter too. And a phrase with no year in it at all — “the seventies” — gets no shelf position: it sorts by when it arrived, and is reachable with the date filter off.

Everything else — the thumbnails on the grid, the JPEG made so a browser can render a HEIC, the M4A made so a browser can play an old voicemail, the enhanced copy — is a copy for showing, and none of them is ever offered in the original's place. A download hands over the bytes you uploaded, under the name you gave them.

Its people tags, comments, favorites, and place in every album come back with it exactly as they were, because none of that was touched.

After 60 days, or sooner if it's deleted forever from that screen, it goes for real: the record and everything hanging off it in one motion — its faces and their embeddings, the description and keywords, the transcript, the comments, the favorites, its place in every album. Then the files — original, preview, enhanced copy, and every stored thumbnail.

Two things stay. One is a line in the activity feed saying it was deleted, and by whom. A record of what is no longer there is the part of a shared archive that cannot be reconstructed later, and it holds the name rather than the photograph.

The other is the weekly off-site copy at Backblaze B2 — the second copy described under How safe this is. That copy is written once and never written over, which is what lets it survive a mistake made here; the same property means a deletion made here does not reach it. Nothing takes a photograph back out of it on a schedule either, so a photograph that has to come out of the backup as well comes out by hand, done by whoever runs the archive. The exception is a photograph uploaded and deleted inside the same week, which the backup may never have copied in the first place.

The credentials for it belong to the deployment and not to any person, nothing is served out of it directly, and the app is the only door.

Nothing is re-encoded or shrunk on the way, and it carries the filename the family gave it. Open a photograph and the Download button is under it. Where a second version exists the button asks which you want: the JPEG copy of a HEIC that opens anywhere, the enhanced copy if somebody made one, the 1080p MP4 of a video that attaches to an email. The original is what you get unless you pick one of those by name.

On a phone there is a second door beside Download, because the first one leads to Files and a photograph belongs in Photos. Save to Photos hands the file to the phone's own share sheet, which offers “Save Image” next to AirDrop and Messages, and the picture lands in the camera roll where everything else on the phone can find it. Same bytes either way. A very large video is offered Download only — the share sheet needs the whole file in memory at once, and a phone would rather kill the tab than let that happen.

A selection from Photos & video and a whole album from its page were both meant to come down as a zip, and neither is built — selecting photographs works, but what the bar that appears when you select several photographs does with them is edit and file, not download. Getting a large archive out in one motion is the obvious thing to want and it is honestly missing; it is recorded here as absent rather than as impossible.

That schedule also reads a sample back and hashes it to prove the copy is still byte-for-byte right. It is on top of the redundancy already inside each service the archive depends on, which only stands between a photograph and a single failed disk. It does not stand between a photograph and an account closed by mistake, a company that stops operating, or a change nobody catches in time — which is what the second copy is for.

The restore has been rehearsed, not just assumed: rebuilding the database from a dump and reading the files back from B2 has actually been done, once, end to end, against a database made for exactly that and thrown away after. What is still missing is a written succession plan — who else could reach the accounts this depends on, and what they would do — a different, unbuilt half of the same problem.

The file you uploaded is the copy of record, whether it is a photograph, a video, a voice recording or a document, and the B2 copy is checked against it on a schedule after that. The thumbnails, the browser-friendly copy of a HEIC, the version that streams when you press play: none of those are backed up separately — they are made from the original and can be remade from it, so losing one costs time, not the photograph itself.

The two do not go away together, which is the point of having a second one. Deleting a photograph forever removes the first copy and leaves the second sitting in the backup; taking it out of there as well is somebody's job rather than a schedule's. The deletion answer under Your files says what that means in practice.

Two different answers, because “undone” means different things here. A deleted photograph is the easy case: 60 days in Recently deleted, restorable the whole time, with its people, comments and place in every album coming back exactly as they were.

A changed one is the harder case, and there is no button for it. Overwrite a caption, untag somebody, reorder an album — the database behind it can be wound back for up to seven days. Past that, the only record of what happened is a line in the activity feed naming who changed what and when, which is enough to put right by hand but is not the same as an undo.

Four companies are paid, monthly, from one person's card, to keep this running: hosting, the database, the storage that holds every photograph and video, and the service that plays video back. Together it runs somewhere around fifty dollars a month, and it is not free to anyone who runs it.

If that stops, a host does not keep serving an archive nobody is paying for. The database and the storage accounts behind it run on their own billing cycles and last longer on their own, but the same thing eventually happens there too: no provider keeps a family archive for free once payment lapses. What that makes worth doing now, while it still works, is exactly the question above about getting everything back out.