Lamponi
When you sign in, your password is used on your device to derive two separate keys (PBKDF2-SHA256, 600,000 rounds). One becomes a login token — the only thing our server ever sees. The other stays on your device and unlocks your data. We never store the password you actually typed — and once your account is on the new system, it never leaves your device again.
Your device generates a random master key that locks the individual key each meeting is encrypted with (AES-256-GCM, a fresh key per meeting). That master key is stored on our servers only in locked form: once locked with your password-derived key, and once with your recovery code. We can store the locked box. We cannot open it.
When you create your account — or the first time an existing account is upgraded — Lamponi shows you a recovery code exactly once and asks you to confirm you saved it. It is the only other way into your data if you forget your password. We do not keep a copy; if we did, the whole promise above would be theater.
That — plus routine sync metadata like meeting IDs and share-link URLs — is the entire list. The metering is numbers, not words — it is how we keep the free tier from being abused.
Transcription and AI answers are the one place your words leave the encrypted vault, and we would rather explain it precisely than hide behind a blanket claim. When you transcribe a meeting or ask the AI a question, your device decrypts just what is needed and sends it to our transcription provider and the AI models that generate summaries and answers.
That processing is ephemeral, and it is contractually locked down: our transcription provider and the AI keep no copy of your content and never train on it. Our relay servers hold your content in memory only — they never write it to disk, never log it, and answer with an X-Lamponi-No-Store header that says so. The audio handed off for transcription is deleted as soon as your transcript is fetched. Nothing from this path is stored, and nothing is used to train anyone’s models.
We do not claim “end-to-end encryption” over this path, because it would not be true — an AI cannot process words it cannot read. No product that processes your meetings with cloud AI can honestly make that claim. What we can claim, and stand behind: your content is stored zero-access, and processed only transiently, never kept.
Meetings on your own computer are stored as normal, unencrypted files — it is your device and your disk, and things like the Obsidian export keep working exactly as before. The encryption applies to everything that leaves your device.
When you share a meeting, the shared copy is encrypted too. The decryption key travels inside the link itself — in the URL fragment after the #, which browsers never send to servers. We host the ciphertext; the key exists only in the link you send. That also means a share link is exactly as private as you keep it: anyone you give the link to can read that meeting. Sharing is opt-in, per meeting.
Your recovery code gets you back in: reset the password, enter the code, and your meetings unlock. But if you lose both the password and the recovery code, your encrypted data is unrecoverable — by you, by us, by anyone. There is no support ticket that can undo the math. We designed it that way on purpose: an escape hatch for us would be an escape hatch for everyone else too.
Because it cannot be, and we will not pretend otherwise. A transcription engine needs to hear the audio; a language model needs to read the words. What we control is everything around that moment: the decryption happens on your device, the processing is transient, our relays never store or log content, and provider artifacts are deleted when the job completes. If another cloud meeting tool tells you everything is end-to-end encrypted, ask them how their AI reads your transcript.
They were upgraded. The first time you unlock the updated app, it re-encrypts your existing cloud meetings on your device and deletes the old unencrypted copies from our storage. One deliberate exception: share links you had already sent keep working — in their original, unencrypted form — because a share is content you chose to publish, and breaking every link your team relies on would help no one. Revoking them from Settings deletes them for good.