tesaguri 🦀🦝 @tesaguri@fedibird.com

何故ここでバリデーションエラーみたいなものを吐いているのか……

$ curl --fail-with-body -s -H 'Accept: application/json' 'https://atproto.brid.gy/xrpc/com.atproto.repo.listRecords?repo=did:plc:lffon5yhpjy26636i2xjl6as&collection=app.bsky.feed.post' | jq
{
"error": "InvalidRequest",
"message": "in com.atproto.repo.strongRef, string cid with value `''`: is invalid for format cid"
}

例えば、例えばの話だけど、特定の自治区の人々のアカウントが、いや、例えばの話なのですけど、集中的にtakedownされたとして、それでAppViewを移動したとしても出来上がるのは親パレスチナ派にしか投稿が届かないネットワークに他ならないであろうわけで、それはあまり嬉しくないよね、的な。モデレーションが厳しいMastodonサーバから移動するのとかとは訳が違う訳で

個人的にはタイムラインの構築もメッセージパッシングをデフォルトにでもしなければ、プラットフォームにオーディエンスを人質に取られることは避け得ないと思っているけど、まあこれは目的意識の違いと言われればそれまでである
QT: https://fedibird.com/@tesaguri/113555154115556875 [参照]

> Resilient small-world bsky AppViews could work by periodically polling specific accounts from their PDS and indexing relevant posts.
というかこれ本当にやって良い想定なのですか？　`com.atproto.sync.subscribeRepos`の個別リポジトリのみを購読するバージョンを用意しないなら私は本当にレートリミットの許す限りの頻度でポーリングするつもりだぞ、おおん？（？）

"ActivityPub can't scale (笑)"の根拠として大きいのは恐らくフォロワー数に比例して増える配送負荷のことだろうと思っていて、それならリプライ等の1対1のやり取りはメッセージパッシング方式にしてくれても良いのではと思っている。
それさえ出来ればタイムラインの構築等の他の機能も含めてネットワークの集約によらずどうにかする余地が生まれるだろうし

> 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