Notesnook

ノートを端末側で暗号化し、サーバーにはciphertextだけを送る

公式ドキュメントでは、各itemを同期前にXChaCha20-Poly1305-IETFで暗号化し、passwordからArgon2iでmaster keyを導出すると説明しています。server login用password hashにはArgon2idを使い、実際のpasswordと復号keyは端末外へ出ません。サーバーが受け取るのは暗号化済みblobだけというzero-knowledge設計です。

出典：[2]

Web・desktop・mobileを同じmonorepoで揃え、clipperと共通crypto/coreも公開する

このrepositoryにはWeb client、Electron desktop、React Native mobile、Web Clipper、shared core、crypto wrapper、editorなどが同居しています。READMEではfront-endをReact、mobileをReact Native、desktopをElectronで構成し、TypeScriptへの移行を進めていると説明しています。プラットフォームごとに別製品ではなく、共通coreと暗号化実装を持つclient群として追えるのが特徴です。

出典：[1][4]

公式クラウドから離れ、4つのserver endpointを自前環境へまとめて切り替えられる

Notesnookの各clientはsync、auth、events/SSE、monographの4 URLを自前serverへ変更できます。self-hosting guideではLinux上にDocker Composeでserver群を起動し、client側で4 URLをtestして保存する構成を案内しています。E2EEはself-host時も維持されるため、暗号化済みdataをNotesnookのmachineへ置かずに運用できます。

出典：[3]

Evernote型の使い勝手を残しつつ、暗号化とserver運用の主導権を持ちたい人に

複数端末で同じノートを使いたい一方、providerが平文を読めない設計を重視する人、Web・desktop・mobileを横断したい人、必要ならsync infrastructureまで自組織へ寄せたい人に向きます。clientとcrypto実装が公開されているため、暗号化やstorageの挙動をsourceから確認したいチームにも比較価値があります。

passwordとrecovery keyを両方失うと復号できず、E2EEはbackup責任も利用者側へ移す

zero-knowledge設計の裏返しとして、passwordとaccount recovery keyの両方を失った場合はNotesnook側でもノートを復号できません。導入時はrecovery keyを安全に保管し、clientやserver障害とは独立したbackupを用意する必要があります。

出典：[2]

セルフホストは単一containerではなく、server群・HTTPS・SMTP・backend切替手順まで運用対象になる

公式self-host guideはLinux、Docker、Docker Composeを前提にし、最低1GB RAM・20GB storageを案内しています。password resetやemail-based 2FAを使う場合はSMTPも必要です。browser/mobile利用ではHTTPSが必要になり、sync/auth/events/monographの4 serverはすべて自前側へ揃える必要があります。

既存の公式backendからself-hostへ切り替える際は、先にbackupを取り、logoutしてserver URLを変更し、自前instance側で新しいaccountを作成してbackupをrestoreします。account自体をbackend間で移動する機能ではありません。またserver実装は別repositoryのnotesnook-sync-serverから取得します。client repository本体はGPL-3.0です。

出典：[3][5]