Your recordings are a folder you can read without us

"You own your data" is the cheapest sentence in software. Every product says it, including the ones where your data is a row in a database you will never see, exportable on request into a format the vendor chose.

The test is not whether the sentence is said. It is whether somebody will show you the folder. Bought, not rented means very little if the thing you bought lives somewhere you cannot point at.

So here is ours, file by file — and then the two things that only become possible once the folder is real: getting the contents out, and keeping two machines in step using storage you already pay for.

The layout

vault/
├─ .yapyap-vault.json            the vault's identity card, written once
├─ inbox/                        drop audio here and it becomes a recording
├─ recordings/
│  └─ 2026/08/                   one folder per recording, dated
│     └─ 2026-08-08-1417-a1b2c3d4/
│        ├─ audio.flac           the audio, as yapyap recorded it
│        ├─ audio.md             the transcript, in your chosen format
│        └─ source.m4a           an import, kept exactly as you gave it
├─ logs/
│  └─ <machine>/                 transcripts, titles, marks, speakers
│     └─ *.plog                  append-only, signed, mergeable
├─ catalog.<id>.json             speakers, vocabulary, lenses, chats
├─ installs/                     one small file per machine using this vault
└─ .trash/                       deleted recordings wait here for 30 days

That is the whole thing. No database server, no proprietary container, no index you need our software to open.

The three files that matter

audio.flac — the recording, at 16 kHz stereo, in a format that has been an open standard since 2001 and is losslessly decodable by roughly everything. VLC opens it. ffmpeg converts it. Your grandchildren's software will open it, because a format this widely implemented does not stop being implemented.

audio.md — the transcript, sitting in the same folder as the audio it belongs to. The extension follows whatever you picked in Settings → your vault → transcript format: markdown, plain text, VTT, SRT, JSON or CSV. All six are text. All six are readable in Notepad.

source.m4a — if you imported the file rather than recorded it, your original is kept byte for byte. We do not transcode your input and quietly discard it. Anything captured on your phone lands here too, once the desktop has it.

The important property is the pairing. The audio and its transcript are adjacent, in a folder named for the date and time it was recorded. Copy that one folder anywhere and it still makes sense to a stranger with no software at all.

Export, three ways

The folder makes export slightly redundant, which is the point. But there are three genuine reasons to want a file out, and all three are one action.

One transcript, in the format the next tool wants. Open the recording, Actions (⇧⌘K), Export, pick from Markdown, plain text, WebVTT, SubRip, JSON or CSV. Markdown for a notes app or wiki, VTT and SRT for subtitling video, JSON when a script needs the full structure with speakers and timestamps, CSV for a spreadsheet.

Everything, as one portable archive. Settings → your yapyap → export → export all data produces a single yapyap-export.zip: every recording with its audio, its metadata and a transcript beside each audio file, plus your speakers, lenses and vocabulary. And it reads back — Settings → your vault → Import a bundle… takes the zip and restores it. An export you cannot re-import is a souvenir, not a backup.

Never, because it already happened. A transcript file is written beside every audio file as a matter of course, in the format you chose. The most common export is the one you do not have to perform.

Worth noticing what is absent from that list: a queue, a job that emails you a link in four hours, a size limit, a paid tier. Exporting is cheap here because it is mostly just copying files that were already sitting on your disk in the shape you asked for.

Sync: bring your own

yapyap runs no sync server. Nobody here is standing between your laptop and your desktop, and there is no yapyap cloud for your recordings to pass through.

What yapyap does instead is make the vault safe to put inside whatever sync you already own. Because it is an ordinary folder, it can live anywhere a folder can live:

• iCloud Drive, OneDrive, Google Drive, Dropbox — the storage you are already paying for, syncing to your other machine the way it syncs everything else.
• A NAS in the cupboard, if you would rather no third party held it at all.
• An external drive or a USB stick, carried between two machines by hand.
• Nowhere, staying exactly where it is, if one machine is all you use.

Move it in four clicks: Settings → your vault → location → Change…, pick the folder, confirm. The dialog tells you what will happen before anything moves — everything you have moves with it, nothing is deleted — and the app keeps working during the move. If the folder you pick is already a yapyap vault, it tells you how many recordings are in it and adds them to your library rather than replacing anything.

Two safety properties worth knowing, because they are what make putting an archive on a sync service reasonable rather than reckless:

