tesaguri 🦀🦝 @tesaguri@fedibird.com

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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

@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.

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