nostr-aopの内部設計
Nostrはイベントを中心としたプロトコルです
ユーザーの投稿、リアクション、メタデータなど、多くの情報がイベントとして表現されます
では、アプリケーションの状態もイベントとして管理できるでしょうか？
nostr-aopでは、この考え方を利用しています
Stateを直接共有しない
一般的なアプリケーションでは、サーバー上に現在状態を保存します
例えば：
Database
Game:
players:
- Alice
- Bob
score:
100
しかし、分散環境では複数の場所から変更が発生します
そこでnostr-aopでは、
Event History
join Alice
join Bob
action score +100
から現在状態を生成します
Event → Action → State
nostr-aopの基本的な処理フローです
Nostr Relay
|
v
eventToAction()
|
v
apply()
|
v
Object State Update / onchanged()
イベントを直接状態変更に使うのではなく、一度Actionとして解釈します
これにより、アプリケーションごとのイベント解釈を整理できます
管理しているObject情報
AOP Objectでは以下を管理します
- lifecycle
- users
- permissions
- history
- pending actions
例えばinviteとjoinの場合：
Owner
|
| invite event
v
Invited User / etc.
|
| join event （invite eventによって許可される）
v
etc.
という流れになります
Permission管理
分散アプリケーションでは権限管理が重要です
誰でも状態変更できる場合、アプリケーションとして成立しません
そのため、AOPではイベントを検証し、
- 誰が送ったか
- 権限があるか
- 取り消されていないか
を確認します
Event Sourcingとの関係
この設計はEvent Sourcingの考え方に近いです
現在状態を保存するのではなく、
Events
↓
State Reconstruction
↓
Current Object
という形になります
これにより、
- 履歴確認
- 状態復元
- 同期
が自然に扱えます
Reducerは現在導入しておらず、呼び出し側のonchange関数内で応用Stateは実装する必要があります
今後の課題１
今後、Relayの不安定さが課題となります
Relayによって処理するイベントの種類、イベントの保持期間、送受信の頻度による送信拒否などが異なっています
そもそも、インターネットの状況などにも左右されます
その場合、
- 同じイベントの重複
- publish成功条件
など、新しい問題が発生します
分散アプリケーションでは、通信層だけではなく状態管理モデルも重要になります
nostr-aopはそのアプリケーション層を作る試みです
今後の課題２
インターネット上に暗号化せずにObject／Actionをあげるため、参加者のpubkeyリスト、行動内容、（場合によっては通信内容）が公開されます
「＜あるpubkey＞が＜どのpubkey＞とよく＜とあるアプリ＞を使っている」という情報が取得できる
ただし、ユーザーが他のアプリとpubkeyを共有せず、アプリごとに使い捨てのpubkey（匿名鍵）を利用している運用であれば、IPアドレス等の現実の個人情報に紐づかないため、このメタデータが第三者に漏洩したとしても実質的なプライバシー上の意味（実害）はほとんどなさないと考えられます
（※同じpubkeyをメインのSNS等でも使い回している一般的なユーザーの場合や、通信元のIPアドレスと照合されるリスクを考慮する場合は、ソーシャルグラフの流出として意味を持つことになります）また、ユーザーが「信頼できるリレー（またはTor/VPN）」を利用し、かつそのpubkeyを使ったサービスの使用を完全に匿名で行っている場合、この情報が漏洩したとしても、現実の個人情報（IPアドレスや本名）に紐づくことはありません
そのため、第三者がこのデータを取得したとしても、実質的なプライバシー上の意味（実害）はなさないと考えられます
通信内容に関しては、"encrypted"プロパティを用意してますが、暗号化は使用者側の任意です