@gimlet_202411 @tell_me_fedi_jp
こちらのページに"Appeal a block decision"というリンクがあります：
Moderated Servers • Threads
https://www.threads.net/moderated_servers
ちなみにこのページからブロックされているサーバのリストも確認できますが（サーバ名に過激な表現が含まれているものも多いので要注意）、`misskey.vermilion3.xyz`は今のところ見当たりませんね

@darnell
> Also, running a PDS (Personal Data Server) is expensive, […]
The author doesn't say that PDSes are expensive. They even admit that PDSes are cheap:
> […], running a Personal Data Store is fairly cheap, because running a Personal Data Store is more akin to running a blog.
What they say is expensive is "relays" and "AppViews", akin to Google Reader, whose cost grow in proportion as the entire Bluesky network grows. And the problem is that Bluesky as social media utilizes an architecture the author calls "shared heap" that heavily relies on them.

ネットワークを横断した全文検索のような本質的に集約が求められる機能についてはともかく、それ以外の機能もメッセージパッシングでなく"shared heap"によって実現するアーキテクチャなのはいかにもTwitterの代替としての設計という感じである

まあネットワーク全体の情報を把握している集約サービスの視点としてはリプライの通知なども自分達で行えるのにメッセージパッシングなんてやっていたら純粋なオーバーヘッドだしね。
あとサービス運用上の問題として、メッセージパッシングのような中小規模のノードに最適化された機能を足してしまうと、AppViewは本当にただのYahoo!リアルタイム検索のような立ち位置になってしまってユーザの囲い込みが難しくなるというのがありそうだけど、これも個人的にはうるせえ知らねえそんなのプラットフォーマーの論理だろという感想でしかないので、はい

それをいうとリレーも現状は土管のようなものと言えばそれはそうだけど、これは例えばfirehoseの利用に課金するなどの選択肢があるだろうし。
そうすると大規模PDSの`com.atproto.sync.subscribeRepos`をどうするのかとかが非自明な気もするけど

流石に`bsky.social` entrywayの`subscribeRepos`は塞がれているっぽいけど、今のところ`*.host.bsky.network`のは通るっぽい？（`websocat`で一瞬接続を試しただけだけど）
QT: https://fedibird.com/@tesaguri/113537193193889537 [参照]

Migrating bsky.social to Multiple PDS Instances (Nov 2023) · bluesky-social/atproto · Discussion #1832
https://github.com/bluesky-social/atproto/discussions/1832
> Account repos will, of course, be canonically hosted at the new hostname indicated in the DID document. repo events will be emitted from the canonical PDS host for the account, not from `bsky.social`; subscribe to the BGS firehose (`bsky.network`) to get all events from all accounts.

現状広告がないのとかは単に広告の出稿を受け付ける基盤が整備できていないだけなどの解釈も可能だけど、無料firehoseとかはいかにも赤字前提の段階のベンチャ〜感がある

This account is not set to public on notestock.

件の記事でも言及されていたけど、これとかもどうなるのだろうな。`*.host.bsky.network`にそういうデータをホストするのに課金するという話なのか`bsky.network`リレーや`bsky.app` AppViewでの受理に課金するのかで大違いな気がするけど

いや、既に後者のようなことをしようと思えば出来る力を有していることが問題なのであって、当座として実際にどちらになるのか自体は実はそこまで重要でないとも言えるのかも知れない

まあそれを言ったらMisskey.ioの「相互リンク」とかもそうなのだけど

まあAT Protocolの偉いところとして、PDSとAppViewの分離が成立していて、多くの公開情報についてPDSに置くのが最も自然になるようなアーキテクチャになっているという点はあると思う。
ミュートとかダイレクトメッセージのようにそうでないものがあるといのも事実だけど、例えば「相互リンク」のようなものはBlueskyだったら多分PDSに記すような設計になっただろうし

まあそれだけでなくブロックとかも全て晒す形になってしまっているわけだけど……

ActivityPods、気になってはいるのだけど、これが怖くて足がすくんでいる（？）
https://docs.activitypods.org/tutorials/deploy-your-own-pod-provider/#maintainance
> It is required to regularly compact the datasets generated by Fuseki, otherwise they may grow very large. Unfortunately, due to the extension we developed to handle WAC permissions, it is required to stop Fuseki, compact it and launch it again.

