技術的なフィードバック
データ制御プラットフォーム上でどのような定義づけをするか？
データフォーマットを定義づける
日付、名前 etc..
ただこれはデータ利用者によって必要なデータが難しい
だからデータの相互運用性が難しい状態になっている
これはフォーマット内の情報が定義づけられている
オープンソースプロジェクトにすることで、自分たちにあったデータフォーマットをデータ利用側が開発することも可能である。
これ結構大きいのでは？Yudai.icon
メタ的にデータフォーマットを定義づける
XMLやJSONはデータフォーマット自体を定義づけしていることと同じ
VCがなんのデータフォーマットを使用するかなどが議論されている理由が分かったYudai.icon なんのフォーマットを使用するか = 定義されたフォーマット以外はそのユーザーのフォルダ内は存在しない
これを僕たちが定義づける必要がある。
疑問点としてユーザーのフォルダ内(つまりプライベート空間内？)ごとに、定義づけていく事とか可能なのかな？Yudai.icon
API
https://scrapbox.io/files/6403f57e1972e3001b90c78d.png
Pipele
https://scrapbox.io/files/6403f5cabf9ff6001c616ea2.png
※作成していただいた図
Pipele上にデータをプラットフォーム(= Amazon表記)から保存される。
データのみだと、データ利用者がPipele上に保存されているデータにアクセスするためにリクエストしても、なんのデータが返還されるか分からない。
そのためにプラットフォーム側のAPIが必要らしい
これ多分情報の真であることの証明を行うことにも近い気がするけど
Pipele上でのデータフォーマットの定義づけもされる
API情報がないとその情報の識別が出来ないっぽい
人やプラットフォーム中心ではなく、人間中心にデータを保存する事を" Pesonal online data"と呼んでた。
面白かったのがUniversal APIの実現。
Universal APIで、SolidのPodにデータを保存していき、異なるアプリケーションでデータが使用可能になる。
まるっきり同じじゃない？Yudai.icon
OpenAPI仕様（旧Swagger仕様）は、REST APIのためのAPI記述形式です。
code: API
openapi: "3.0.3"
info:
title: "Sample API"
version: "1.0.0"
paths:
"/api/v1/hello":
get:
summary: "hello"
responses:
"200":
description: "成功"
content:
aplication/json:
schema:
type: string
example: "hello"
「/api/v1/helloというパスには、文字列データが入っている」ということを宣言します。このAPIの利用者は、「/api/v1/helloというURLにアクセスすると、文字列が返ってくるんだな。じゃあ、その文字列を使ってこういうことをしよう」という開発ができる感じです。
API自体の勉強にもなる
これはプライベート空間の検索の回答でもあるのかも？
ただこれ何が返ってくるのか分かるとそれは公開されていることになるとも思う
提供できること？
URLとデータ定義
アクセス制御
果たしてLit Protocolを使用して進めるのがいいのかどうか
Lit Protocolに依存していく状態になる。つまりLit Protocolが終わったら進まなくなるという事では？
うーん、確かにそうではあるYudai.icon
Lit Protocol側はシステムを止めたくない、僕たち側もシステムを止めたくない
これって利害の一致ではないのかな？？
当たり前のことなのかもしれんけど、クリプトでComposabilityがよく出てくるけど、僕的にはある意味では依存することも必要なのかもとは思う ある意味では僕たちのエコシステム上に開発してくれる人たちは僕たちに依存するわけで。