This account is not set to public on notestock.

AppView実装という意味ならBlueskyの他にWhiteWindやFrontpage、Linkatなどがあるから、「ATProtoの実装はBlueskyしか存在しな」いはフェアな表現でないように思う。
PDS実装としてもarroba（Bridgy Fedのsnarfed氏がメンテナンスしているやつ）などがあるけど、可搬なデータ形式を共有する以上はPDS実装による違いというのは実際のところ多分そこまで重要でない。違いがあるとしてもXRPCメソッドの実装詳細などの細かい差異くらいだろうか。
で、分散という観点においてより重要であろうリレーについては……知らんｗ（？）

「bsky.socialに一極集中」については、BlueskyとBridgy Fedを除いたPDSのアクティブユーザ数は、ええと……約0.027%？（<https://blue.mackuba.eu/stats/>）

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

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

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

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

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

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

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

@aumetra I think OStatus was fine enough, except for lack of native support for private posts and manual approval of follows (and, uh, proper documentation). That has been making me wonder if WebSub would've been actually a nice fit for AT Protocol, that doesn't support private posts either (Bluesky's direct messages aren't quite integrated into the protocol AFAICT)

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

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

This account is not set to public on notestock.

This account is not set to public on notestock.

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

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

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

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

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

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

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

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

First draft of ActivityPub HTML Discovery report from Evan Prodromou on 2024-11-16 (public-swicg@w3.org from November 2024)
https://lists.w3.org/Archives/Public/public-swicg/2024Nov/0041.html
ActivityPub Discovery
https://swicg.github.io/activitypub-html-discovery/