Fediverseでアイデンティティの可搬性が欲しいかというと、セルフホストという選択肢が現実的に存在するので絶対に必要というほどでもないとは思うけど、それはそれとして実装を乗り換えたくなったりあるいはドメインを喪失したりしたときに可搬性が高ければ便利だろうし、やはり普及しているに越したことはないのだよな

その観点に関連して、FEP-ef61 portable objectsの`id`のpathの形式は実装依存と認識しているけど、実装間の可搬性についてはどんなものなのだろう

個人的にDNSという仕組みをいまいち信用しきれていないけど、DID（と名乗っているものを含む）も今のところいまいち決定打に欠ける感じがするのだよな。
ブロックチェーン系はフットプリントの問題があるし、`did:key`はローテーション不能だし、`did:plc`はdecentralizedでないし

Fediverseについて言えば`did:key`間でMastodon方式の`Move`を行うという手もあるだろうけど。
あるいは`did:plc`にFEP-ef61のgatewayのノリでカスタムのディレクトリサーバを導入できれば良いだろうか

@silverpill I've never heard of `did:tdw`, but a self-certifying, key-rotatable and `portable` alternative to `did:web` sounds quite promising!

This account is not set to public on notestock.

This account is not set to public on notestock.

考えてみれば、リモートのオブジェクトの`id`を不透明な文字列として扱っているのをローカルのオブジェクトにも一般化すれば良いだけの話か。どうせクライアント側での署名を考えると特定のパスの形式を強制するのは難しいだろうし
QT: https://mitra.social/objects/01935ec0-ca11-2b5e-00a7-ab0dbafd534e [参照]

というかアクターがサーバの協力なしに脱出できるようになると「ローカル」と「リモート」という分類の意味するところすら変わりうるな

This account is not set to public on notestock.

いわゆるauthorized fetchで弾きたいようなアクセスはある程度の敵対的関係を前提にしたケースが多いと思うけど、公開オブジェクトについては許可リスト連合でもない限りはいくらでも迂回のしようがあるし、脅威モデルとしては「行儀良くアクセスしてくれる敵対者」という奇妙な存在が仮定に含まれるということになりそうだよなあ

This account is not set to public on notestock.

Bluesky PBCが消滅してもBlueskyを「セルフホスト」することが出来ると言われても、仮にBluesky PBCですら失敗したのだとすれば他に誰がリレーだのAppViewだのといったデカブツを世話できるのかという問題があるわけで、代替可能であることがどこまで嬉しいのかは疑問に思う。
これらは酔狂で持続的にセルフホストできるだけの細かい単位に分割できるようなアーキテクチャにはなっていないわけで

あと、自分の視界を確保する分には既知の人々のPDSを探してクロールするということも出来なくはないだろうけど（PLCの解決の問題をどうにかしてどうにかしたとして）、他人にリプライなどのアクティビティを届けるには相手が自分のPDSの存在を把握している必要があるわけだけど、この疎通の有無をこちらから確認するのは少なくとも現在の仕組みでは困難では。
現在は`bsky.network`が「公式」という権威をもって実質的に全てのPDS（あえて連合していないものを除く）から`com.atproto.requestCrawl`を受けて大域的なネットワークのクロールを実現しているものと理解しているけど、Blueskyが散り散りになった後にそのような権威が自明に存在しうるとも思えないし

勢いで「現在の仕組みでは」と書いてしまったけど、あるリポジトリの所有者がどのAppViewを使っているかクエリするための仕組みなんて将来的にも実現されるわけがないか。あるAppViewやリレーが`com.atproto.sync.subscribeRepos`しているホストの一覧くらいならまだしも

これ、Blueskyの崩壊とまではいかないまでも仮にモデレーションの方針の違いなどからリレーが分裂して、ユーザ層がある程度重複しつつも一致はしないネットワークに別れたりしたときに困らない？

例えばpixivのようなモデレーションの方針が相容れなそうな（偏見）プラットフォームがAT Protocol対応する際に独自のリレーを構えるようなシナリオを想像していたけど、ネットワークを別けるくらいならそもそもAT Protocolに対応する意義も薄いか

