Data Availability ≠ Data Storageのおかげでデータ管理プラットフォーム(draft)で何を実現させたいかの全体像の説明がしやすくなったのと自分たちのポジションも明確になったと思う

Pipeleでの実装はデータを暗号化して保存して、アクセス制御が実装されている。

これはCanned foodにデータを入れる作業と同じ

Personal空間 = Canned food

IPFSの中に境界線を引きユーザーだけの空間を作成している

足りない部分

1つのDIDでは実現可能だけど、複数のDIDを接続した際に、どのように異なるDIDで他のCanned foodを制御するのかって部分の設計が足りない

1つのPersonal空間の中に複数のデータが入っている場合に、他のデータは見えないままにして目的のデータにのみアクセス可能にする

Cryptreeは1つ解決方法になりうる

そうなるとLit Protocolの実装では足りなさすぎる

つまり暗号化、復号化の実装を自分たちで0から実装する必要がある

= Nodeを建てたりとかなり多くの作業が必要になる可能性がある

1つ1つのデータごとに空間の作成を行う

これはまじで地獄だよね...

鍵になるのはSymmetric LinkとAsymmetric Link

これによって量を指定することができる

なんのデータが入っているのか、どこで作成されたのか、正しいデータなのかの証明をする

= Universal APIの実現 = 全てのデータは検証可能

これ分散型台帳だからこそ実現可能なのではないか？

Write Access Cryptreeによって許可された人のみが書き込み、つまりはデータの保存や管理が可能

ここをユーザーが簡単に出来なくするなど色々と可能ではある

CIDの更新によっても分かる

誰によってが重要な場合、秘密分散法との組み合わせってかなりいい感じに出来そう

誰が書き込んだかの証明は可能

アクセス可能期間の設定を可能にする

これCodeによる規制可能性の重要な部分

dirty keyをどのように洗浄するか

技術的な部分もそうだけど、どう制約するのかの設計が大事やな

ここの部分考えよう

Cryptreeでは時間的な概念があるから可能そう

これらの実装が僕たちが行おうとしていること

なぜ必要なのかがData Availability ≠ Data Storageによって言語化がしやすくなった

データ管理プラットフォーム(draft)によってCanned foodからbuffetへ何を出すのかを選択するchefと同じなのである

つまりPersonal data => Commons data

「=>」には、選択だけではなくDifferential privacyやFederated learningの計算処理も含まれたりする

僕たちは秘密処理を次にやる or ハッカソンを開いたりする必要があるのか

エコシステムを拡げるために

これって僕たちの方でライブラリー出せるんじゃね？？？

ただCollective dataがどこに入ってくるのかがイメージ湧かなくなってきた

これに対してはPhilippeたちと対話を重ねながら探す