標準のC2S APIが普及したとしても、現状のActivity Streamsの枠組みだと受信者側でのコンテンツのフィルタリングが曲者そう。
現状でも`Note`と`Article`といった区別くらいはあるけど、例えば`Video`に加えて「ショート動画」のようなものは当然ながら標準では用意されていない。この例ではヒューリスティックに判定という手もあるかも知れないけど、そんなどのクライアントで何が見えるのかはっきりしない環境で発信者・受信者ともに嬉しいのか微妙そう。`"type": "ex:ShortVideo"`のようにアドホックな拡張型を用意する手もあるけど、今度はショート動画とその他の動画の区別を気にしないような受信者との互換性が問題になる。いずれにしても中央集権プラットフォーム（やAtmosphere）のように「ショート動画」が満たすべき解像度等の要件の合意を成立させるのは困難そう。
（ちなみにこういう場面で`"type": "ex:ShortVideo"`の対案としてよく提案される解決策として、`"type": ["Video", "ex:ShortVideo"]`のようないわゆるmulti-typeなオブジェクトがある）
ところでvidzyはどうしているのだろうと思って見てみたら、何じゃこりゃ……
AT Protocolでは割と積極的にAppView固有の語彙を作る風潮がある気がするけど、lexiconに対して少数のAppViewのみを想定したAtmosphereと比較して多様な独立した実装間の相互運用を尊んでいそう（ホンマか？）なFediverseにおいてはそこまでの割り切りは馴染まなそうというのが個人的な感想。
読書とアニメ視聴記録というユースケースがあるなら`my.skylights.rel`と`app.netlify.aniblue.status`を作るのがAtmosphereだとすれば、「作品とその閲覧と評価」のような共通項を見出して共有できる語彙は共有するのがFediverseっぽいというか（実際には例えばBookwyrm拡張は「本」しか想定していなそうだけど（`inReplyToBook`とか）……まあ、あくまで概念的な話として、はい）。
TwitterクライアントでRedditは見たくないけど、YouTubeでTikTokを観るくらいは（その逆を防ぐ仕組みさえあれば）良いんじゃね、的な
個人的な感想、というか、普通にこれを引用すれば良い話だった：
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#activities
> When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type.
https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#extensibility
> implementations that rely too heavily on the use of extensions may experience reduced interoperability with other implementations.
（というかmulti-typeなオブジェクトは普通にMUSTな要件で言及されているレベルの事柄だったな）
