頭の中を抽出する

Writer: 書き込み -> 暗号化 -> PDSに保存

Reader: 鍵の共有 -> クエリ(検索) -> -> 復号化 -> 入手

アクセス拒否 -> 再暗号化

Writte function

UserとPlatfoer用の2つの機能がある(Platformerによって保存されたデータをUserが編集可能な場合そのデータは信頼性が無くなる)

User

アップロードボタンを押すと保存したいファイルが選択される

Platformer(制約)

どのように記述されるのか

ファイル形式の定義づけ

Platformerのためのディレクトリはどのように生成されるのか

Userが指定する？それともPlatformerが生成する？

SNSならSNSのディレクトリがある方が識別はし易い

データの信頼性を保つために署名による検証が行えるようにすることは1つなのかもしれない

Platformへの信頼のデザインは僕たちで行うことではなく、正しいローデータかどうかを検証可能にするってことに近い

だからDIDが必須になる

Encryption function

ディレクトリ: 非対称リンク

親ノードの鍵からリンクして暗号化してディレクトリが生成される

ファイル: 対称リンク

ディレクトリにファイルを追加した際にCIDが変化する

どのように紐づけるか

Store function

IPFS上に保存する or P2Pネットワークが必要？

目的はデータの真正性を持たせる

理想はIPFS上に保存が出来る

IPFSの機能のほとんどを使って開発が行えると思うんだけど、Content-addressingの機能だけアルゴリズムを変える必要があると思う(IPFSを拡張する)

どのように元の情報を検索させないか = 削除機能の追加(実際に削除ではない)

どこで状態を管理するのか

P2Pネットワークを独自に作る必要があるのか

Query function

IPFS Subsystems and componentsを参照

ここはそのままできると思う

Shearing key feunction

鍵の共有タイミング

これさ、Cryptreeのルートの鍵(公開鍵？)に対して送信することが出来るのではないか？と思った

Decryption function

鍵が共有される

どのように共有するのか

Get(Download) function

ReEncryption function

更新した際に再暗号化を行う

この問題は元のデータがネットワーク上に残ること

残ることを消すのではなく、更新した際に検索不可能にする(実質削除と同じ)

この実現をどのように行うのか

Soccial Management

誰に共有しているのかの管理

この部分でアクセス拒否とかが出来るUIがあるといい？

そうえばPipeleだとSBTによって管理が可能だった

オンチェーン情報を条件にするとオラクル問題が解決できる

しかしプライバシー面とトレードオフ

アクセス制御ポリシーの設計

ただMonasは抽象化させる必要があり、開発者に委託できるようにする

アプリケーションによって設計は異なるため

Codeによる制約で、静的なアクセス制御はMonasで定義づけてみる

デモでは簡易的に開発はする

Memo:

SDKとして誰でも使える

Platformer側

User側

DIDの機能をどうするのか

データ提供者とデータ要求者のマッチングの設計

WriterとReaderの役割を与える方法

Writerが出来る人は前提としてReaderができる

つまりReaderは前提としてアクセス許可した人は出来ることができ、Writerの許可をする時は新しく鍵を生成することが出来ればいいのではないか？

この鍵によって役割を与える？

DIDによってWriterのアクセス制御の実現が出来ればいいが、結局鍵の生成が必要になるのではないか？と考えている

セキュリティ面

現状は実装に焦点を当てているが、セキュリティ面に対してのアプローチはできていない

圧倒的に量子耐性の部分をどうするんだってこと

Yousei氏の質問で確かにとなった、ありがとう。