PrivacyNotes.app: an E2EE notes app whose client source you can read
End-to-end encrypted notes, tasks, files, passwords, journal and bookmarks. Keyed by a 12-word BIP-39 phrase: no email, no password, no account to leak. The full client source for web, desktop and mobile is published, along with the encryption (XChaCha20-Poly1305, HKDF-SHA256, Ed25519) and the threat model, so the privacy claims are falsifiable.
At a glance
- What is it?
- PrivacyNotes.app stores notes, tasks, a journal and files under a 12-word BIP-39 phrase instead of an account, and publishes the client, the crypto core and the threat model under AGPL-3.0. The code is auditable; the audit has not happened yet.
- Who is it for?
- PrivacyNotes.app suits people who want a notes app with no email, no password and no server-readable content, and who will actually read crypto/crypto.ts or VERIFY.md before trusting it. It does not suit anyone who needs a third-party audit certificate today, because the repository badge still reads 'Third-party audit: not yet', or who wants a hosted provider to hold a recovery key.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What PrivacyNotes.app solves, and for whom
Most note apps ask for an email and a password, then hold a copy of everything you wrote. PrivacyNotes.app removes the account entirely. A 12-word BIP-39 mnemonic, generated on your device, is both your identity and your key. There is no email to leak, no password to reset, and, according to the README, no title, body or tag in the server's notes table: the screenshot in the repository shows rows containing a public key, a ciphertext and a nonce.
The audience is narrow and specific. It is for people who already accept that losing a recovery phrase means losing the data, and who want to check the encryption themselves rather than read a marketing page. The repository exists for that second group: as the README puts it, "Privacy claims need proof." The published files are the client applications, the cryptographic core, and the threat model, described as the real files that ship rather than summaries.
It is not aimed at teams that need shared workspaces with server-side search, or at users who want a provider to be able to restore access after a lost phrase. Those are different products with different trust models.
How the key hierarchy and note encryption actually work
The design is a single seed fanned out into five domain-separated keys. The 12-word mnemonic (128 bits of entropy) goes through the standard BIP-39 PBKDF2 path to a 64-byte seed, and every key is then derived from that seed with HKDF-SHA256 under its own info string, so no two uses share key material. The README lists them: `privacynotes-signing-v1` produces the Ed25519 private key whose public key is your user ID; `privacynotes-encryption-v1` produces the 32-byte symmetric key for notes, attachments and images; `privacynotes-local-at-rest-v1` seals content in the device's own storage and is never stored or transmitted; `privacynotes-auth-password-v1` produces the password for the anonymous account carrying your session; and `privacynotes-fp-pepper-v1` peppers the device-grouping signals described in SECURITY.md so the server never sees the raw values.
Note encryption uses XChaCha20-Poly1305 under a random 24-byte nonce, with title, body, tags and metadata such as trashed and starred state inside the plaintext payload. The README makes a concrete argument for the nonce size: 24 random bytes make collision risk negligible without a counter, unlike AES-GCM's 12 bytes. That is a real design decision, not a slogan, and it is the kind of detail you can check in `crypto/crypto.ts`, about 560 lines and commented step by step. Attachments and images go through the same cipher in `crypto/blob.ts`.
Account binding is signature-based. Pubkey-to-account linking uses Ed25519 signatures over structured challenges of the form `link:<authUid>`, and device registration and revocation reuse the shape. Each signature binds to the session's auth UID, so a captured signature cannot be replayed into a different session. The dependency surface is deliberately small: `@scure/bip39`, `@noble/hashes`, `@noble/ed25519` and `@noble/ciphers`, each with zero dependencies.
Installing from source and encrypting your first note
The repository publishes the client under `application/`. The README gives one command line for building it from source, run from the repository root:
cd application && pnpm install && pnpm buildThat is the whole documented build path. The README does not describe environment variables, a development server port, or a signing step, so treat anything beyond this line as undocumented. If you only want to see the app running, the README points at a hosted demo at try.privacynotes.app, which it says saves nothing and runs the real encryption.
To check the claim that your phrase never leaves the device, the repository's VERIFY.md describes a tier 1 procedure that needs nothing but your browser's network tab: you watch your own notes leave as ciphertext. The README frames this as a roughly one-minute check. There is no code block for it in the README, so follow VERIFY.md itself.
For the cryptographic core, the README states that `crypto/crypto.ts` is a copy of the production file and that the canonical version lives at `application/packages/shared/src/crypto.ts`. If you are auditing, read the canonical path; if you want a short link, read the copy. The README is explicit that this is not a reference implementation.
The custodial signup option and other limits worth knowing
The README names one exception to its own central claim. At signup you can choose custodial mode, which it describes as the exception to the statement that your phrase never leaves your device. It is off unless you pick it, but it exists, and anyone repeating the "phrase never leaves the device" line without that caveat is overstating the guarantee. Read that section before you create an account.
There is no third-party audit yet. The repository badge reads "Third-party audit: not yet", and the README links that badge to a security contact section. For a project whose pitch is falsifiable privacy, an absent audit is the most consequential gap: the code is readable, but readable is not the same as reviewed by someone with no stake in it.
The threat model is where the authors put the unflattering parts, and THREAT_MODEL.md is described as the place to start if you are reviewing the project, with known limitations included. That is unusually direct, and it is also a warning: the file exists because there are limits. Nothing in the README describes key rotation, recovery, or what happens if a device is compromised while unlocked, so do not assume those are handled.
Finally, the licence is AGPL-3.0. If you fork the client and run it as a network service, the AGPL's network clause is the part your legal team will want to read. This is not legal advice; it is a pointer to the clause that matters for a hosted derivative.
Where it sits next to a mainstream notes app
The obvious comparison is a mainstream notes app such as Evernote, which the repository's own topic list names. The difference is not features, it is who holds the key. A conventional notes service authenticates you with an email and password and can, in principle, read your content on its servers; server-side search and sharing depend on that access. PrivacyNotes.app inverts it: the server holds ciphertext it cannot read, and the cost is that anything requiring plaintext on the server is off the table.
A second comparison is a local-first notes app with no sync at all. Those avoid the server problem entirely, but you carry the device-loss problem alone. PrivacyNotes.app keeps sync while encrypting on the client, which is the harder engineering position and the reason the crypto core is published at all.
If your requirement is a shared team wiki with server-side full-text search, neither PrivacyNotes.app nor a purely local app fits, and you should not force it. If your requirement is that a subpoena or a breach returns bytes nobody can read, this is the design that targets it.
Maintenance, releases and what upgrading costs you
The repository is not archived, and the last push was on 2026-09-15. Recent releases are versioned in the 0.5xx range: v0.518.1 and v0.517.3, both dated 2026-09-15, and v0.514.3 on 2026-09-10. The cadence visible in those tags is fast, with two releases on the same day, which fits a project still below 1.0 and still changing.
That cadence has a cost for anyone building from source. The README's build line is `cd application && pnpm install && pnpm build`, with no lockfile guidance, no version pinning advice and no upgrade notes. Frequent point releases plus an unpinned dependency install means you should expect to re-read the crypto core when you pull, not just rebuild. The info strings in the key derivation table are versioned (`privacynotes-signing-v1`, `privacynotes-encryption-v1`), which suggests the format is meant to be stable even as the app version moves, but the README does not document a migration path between versions.
The licence is AGPL-3.0, and the repository also carries a NOTICE.md and a CONTRIBUTING.md. If you modify and redistribute the client, or expose a modified version over a network, the AGPL's source-availability obligation is the term to examine with counsel. Nothing in the README grants additional permissions.
Editorial conclusion
PrivacyNotes.app suits people who want a notes app with no email, no password and no server-readable content, and who will actually read crypto/crypto.ts or VERIFY.md before trusting it. It does not suit anyone who needs a third-party audit certificate today, because the repository badge still reads 'Third-party audit: not yet', or who wants a hosted provider to hold a recovery key. Before adopting it, read THREAT_MODEL.md for the limitations the authors admit to, and check the custodial signup option, which the README describes as the one exception to the claim that your phrase never leaves your device.
Frequently asked questions
Can hackers access my notes in PrivacyNotes.app?
The README states that the server stores only ciphertext it cannot read: rows in the notes table contain a public key, a ciphertext and a nonce, with no title, no body and no tags. It also publishes THREAT_MODEL.md and SECURITY.md, which describe what the project protects against and what the server can see. What the README does not claim is that the client is free of bugs.
Is PrivacyNotes.app safe to use?
The client, the crypto core and the threat model are published under AGPL-3.0 so the privacy claims can be checked, and the README points to VERIFY.md for a browser-based check that notes leave as ciphertext. The repository badge still reads "Third-party audit: not yet", so the code has been made readable rather than independently reviewed. The README also notes one exception at signup, custodial mode, which it says is the exception to the claim that your phrase never leaves your device.
Can someone read my notes on my iPhone with PrivacyNotes.app?
The README says notes are encrypted on the device under a key derived from your 12-word BIP-39 phrase, and that the server sees only ciphertext. It does not document what happens if the device is unlocked and compromised, and THREAT_MODEL.md is the file that lists the known limitations. Read that file before relying on any specific device scenario.
Can anybody see your notes app content on the server?
According to the README, no: the production notes table holds a public key, a ciphertext and a nonce, and the cryptographic path is in crypto/crypto.ts using XChaCha20-Poly1305 under a random 24-byte nonce. The README recommends confirming this yourself through the network tab, following VERIFY.md tier 1.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/lifetimelabsdev-privacynotes-app)