このアカウントは、notestockで公開設定になっていません。

テレスクリーンじゃん（「1984」以外の喩え方を知らない人（未読））

「Xのアルゴリズム」は数日であなたの政治的意見を変えられる――米スタンフォード大が1000人以上で検証：Innovative Tech - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2412/09/news046.html

標準のC2S APIが普及したとしても、現状のActivity Streamsの枠組みだと受信者側でのコンテンツのフィルタリングが曲者そう。

現状でも`Note`と`Article`といった区別くらいはあるけど、例えば`Video`に加えて「ショート動画」のようなものは当然ながら標準では用意されていない。この例ではヒューリスティックに判定という手もあるかも知れないけど、そんなどのクライアントで何が見えるのかはっきりしない環境で発信者・受信者ともに嬉しいのか微妙そう。`"type": "ex:ShortVideo"`のようにアドホックな拡張型を用意する手もあるけど、今度はショート動画とその他の動画の区別を気にしないような受信者との互換性が問題になる。いずれにしても中央集権プラットフォーム（やAtmosphere）のように「ショート動画」が満たすべき解像度等の要件の合意を成立させるのは困難そう。

（ちなみにこういう場面で`"type": "ex:ShortVideo"`の対案としてよく提案される解決策として、`"type": ["Video", "ex:ShortVideo"]`のようないわゆるmulti-typeなオブジェクトがある）

ところでvidzyはどうしているのだろうと思って見てみたら、何じゃこりゃ……

https://vidzy.pythonanywhere.com/activitypub/actor/1

AT Protocolでは割と積極的にAppView固有の語彙を作る風潮がある気がするけど、lexiconに対して少数のAppViewのみを想定したAtmosphereと比較して多様な独立した実装間の相互運用を尊んでいそう（ホンマか？）なFediverseにおいてはそこまでの割り切りは馴染まなそうというのが個人的な感想。

読書とアニメ視聴記録というユースケースがあるなら`my.skylights.rel`と`app.netlify.aniblue.status`を作るのがAtmosphereだとすれば、「作品とその閲覧と評価」のような共通項を見出して共有できる語彙は共有するのがFediverseっぽいというか（実際には例えばBookwyrm拡張は「本」しか想定していなそうだけど（`inReplyToBook`とか）……まあ、あくまで概念的な話として、はい）。

TwitterクライアントでRedditは見たくないけど、YouTubeでTikTokを観るくらいは（その逆を防ぐ仕組みさえあれば）良いんじゃね、的な

どうでも良いけど、`app.netlify.aniblue`ってびっくりNSIDだな。実際にそれでも困っていないのだろうけど、将来的にlexiconの解決とかが策定されたときにどうするのかとかは気になる。例によってatprotoエアプなので知らんけど

まあ何はともあれまずは成熟した汎用ActivityPubサーバが欲しいよなあ。実際のサーバを用意する前からあれこれ課題を想定するより実際に運用して問題にぶつかる方が楽しいだろうし（？）

欲しい欲しいと言うだけではなくてだな……はい

個人的な感想、というか、普通にこれを引用すれば良い話だった：

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な要件で言及されているレベルの事柄だったな）

いつでも内容が書き換わる可能性のある実際のサーバのオブジェクトへのリンクよりも、対応するソースコードへのリンクを張るべきだったな：
https://github.com/vidzy-social/vidzy/blob/1068f64f1264ebd0b8252d27b2ee4028790b19c7/app.py#L880-L906
QT: https://fedibird.com/@tesaguri/113773137545779149 [参照]

そういえばLoopsも`loops.video`上の1アカウントだけ連合を開放しているのだったな：

https://loops.video/v/2hltW5wx00

何の変哲もない`Note`だ（あと`Video`） [参照]

https://www.w3.org/TR/2018/REC-activitypub-20180123/#client-to-server-interactions
> If an Activity is submitted with a value in the `id` property, servers MUST ignore this and generate a new `id` for the Activity.

以前から思っていたけど、これ、クライアントサイドの署名と致命的に相性が悪いよね。実際FEP-ae97（Client-side activity signing）ではあえてこれを破っているし（<https://w3id.org/fep/ae97#sending-activities>）

しかしActivityPubが既存のWebサイトに適用するユースケースを重視している以上はサーバ実装固有のHTML表現のURL形式に引っ張られるのは避け得ないよなあとも思う。

いや、正確に言えばHTML表現のURIとActivity StreamsオブジェクトのURIの間で紐付けさえ出来るならAS側のIDがHTML側のURLと一致している必要はないだろうけど、いずれにしてもHTML表現のURLを`url`などでASオブジェクトから指したいことには変わりないし。……今からでもこの役割をWeb Linkingあたりに押し付けられません？（？）いや、これが署名の対象にならないのはやはりまずいか

雑に推敲しているうちにHTML表現の"URL"と"URI"が表記揺れしてしまった

ジャーナル ↔︎ be炊飯器