An interrupted move leaves everything in the old location, untouched. Power loss, a yanked drive, a laptop that sleeps mid-copy: nothing is half-moved. Across disks, yapyap copies everything and verifies every file before deleting anything from the source. Run the move again when the drive is back.

yapyap refuses to become a folder somebody else organised. Your home folder, Documents, Desktop, Downloads, Music, Pictures, the root of a drive. A folder inside any of those is fine. Moving a vault leaves a marker file and merges everything into the target, and that is not a thing to do to your Documents folder.

Why this works with two machines

Cloud drives are notoriously bad places to put application data. Two machines write the same file, the service makes a "conflicted copy", and something is quietly lost. The vault is laid out specifically so that does not happen.

Every machine writes to its own log directory. Look at logs/<machine>/ in the layout above. Titles, marks, speaker names and the transcript's own history are append-only, signed entries — and no two machines ever write the same file, so there is no file for a sync service to find a conflict in. Each machine reads all the logs and merges them. That is why the design survives Dropbox where a shared SQLite database would not.

The folder is the authority; the app's database is a copy. Which means the recovery path for anything going wrong is not a support ticket. Copy the vault to a new machine, click Rebuild library, and recordings, transcripts, speakers, lenses and vocabulary all come back.

A missing file never deletes anything. This is the one that matters most on a cloud drive. An unmounted NAS, a drive you pulled out, a sync conflict, an iCloud file that has been evicted to save space — yapyap treats absence as missing, and waits. It does not conclude the recording was deleted and tidy up around it. Deleting is always an explicit act in the app, and even then the files sit in .trash/ for thirty days first.

That last property is worth dwelling on if you use "Optimise Mac Storage" or OneDrive's Files On-Demand. Your audio may be a placeholder rather than a real file at any given moment. That is fine — but a tool that reacted to a missing file by cleaning up its siblings would eat your archive on a slow Tuesday, and plenty of tools do exactly that.

Two honest limits on the multi-machine story. A licence covers two devices at once, so the household version of this is two machines, not five. And a fresh install is a genuinely new device: once a vault has been used by a licensed copy, the titles, marks and speaker names in logs/ are locked to that licence, so activate the same key on the new machine before rebuilding, and pair it from a machine already in the fold. The audio and the transcript files beside it are readable either way, on any machine, with or without yapyap.

The thirty days, stated plainly

A deleted recording is not gone immediately. It moves to .trash/, in the same folder layout, and is purged after thirty days.

That is a retention window, and it is worth naming as one, because we are fairly hard on cloud vendors for having them — see what we do and do not hold. Ours exists for exactly the reason theirs does: people delete things by accident.

Two differences are the whole argument, though. It is thirty days on your disk, not an unspecified interval on somebody's storage cluster. And you can end it early yourself by emptying the folder, which is not a request to anyone.

What is not in the vault

Models, the search index, caches and the licence live in the application data folder, not in the vault. All four are rebuildable, which means the vault is the only folder worth backing up — and that is a deliberate design choice rather than an accident of layout.

If you have ever tried to work out which of an application's seven directories actually contains your work, you will recognise why this matters. It is also part of what a €69 app has to refuse: there is no server-side anything to back up, because there is no server.

The test that actually counts

Here is the exercise. It takes two minutes and you should run it on any tool you are considering, ours included.

Uninstall the app in your head. The software is gone, the company is gone, the website is a parked domain. What is left on your disk?

For a cloud notetaker, the answer is whatever you last exported, in whatever format they offered, if you remembered to.

Here, the answer is: a folder of dated directories, each containing a FLAC file and a text file, sitting on whichever drive you chose to put it on. You lose the app — the search, the lenses, the speaker work, the playback interface, all of it, and none of that is nothing. What you do not lose is the recordings and the transcripts, because they were never in a format that needed us, and they were never in a location we controlled.

That is the difference between owning your data and being given a copy of it.

Why competitors do not publish this page

Not because they are hiding something sinister. Because there is no page to write.

If your audio is an object in a storage bucket and your transcript is a row in a database, "here is every file and what it does" resolves to a schema diagram nobody outside the company can act on. There is no folder to move to your NAS, because the folder is theirs. The honest version of their page is your data is in our system and you may request an export, which is true, and is a different promise.

The folder is the promise. Go and look at it.