tesaguri 🦀🦝 @tesaguri@fedibird.com

> Other data transfer mechanisms, such as […] routed delivery of events (closer to "message passing") are possible and likely to emerge.
これが具体的に何を想定しているのか気になる

そろそろatprotoエアプのボロを誤魔化すのが厳しくなってきている気がするな（？）

> Technically, Bluesky PBC is still operating the PLC directory (we are actively exploring how to change this). However, […], so any retroactive manipulation would be observed and called out.
個人的にはBluesky PBCが初めから（retroactiveですらなく）上位のローテーション鍵によるPLC operationを存在しないかのように扱って下位のローテーション鍵で好き放題するシナリオを想定していたけど（元の記事の意図は知らぬ）、まあ現実的にはDIDコントローラがサードパーティのPLCサーバに同じ操作を登録して回ればどうにかなる……か？

元の記事が具体的にコストの計算を試みていたのがリレーのみであったのは、その更に引用元のセルフホストについての記事がAppViewまではセルフホストできていなかったことによるものだと思うけど、そもそもの参入障壁の問題の議論はAppViewを含めたものなので、リレーのコストだけを云々してもあまり本質的でないように思う。
というか問題はネットワークの全体を集約する必要があることなので（記事では"The ability to scale-down atproto"について述べられているものの、ここではリプライの到達可能性等のために必要と仮定する）、共時的な具体的コストについて論じても仕方ないのでは。Non-archival relayにしてもスループットには比例するだろうし、AppViewに至ってはストレージコストは増大し続けるだろうし（それとも将来的にAppViewもnon-archivalとか言い出す？）

元の記事ではshared heapの性質として特にリプライに関して"no directed delivery"であることを述べていたわけだけど、この記事はそれに対する答えになっていないように思う。
リプライを送る・受け取ることを必須の要件としないならばそりゃRFC 9518の要件を満たすかも知れないけど、流石にそれは暗黙の仮定として受け入れるには無理があると思うので少なくとも陽に言及されるべき論点かと思う

Reply on Bluesky and Decentralization | bryan newbold | WhiteWind blog
https://whtwnd.com/did:plc:44ybard66vv44zksje25o7dz/3lbvbtqrg5t2t

いやまあ、ユーザ視点で求められているのだとすれば前向きに検討するべきなのだろうけど、それはそれとしてこういうグロー〜スハック的な施策はプラットフォーム都合に偏らないか注意が必要そうだよね

そもそも他人のおすすめアカウントの一覧みたいなものから一括でフォローされても洒落せえと思ってしまいそうなので……（？）。他人のおすすめを参考にするにしても、せめて1件ずつ自分で吟味せんかいと。
Fediverseの場合はフォローの承認（自動で承認しない場合）や配送の負荷もあるわけだから、不必要にフォローを増やす方向にUXを設計するものでもない気がするし

コレクションへの追加の同意については、うーん、考え始めると正直面倒くさそうだけど、どうせActivityPubの上でやるならそれに類する仕組みがあっても良さそうという気もしないでもなく

それだけだと一般のコレクションと「スターターキット」を区別しづらいだろうから、個人的にはthisismissem氏やa氏が提案しているように`StarterPack`なり何なり的な固有の型の指定を加えた方が良い気がしているけど

書こうと思ったら自己解決されていた。ちなみに連合上の仕様としては単なる`Collection`とするつもりらしい：
https://github.com/pixelfed/starter-kits

って、改めて確認してみたらFedibirdも似たようなものだな……。もしかしたら最新のMastodonでは改善されていたりするのかも知れないけど

ざっと眺めてみたら、視覚上は表示されているリポスト・引用数が先祖要素の`aria-label`で上書きされて聞き取れなくなっていて、"No ARIA is better than Bad ARIA"（<https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/>）を思い出すなどした。
いや、リプライやいいねなどの他のボタンはその辺り配慮されているっぽいので、リポストボタンが単に漏れただけかも知れないけど

Voiceover issues on web · Issue #6116 · bluesky-social/social-app
https://github.com/bluesky-social/social-app/issues/6116
https://atproto-browser.vercel.app/at/did:plc:wlv2lek2tmwsfpob3r4mix7y/app.bsky.feed.post/3la6ddlhopv2u
https://atproto-browser.vercel.app/at/did:plc:wlv2lek2tmwsfpob3r4mix7y/app.bsky.feed.post/3la6dgj3ujd2k
> All the buttons for quoting, replying, retweeting, liking are all divs. Not even a `role="button"` in sight.
これについては既に修正済みらしいとはいえ、なかなか衝撃的だな……

というのも、私自身も理解が滅茶苦茶曖昧なので……（？）

私が「AT Protocolは素直でない」と評するとき、それは必ずしも素直でないことが劣っていることを含意するものとして述べているわけではないのだけど、AT Protocolのもたらす保障……というか何を保障し*ない*かについての人々の理解が曖昧そうなまま漠然と「分散型SNSプロトコル」として受け止められているあたりは普通に弊害が大きいと思っている
QT: https://fedibird.com/@tesaguri/113506622239236636 [参照]

いやまあ、"modeled after the open web itself"と言ったときの"web"に普通Webmentionのような仕組みを含めるかと言われたら確かに微妙ではあるかも知れないけど、それを言ったらコメント欄を外部のサービスに頼るようなブログというのもなかなかないわけで……