A photo is a file. A memory is not. It is a set of photos, the order they are best seen in, a line about each, the people in them and how they relate, and the music under them. Today that set lives inside one app’s database. Close the account and the memory is gone, or it comes back as a folder of files with the meaning stripped out.
A .mem file is a memory as a file. It carries the moments and everything that makes them play well: the lines, the order, the people as roles, the emotional values, the music match, and a stamp that proves when it existed. A person can open it. A player can play it. A model can read it and write from it with nothing else to download.
One file, a version for every person in it
This is the part that is new. The same file plays differently for each person who appears in it. A mother opening the memory sees the photos she is in first, framed on her, with an opening written for her. Her son sees his. There is one file and no duplicated media; the version each viewer gets is a function of who they are to the people in it. That viewer-conditioned rendering is the mechanism Memoresse has claimed. It is patent pending. Chapter 6 explains it.
Yours to keep, move, and hand on
The file does not depend on us. Hand it to a desktop viewer, a family-history app, a script that lays out a photo book, or a model that answers questions about it. Verify it without our code. Move it to a lockbox you own. If Memoresse vanished tomorrow, the file would keep working.
Why a format, not a feature
A memory that only plays in one product is a cache, not a possession. We want .mem files made by camera apps, wedding photographers and estate planners, and opened by players we never wrote. The spec is open; the intelligence that authors a good one is ours. The chapters that follow walk the format from what is in it to how to build and verify one.