tesaguri 🦀🦝 @tesaguri@fedibird.com

どちらかというと後者のRedoclyの方が食っていたっぽいかな

FirefoxとThunderbiredくらいしか開いていないのにメモリ不足になって何事かと思ったけど、Misskey Hubや<https://misskey.io/api-doc>を閉じたら2 GiBくらい空いた（？）

あと、どう取り繕っても悪口みたいになってしまうけど、Misskey APIの命名は全体的に英語として理解しづらいがち。
例えば今言及した`MiNote`エンティティも、他のプラットフォームでは`inReplyTo`とでも呼ぶであろう概念を単に`reply`という名前で指していたりするし……（単に"reply"というと、素朴にはそのノートに対して返信している他のノートのことのように思えてしまう）

あと返信が1件もないときにも"Show replies"が表示される仕様も混乱しがち。いや、`GET notes/show`を呼んだときに`repliesCount`が`0`だったとしても後から`GET notes/children`を呼んでみればリプライが生えていることもそりゃありうるだろうけどさ……

他人からのリプライについてはともかく、なぜ自己リプライ・スレッドまでワンクッションの操作を挟む仕様なのか気になっている表示も何か小さいし

AT Protocol（というか`app.bsky.*` lexicon？）の性質を考えればオプトアウトの方が馴染むというのは総論として同意だけど、`!no-unauthenticated`セルフラベルやリプライ制御と、（特にアカウントの所有者本人によってセルフホストされた）他のブリッジとの重複への対応をどうするのか気になるな
QT: https://fedibird.com/@tesaguri/113265667860530240 [参照]

Switch Bluesky to opt out? · Issue #1471 · snarfed/bridgy-fed
https://github.com/snarfed/bridgy-fed/issues/1471

ここでの「ローカル」とは、フォロイーのサーバがフォロワーのサーバに直接アクティビティを配送して、フォロワーのサーバがそれを`inbox`コレクション（あるいはMastodon API等における相当物）にまとめるという二者間通信を基本とするActivityPubの世界観を念頭に置いた上での、「グローバル」の対義語としての表現のつもり。
「リモート」の対義語と紛らわしいので、「大域的」／「局所的」とでも言った方が良かったかも知れない

というかフィードのエントリをメッセージフィルタで分類するのは今までもやっていたことだけど、この通知の仕様は以前からあったものだったっけ

フィードリーダとしてのThunderbirdが新着エントリを通知してくれない（<https://bugzilla.mozilla.org/show_bug.cgi?id=261841>）のが今までの悩みどころだったけど、どうもメッセージフィルタでエントリをフォルダに移動すると通知が発火してくれるらしいので、これなら実用上は問題なさそう

`com.atproto.sync.subscribeRepos`（<https://github.com/bluesky-social/atproto/blob/ee0e6356df1bcc2dc935988567632fa37d05284b/lexicons/com/atproto/sync/subscribeRepos.json>）とかも、見たところPDS全体でなく個別のリポジトリのみを購読するようなことは出来ないようで、いかにもリレー専用メソッドという感じである。
`com.atproto.repo.listRecords`のポーリングで代用できなくもないだろうけど

AT Protocol、もうちょっとWebSubとフィードアグリゲータに近い感じの世界観だったら好きになれただろうにと思っている。
というか今からでもWebSubと（セルフホストの）フィードアグリゲータをもっと流行らせません？（？）

全てが無料でないというのは当然のコストとしても、自己負担で良い感じに慎ましく自己統治する選択肢に乏しいのが問題だと思っている。PDSはセルフホストしたところでリレー・AppViewレベルの検閲からの自由を得られるような代物ではないし、リレー・AppViewも自分の必要な範囲だけで慎ましく運用できるような代物でもなければ、運用したところでやはりオーディエンスが着いてこなければどうしようもないことに変わりはないし。
ホームタイムラインの構築のような、（自分が選んだユーザ以外の情報のインデックスを必要としないという意味で）ローカルで基本的な体験までもがグローバルビューの集約と同一レイヤーによって担われているせいで、結局リレー・AppViewという強力なネットワーク効果を握る存在から逃れられないのではと思っている

まあクローリングや、場合によっては集約も含めた面倒くさい部分を避けてつまみ食いでハックできるのは開発者体験としては魅力的ではあるのだろう。
一方でその誰も実装したくないリレーやらAppViewとかいうやつがいつまでもfirehoseやその他のインタフェースをunensh*ttified（？）かつ無料で提供し続けてくれるのか甚だ疑問だけど

AppViewの運用というものにはグローバルビューの集約という劇重責務が付き物であることから、気軽に実装して運用できるような代物でないという構造的なインセンティヴの問題はあるかも知れない

AT Protocolのサービスといっても、単なる"Sign in with Bluesky"レベルのものやbsky.appの代替Webクライアントの見分けが付きづらいのが困る。いや、それこそが意図して設計された「機能」なのかも知れないけど

例によってPLCについては考えないものとする（？）