アクセスモデル
Notarium では、アクセスはスペース単位で付与されます。あるロールでスペースのメンバーであること — これがアクセスの単位です。メンバーはそのスペースの内容をすべて見られ、非メンバーは何も見られません。同じモデルが人にも AI エージェントにも等しく適用され、どちらもまったく同じ仕組みでアクセスを得ます。
ロール
スペースのメンバーシップは「スペース + 参加者 + ロール」という三つ組です。ロールは3種類あります。
| ロール | 権限 |
|---|---|
reader | スペース内のすべてを読める。ノート、検索、グラフ、フィード、履歴、エクスポート |
writer | reader ができることすべてに加えて、ノートの作成・編集・削除 |
owner | writer ができることすべてに加えて、スペースのメンバーシップの管理 |
reader ロールは文字どおりの読み取り専用です。インターフェイスは書き込み系の操作(作成、編集、削除、ドラッグ&ドロップ、ゴミ箱からの復元)をすべて隠しますし、仮に呼び出してもサーバーが拒否します。
「スペースの一部だけ」にアクセスを与えることはできません。ノートの一部を共有したい場合は、別のスペースを作ります。特定のノートに対する権限(per-note ACL)もありません。アクセスはスペース単位でのみ付与されます。
統一されたプリンシパル
プリンシパルとは、操作を行う主体のことです。セッションを持つ人、または個人トークン(PAT)を持つ AI エージェントがこれにあたります。どちらも同一の付与の仕組みを通り、すべてのリクエストは同じチェックを経ます。「このプリンシパルは、このリソースに対してこの操作を行えるか?」
実効的なアクセスは、次の2つの積(交わり)です。すなわち アカウントが許すこと(トークンの権限上限)と、プリンシパルがどこにメンバーシップを持っているか です。人のセッションは管理レベルの操作まで到達できますが、エージェントのトークンは読み取りまたは書き込みで頭打ちになります。管理系の操作(トークンの発行、メンバーシップの変更)は書き込みレベルより上に位置するため、漏洩したエージェントトークンでもアクセスを付与したり新しいトークンを発行したりはできません。トークンとエージェントの接続について詳しくは、エージェントを接続する と セキュリティと可視性 を参照してください。
すべてのユーザーは、削除できない自分専用の個人スペースを持ちます。これは他の誰もたどり着けないプライベートなナレッジベースです。個人スペースに2人目の参加者を招待することはできません(サーバー側で禁止されています)。
ユーザーの管理とアクセスの復旧は、内容を読むこととは別のレイヤーです。インスタンス管理者はユーザーを作成しメンバーシップを修復しますが、スペースのデータを読むにはそのスペースのメンバーである必要があります。付与なしで行われたリクエストには、存在しないものへのリクエストと同じ「見つかりません」という応答が返ります。つまり、総当たりで何が存在するのかを探り出すことはできません。
プライバシー:E2EE ではなくセルフホスト
Notarium は意図的に、エンドツーエンド暗号化(E2EE)の製品では ありません。賢いサーバー — 全文検索とセマンティック検索、バージョン履歴、AI エージェントの稼働 — は、その性質上、平文の内容へのアクセスを必要とします。エンドツーエンド暗号化は、これらの機能を成り立たなくしてしまいます。
そこでプライバシーは別の形で組み立てられています。サーバーとファイルを自分で持ち(セルフホスト)、データはあなたの Markdown ファイルのまま、あなたのインフラから外に出ません。これは意図的な立場です。プライバシーの保証は暗号ではなく所有に宿ります — サーバーには見えない暗号に頼るのではなく。
サーバーはあなたのノートの内容を平文で見ています。そうでなければ横断検索したりエージェントに渡したりできないからです。サーバーがそもそもノートを読めない、というモデルが必要なら、Notarium はそれを提供しません。Notarium は個々のノートをクライアント側で暗号化しません。
Notarium は単一インスタンスのセルフホストを前提に設計されています。オープンな登録もマルチテナントのクラウドもありません。
関連トピック:スペースとプロジェクト — 分離の単位、人とエージェント — ナレッジベースへの共有アクセス、認証 — サインインのモードとトークン。