Nod

Local-first AI meeting notetaker

How it works

A conversation turns into four kinds of data: the audio, the transcript, the notes, and the keys that protect them. Nod is designed so that only one of them can leave your device, and only in a form nobody else can read.

1What leaves the device

Audio exists in memory only for as long as the speech model needs to hear it. Nothing writes it to disk, to a cache, to a temporary file, or to a crash report. If the app is killed in the middle of a meeting, the transcript written so far is already saved. The audio that wasn't heard yet is gone.

Transcripts and notes are stored on your device, one encrypted file per meeting. The file key never leaves the keychain.

The vault key exists as twenty-four words on paper and in the keychains of your devices. It leaves a device only once: encrypted for a phone you pair, over your own network.

Who can read what. Each row is a party, and each cell is the form in which they hold the data.
AudioTranscript and notesKeys
Your devicesIn memory, while recordingReadable, after the keychain unlocks the fileIn the keychain
The folder or relay that sync goes through—Encrypted only—
Nod, the company—Encrypted files and sync metadata, and only if you choose a relay I run. Nothing otherwise—
People and teams you share with—The title and summary of the meetings you share, nothing else—
An AI assistant you connect—What you allow: notes, transcripts, or both—
YOUR DEVICEMicrophonesystem audioSpeech modelin memory, as heardTranscriptsaved as it is spokenNotessummary modelnever written to diskEncrypted fileAES-256-GCMKeychainholds the file keyunlocksEncrypted for syncwith the vault keythe meeting id is bound into the tag.the sync copy binds the vault and device ids tooFOLDER OR RELAYencryptedno key, nothing to readself-hostableYOUR OTHER DEVICEEncrypted filemerged with AutomergeVault keyfrom 24 words or a QR codeunlocksTranscript and notesreadable, only on your devicesa key, never sent to a serverholds encrypted files onlyThere is no account. If you choose a relay I run, it holds the encrypted files like any other relay, and can't open them.
The path of one meeting. Solid boxes hold readable data and exist only on your devices. The shaded path between them carries encrypted files that the folder or relay can't open.

2The cipher

Each meeting is encrypted with AES-256-GCM, the authenticated cipher that most operating systems and browsers already ship with. An encrypted file starts with a version byte and a fresh 96-bit nonce. The ciphertext and a 128-bit tag follow. The meeting's identity is bound into the tag as associated data. So a file copied into another meeting, another device, or another vault fails to open, instead of opening as something it isn't.

The file key is a random 256-bit key that the operating system's keychain wraps. That's the Keychain on macOS, DPAPI on Windows, a keyring on Linux, and the Keychain or Keystore on phones. The vault key that encrypts files for sync is a separate 256-bit root, written as twenty-four BIP39 words. Every purpose gets its own key derived from it with HKDF-SHA256. A key exposed in one role says nothing about another.

3Sync without a server that can read

Your devices share meetings through a place you choose. It can be a folder that a file sync you already trust carries, or a relay, a small server anyone can run from the repository. Both see the same thing: encrypted files named by device and meeting, with their sizes and times. Neither can open them.

The vault key is never sent to a server. Each device derives it from the twenty-four words of the recovery phrase. A phone gets it by scanning a QR code that carries a one-time pairing secret.

Every meeting is one Automerge document. That's a data structure that merges edits from several devices without a central authority, and without dropping any of them. If two devices rename the same meeting, or edit the same line, both end up with the same result. Deleting a meeting writes a tombstone that every device adopts. A deletion is a deletion everywhere.

4Specification

What the desktop app does, as it is written in its repository.
StorageOne encrypted file per meeting, written atomically
CipherAES-256-GCM, with a 96-bit nonce and a 128-bit tag. The meeting id is bound as associated data, plus the vault and device ids for a sync copy
Key at restA random 256-bit key, wrapped by the operating system's keychain: Keychain, DPAPI, or a Linux keyring, and Keychain or Keystore on phones
Vault keyA 256-bit root, written as 24 BIP39 words. A key per purpose is derived from it with HKDF-SHA256, so no key stands in for another
Sync documentAutomerge, one per meeting. Text merges character by character, and deletions propagate as tombstones
Sync transportA folder you already sync, or a relay you can self-host. Both carry encrypted files only
Pairing a phoneA QR code with a one-time secret. The offer is encrypted with a key derived from it, and the proof sent to fetch it reveals nothing about that key
Speech recognitionParakeet TDT 0.6B v3 or Whisper, running on your device
NotesQwen3 4B Instruct, running on your device once the meeting is over
ModelsDownloaded from a pinned revision, and moved into place only after the size and SHA-256 match
AudioProcessed in memory. Never written to disk, cache, or crash reports
SharingA meeting's title and summary, encrypted for one person or for a team's members. Each person is known by an identity derived from the recovery phrase, checked by an 80-bit code. Team roles: owner, admin, writer, reader
AI assistantsA read-only MCP server on localhost, with a key per assistant that you can revoke. Each reads notes, transcripts, or both, as you allow
PlatformsmacOS, Windows, and Linux now. iPhone and Android in progress, on the same core
SourceOpen at launch, under the Apache 2.0 license. The sync relay is in the same repository, under the AGPL v3