個人的には「グローバルビューがないことはむしろ利点」という意見にも正直賛同できないのだけど（現状は単に検索エンジンが欠けているだけという偶有的な要素も強いので）、それはそれとしてAtmosphereの何でもオープンで`noindex`的な意思表示の手段すらない状況は極端だなとも思う

個人的には、`toot:indexable`よりもう少し柔軟な意思表示の仕組みを整備した上でまともな検索エンジンが発展すると良いですねというくらいの気持ち。
というか、`toot:indexable`の存在とFediverse Discovery Providersの計画を踏まえればある程度のものは現実的に実現されうるように思うけど、件の記事がこの辺りに言及していないのは考慮漏れかな

「BlueskyがActivityPubを採用しなかった理由」の技術的な側面については頑張ればある程度所望の要件を満たすことが出来たであろうものも多いので（「グローバルビュー」はdiscovery provider、「アカウントポータビリティ」はnomadic identity、「スケーラビリティ」は……自明な対応物はないけど、通信プロトコルとしてのActivityPubはともかくデータ形式としてのActivity Streamsは使う余地があったはず）、これらは理由としては表面的なものに過ぎなくて、さらに突き詰めるなら既存のActivityPubエコシステムを改善する道を選ばなかった理由まで検討する必要があると思う。
まあそれをやったらやったで仕様を擦り合わせる政治的コストが高い上にEEEの誹りを受けるのがオチだったと思うけど……（はい）

というか「分散型SNSでは一度投稿した内容を消せない」というのをActivityPubの問題であるかのように語っているけど、その点ではむしろdata repositoryのレコードの否認不可性を強制するAT Protocolの方が深刻では（否認不可性自体は必ずしも悪いものではないけど）

これは禁止カードだから（？）使うのを躊躇っていたのだけど、`did:plc`の中央集権性の改善はいつになるのですかね？（「アカウントを移行させるためには、元のサーバー管理者の協力が不可欠」というActivityPubへの批判が数倍の威力で跳ね返る）

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

（さんざん批判的なことを書いた後に拡散するのも申し訳ないけど、たった今見つけてしまったので……）

元は「BlueskyがActivityPubを採用しなかった理由」の話だからBlueskyが技術選定を確定させた当時の状況で考えるべきか。うーん、それなら`toot:indexable`の実装開始が2023年2月（<https://github.com/mastodon/mastodon/pull/23808>）で、ADXの公開が2022年5月（<https://bsky.social/about/blog/5-4-2022-working-in-public>）だから、まだ状況が不安定だった時期か

`id`がDIDなオブジェクトはFEP- ef61で提案されていて、実際に実装しているプロジェクトもある（<https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md>）。
DIDsからActivityPubのアクターの解決についてはエンドポイント（gateway）を手動で指定する方式のようだけど

「アクターの解決」というか、一般のオブジェクトの解決も含むな

件の記事はBlueskyがActivityPubを採用しなかったという所与の事実を出発点に理由の説明を試みるという構成からして、Blueskyの設計目標とActivityPubのミスマッチを中心に論じることになるのはそれはそうなのだろうけど、多くの読者がそれを鵜呑みして一方的な感想を抱いているのがちょっと宜しくないなと

@Haru_nishi0101 検索から失礼します。Bridgy Fedを使ってBlueskyにブリッジされているものとお見受けしますが、その場合はノートの公開範囲を「ホーム」にするだけでもBluesky側に公開されることを防げます

連合がスケールしないとは言うけど、素人考えとしてはあらゆるPDSをクロールしてfirehoseを作る設計もかなり腕力任せではと思ってしまう

非中央集権やら分散といった「手段」寄りの表現を噛み砕いてその動機に還元するとすれば、ロックインやSPoFの排除のような要素が挙げられるだろうけど、そうすると現状のBlueskyの寡占性の何が嬉しくないか分かりやすくなるだけなのでやめた方が良いと思う（？）

というかポータビリティの欠如をもって中央集権化と呼んでしまうと連合しないセルフホストのサービスはみんな中央集権サービスになってしまっておかしなことになるので、それこそ普通に「ロックイン」で良かったように思う。
まあ「ActivityPubは中央集権的」という表現の方がインパクトはあるだろうけど

> 異なるタイプのソーシャルメディアが連合する場合は、一方のUIに合わせたコンテンツ配信が求められます。
これは現状のFediverseの説明としては正しくないな。例えばWordPressの記事のActivity Streams表現では普通に`content`に全文が含まれる：
```sh
curl -fLH 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' 'https://socialwebfoundation.org/2024/09/24/launch/' | jq '[.content, .summary]'
```
Mastodonの場合は`Note`以外のタイプのオブジェクトは要約表示にしている：
https://github.com/mastodon/mastodon/blob/66b2bc1c841d6ad59fe4961ff9f0075fa3e52d50/app/lib/activitypub/activity/create.rb#L88
つまり現状のFediverseの慣習としては発信者は全文と`summary`を配信し、受信者が必要に応じて表示を調整している。
例えばWhiteWind lexiconのレコードをBluesky AppViewが無視している（という認識で合っている？）ようなAtmosphereとどちらが良いかといえば、価値観の問題だろうけど [参照]

この話いつまで続けるんです？（？）（実際nitpickを始めるとキリがないな）

せっかく`Article`の`content`があるのだから、ページ遷移せずにモーダルウィンドウとかで良い感じに読めたら良いのだけど

> その結果、ユーザーの分布はパレート分布に近づきます。
Pareto則に従うこと自体は当然では……？　冪分布の裾野がしっかりと成立していそうなだけむしろ健全な部類のように思う。
……と思ったけど、`bsky.social`以外のPDSがホストできるアカウント数が10に制限されていることからPDSあたりのアカウント数の分布は冪分布にすらならないだろうから、確かにPareto則には従わないか（？）

いや、裾野の方はどうでも良いか。それを言ったらAtmosphereにおけるPDSあたりのアカウント数の分布なんて、ぺしゃんこな劇長尻尾の先にぽつんと`bsky.social`があるだけで裾が長いことになってしまうし。雰囲気で意味の分からないことを書いてしまった

私のドメインあたりのフォロー数の分布はこんな感じだった。まあ普通に冪分布風ですね（累積分布は面倒なので略（？））

しかしサードパーティのPDSを制限している状態でスケールする分散プロトコルでございという態度を取っているのがかなりアレだな。スケールする中央集権プラットフォームを名乗るならまだ許せた（？）

https://misskey.io/notes/9z3yj5qotpt508oc
Code fenceの言語名を雰囲気で雑に設定したものの、本当にこれで良いのかと思ってMisskey (.io)の表示を見たらcode fenceがまるまる無視されていて泣いた
QT: https://fedibird.com/@tesaguri/113271705336705080 [参照]

```test
test
```

https://misskey.io/notes/9z435va87nh404ii
うむ……