いや、同じlexiconを喋る複数のAppViewに分裂するならまだしも、独自のAppViewで独自のlexiconを喋る分には混乱はそこまで発生しないか？　いずれにせよあえてAT Protocolの上に実現する嬉しさがあるのかも微妙な気はするけど

そもそも一般にサービス提供者視点で（ユーザ視点でなく）AT Protocol上にサービスを作る嬉しさというものが何なのかあまり理解していない気がするな。
Blueskyのユーザ層を引き込めること……はリレーを別けたら微妙そう。Blueskyのモデレーションに相乗りできること……もリレーを別けたら意味ないな。「ナウなAT Protocolのサービス」という話題性……うーん？

This account is not set to public on notestock.

This account is not set to public on notestock.

なるほどなあ……

User: truncate remote user fields instead of rejecting (!4220) · Merge requests · Pleroma / pleroma · GitLab
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4220
> feld merged 3 months ago
3 months ago…?

This account is not set to public on notestock.

This account is not set to public on notestock.

Bridgy Fed、ブリッジ先のプラットフォームの字数制限まで文字数を切り捨てる処理で、分かち書きを前提にして最後の空白文字まで切り捨て（るようなライブラリを使用し）ているっぽくて、日本語の扱いが怪しい。
例えばこれとか：<https://atproto-browser.vercel.app/at/did:plc:lffon5yhpjy26636i2xjl6as/app.bsky.feed.post/3l7eq6tlwdcq2>

https://github.com/snarfed/granary/blob/3245c42f9159da78ef411cca160341eb904f3abd/granary/source.py#L916
https://github.com/kylewm/brevity/blob/445f55c0f4c91bb76e38ce59cf653dbc3b24bdf3/brevity.py#L25

しかしBridgy Fedの"original post"は`id`でなく`url`なのか。リンクアグリゲータ系の実装で`url`がオブジェクト自身のHTML表現でなくリンク先を指すような例があったりするから、上手く動かないことがあってもおかしくなさそうだな。
しかし`id`は`id`でコンテンツ交渉に応じてActivity StreamsでなくHTML表現を返してくれる保証もないしなあ。HTMLを返さない例としてThreadsがある

https://www.w3.org/TR/2017/REC-activitystreams-vocabulary-20170523/#dfn-url
まあ`url`プロパティの"Identifies one or more links to representations of the object"という定義に照らせばリンクアグリゲータ等の慣習の方がおかしいと言えそうだし、そこまで気にしなくても良さそう？

しかし`Link`型を定義するくらいなら`url`プロパティもはっきりとRFC 8288のlink relationを示すものとして定式化しておけば良かったのにと思わないでもない。JSON Activity Streams 2.0の前身であるAtomでも`<atom:link>`で`url`相当の機能を実現していたわけだし

この辺りの定義がはっきりしていたらリンクアグリゲータとかだってきちんと`"rel": "about"`などを使っていただろうに（ホンマか？）

`url`プロパティを使う慣習というのはMbin（というか/kbin）を指してのことだったけど、LemmyやPieFedでは`attachment`に`Link`を入れる方式っぽいな。というかMbinでも`url`に加えて`attachment`でもリンク先を参照している

Announcing AT Protocol Grants | Bluesky
https://docs.bsky.app/blog/atproto-grants
重要なのを忘れていた。グラントもあるのだった。資金力〜

This account is not set to public on notestock.

Akkomaには連絡が行っていなかったのかな……

This account is not set to public on notestock.

https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/#extensibility
> Consuming implementations that encounter unfamiliar extensions MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present.
これなあ

AT Protocol、"big world with small world fallbacks"とか書いてあったからてっきり将来的にはメッセージパッシング的な仕組みの併用も想定しているのかと思っていたら、「Blueskyは既に分散しているよ！」と言い切られてびっくりしてひっくり返っちゃったよね（？）

This account is not set to public on notestock.

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

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

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

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.
これについては既に修正済みらしいとはいえ、なかなか衝撃的だな……

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

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

This account is not set to public on notestock.

This account is not set to public on notestock.

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

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

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

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

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

This account is not set to public on notestock.

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

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

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

> 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サーバに同じ操作を登録して回ればどうにかなる……か？

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

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

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

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

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

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

$ 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"
}

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

