プロトコルを再設計しよう。
まずJSONLDは正規化がややこしい上にデータ形式がヘドロなので殺す。
代わりにlysand protocolを見習って非標準プロパティは全てextensionプロパティに入れる。
extensionプロパティはソフトウェアが好き勝手に設定していいが、同じソフトウェアの同じバージョンでは一貫した振る舞いをすることが望ましい。
extensionプロパティを読む際は、いかなる直下のプロパティも仮定してはならない。
また、extensionプロパティのキー名についてはUUID v7でなければならない。異なるUUIDについて全く同じ意味論で使用すること、及び同じUUIDについて全く異なる意味論で使用することは混乱を招くため禁止する。
別の言葉で言うと、UUIDが同じであることと、意味論が正確に一致することは同値でなければならない。
これは報告者側の責務である。受理者は診断不要。
また、各オブジェクトのルートには一位なUUIDを振ることとして、それが同一なら同一とみなす。
次に署名、APでは特に定めていないが、draft版のHTTP Signatureが使われることが多い。このプロトコルはそれを廃用にし、IETF RFCとなった方のHTTP Signatureを採用する。
最後にコンテンツの冗長化、これはpeertubeを見習ってデフォルトでは行わない。やりたいやつが勝手にやればいい。
その代わりサーバーがトップレベルで持つインデックスキャッシュを必要になったら引くこと。ETagおよびLast-Modifiedを適切に報告運用活用することでCloudflareなどのリバースプロキシがキャッシュを返しストレージ使用量がぐんと減る。
プロトコルを再設計しよう。
まずJSONLDは正規化がややこしい上にデータ形式がヘドロなので殺す。
代わりにlysand protocolを見習って非標準プロパティは全てextensionプロパティに入れる。
extensionプロパティはソフトウェアが好き勝手に設定していいが、同じソフトウェアの同じバージョンでは一貫した振る舞いをすることが望ましい。
extensionプロパティを読む際は、いかなる直下のプロパティも仮定してはならない。
また、extensionプロパティのキー名についてはUUID v7でなければならない。異なるUUIDについて全く同じ意味論で使用すること、及び同じUUIDについて全く異なる意味論で使用することは混乱を招くため禁止する。
別の言葉で言うと、UUIDが同じであることと、意味論が正確に一致することは同値でなければならない。
これは報告者側の責務である。受理者は診断不要。
また、各オブジェクトのルートには一位なUUIDを振ることとして、それが同一なら同一とみなす。
次に署名、APでは特に定めていないが、draft版のHTTP Signatureが使われることが多い。このプロトコルはそれを廃用にし、IETF RFCとなった方のHTTP Signatureを採用する。
最後にコンテンツの冗長化、これはpeertubeを見習ってデフォルトでは行わない。やりたいやつが勝手にやればいい。
その代わりサーバーがトップレベルで持つインデックスキャッシュを必要になったら引くこと。ETagおよびLast-Modifiedを適切に報告運用活用することでCloudflareなどのリバースプロキシがキャッシュを返しストレージ使用量がぐんと減る。