Notesnook

Encrypt notes on the device so the server receives ciphertext rather than readable note content

The official encryption documentation says each item is encrypted before sync with XChaCha20-Poly1305-IETF. A master key is derived with Argon2i, while Argon2id is used for the server-side password hash path. The actual password and decryption keys do not leave the device, and the server stores encrypted blobs it cannot open.

Sources: [2]

Ship web, desktop, and mobile clients from one monorepo with shared editor, core, and crypto packages

The repository contains the web client, Electron desktop app, React Native mobile apps, Web Clipper, shared core, crypto wrappers, and editor packages. The README describes React across the front end, React Native on mobile, Electron on desktop, and an ongoing migration toward TypeScript, making the client and cryptography stack inspectable in one codebase.

Sources: [1][4]

Replace the hosted backend with your own sync, auth, events, and monograph endpoints

Every Notesnook client can be pointed at four self-hosted endpoints: sync, auth, events/SSE, and monograph. The self-hosting guide runs the server stack with Docker Compose on Linux, then has the client test and save all four URLs. End-to-end encryption remains in place, so self-hosting can also keep the encrypted server-side data off Notesnook-operated machines.

Sources: [3]

A fit for users who want Evernote-style convenience without giving the storage provider plaintext access

Notesnook is relevant when cross-device notes are important but the service operator should not be able to read note content, when web, desktop, and mobile clients need to stay aligned, or when an organization wants the option to run the synchronization infrastructure itself. Open client and crypto code also helps teams that want to inspect implementation details rather than rely only on product claims.

Zero knowledge also means losing both the password and recovery key can make the notes unrecoverable

Because Notesnook does not hold the keys needed to decrypt user data, losing both the password and account recovery key leaves nobody, including Notesnook, able to recover the notes. Adoption should therefore include secure recovery-key storage and backups that are independent of a single client or server.

Sources: [2]

Self-hosting is a multi-service operation with HTTPS, SMTP, backups, and a deliberate backend migration procedure

The official self-hosting guide assumes Linux, Docker, and Docker Compose and lists 1 GB of RAM and 20 GB of storage as baseline requirements. SMTP is needed for password reset or email-based two-factor authentication. Browser and mobile use require HTTPS, and all four required server endpoints must move together rather than mixing hosted and self-hosted services.

When switching an existing client from the official backend to a self-hosted instance, the guide tells users to back up first, log out, change the server URLs, create a new account on the new instance, and restore the backup. It is not an account-transfer mechanism. The server stack itself comes from the separate notesnook-sync-server repository, while this client repository is GPL-3.0 licensed.

Sources: [3][5]