というかBridgy Fedさん、削除されたと認識した投稿のログを公開のdashboardに正直に表示し続けないでいただけるとありがたいのですけど……

This account is not set to public on notestock.

円が安くて買うタイミングを逃していたけど、どうせ他にちょうど良い機会もないだろうから、そろそろ買おうかなあ

まだセキュリティキーを持っていないのに、何故か鍵のバックアップを保管するための小型金庫だけは用意済みだったりする（？）

小型金庫なんてあったってどうせ5ドルのレンチで殴られたら全ておしまいなのにな（？）

昔は200ビット前後の鍵空間のランダムなパスワードを暗記で運用したりしていたので（？）、Curve25519の秘密鍵くらいなら何とか暗記でいけるか？　忘れた時のリスクが大きすぎるし、いずれにしても5ドルのレンチで殴られたらおしまいだけど

5ドルのレンチで殴られて256ビットの鍵を吐かされるの嫌すぎる

この利用できない添付ファイルを開こうとするとリダイレクトする挙動、ローカルのWeb UIで開くつもりがリモートのURLを踏むことになりがちで個人的に困るのだよな。ランダムなサーバに不用意に接続したくないので……（過敏）

https://atproto-browser.vercel.app/at/did:plc:o4s55v3tsfph6whswxccpsia/app.bsky.feed.generator/aaaixbb5liqbu
> Gift links or Gift Articles - paywall bypassing links to major publications.
こういうことをされるとパブリッシャーとしては困ったりしないのだろうか。
記事のギフト機能というのがどういう想定で運用されているのかよく知らないのであれだけど

This account is not set to public on notestock.

How Google helped destroy adoption of RSS feeds - Open RSS
https://openrss.org/blog/how-google-helped-destroy-adoption-of-rss-feeds#google-removes-rss-integration-from-google-news

FeedBurner、フィードにXSLTを付けてそのままブラウザに表示させていた面白サイト（？）という印象がある

YouTubeが中々しぶとくAtomフィードを提供し続けている（なんとPubSubHubbub/WebSubにも対応している）ので、Googleは一応まだ最大手のフィードのパブリッシャーの一つではあるのではとは思う

まあHTMLページには`<link rel="alternate" type="application/rss+xml">`とあるのに中身がRSSでなくAtomだったり、Atomフィードからの`<link rel="hub">`がなかったり、というか通常のプル型のリクエストに使えるフィードのURLとWebSubのトピックとしてのURIが何故か異なったり、WebSubのトピックの`<link rel="self">`が正しくないURIを指していたりと、色々と相互運用性が怪しい部分が多いけど

フィードの例：<https://www.youtube.com/feeds/videos.xml?channel_id=UCEOugXOAfa-HRmRjKbH8z3Q>（`<link rel="hub">`がない）
対応するWebSubトピック：<https://www.youtube.com/xml/feeds/videos.xml?channel_id=UCEOugXOAfa-HRmRjKbH8z3Q>（`<link rel="self">`の方からは`channel_id`パラメータが欠けている、`<entry>`がないのでプルには使えない）
cf. <https://developers.google.com/youtube/v3/guides/push_notifications>

> <!-- This is a static file. The corresponding feed (identified in the <link rel="self"/> tag) should be used as a topic on the http://pubsubhubbub.appspot.com hub to subscribe to video updates. -->
じゃあないんだよなあ。そもそもその`<link rel="self"/>`が間違っているわけで……

これの何が嬉しくないかというと、WebSubの規格に従ってトピックURIを`rel="self"`に正規化する（<https://www.w3.org/TR/websub/#subscriber-sends-subscription-request>）購読者側の実装が壊れる

YouTubeのWebSub周りの仕様については実体験として苦しめられたので早口で語れる（？）

まあ、変な実装でもそもそも何もないよりはマシではある……（embrace, extend, and extinguishの場合は除く……と言っても、そもそもPuSHを作ったのがGoogleなのだったっけ）。
PubSubHubbubなんて他に実装しているところもろくに見かけないしなあ。あってもBloggerとか、Amebaブログとかくらい……って、BloggerもGoogleたったか

あとWordPress.comとかもWordPressのWebSubプラグインを有効にしているのだっけか。セルフホストのWordPressではあまり利用例を見かけないけど