新しいものを表示
+
tesaguri 🦀🦝

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

1
+
tesaguri 🦀🦝

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

スレッドを表示
0
+
tesaguri 🦀🦝

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

スレッドを表示
1
+
tesaguri 🦀🦝

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

スレッドを表示
1
+
tesaguri 🦀🦝

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

1
tesaguri 🦀🦝 さんがブースト
+
ふぉの :inkan: :sabakan: (自律しろ)

Blueskyも、Blueskyというフロントエンドが死んでも誰かが立てれば良いという側面があるので、それらすべての対応実装が死なない限り死んだとは言い切れないという問題が

1
+
tesaguri 🦀🦝

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

1
tesaguri 🦀🦝 さんがブースト
+
洪 民憙 (Hong Minhee)

Hot take: It is bad that #ActivityPub software implements #AUTHORIZED_FETCH, also known as secure mode, because, contrary to its name, it does not actually contribute to security and instead gives a false sense of security.

swicg.github.io/activitypub-ht

1+
+
tesaguri 🦀🦝

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

スレッドを表示
0
+
tesaguri 🦀🦝

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

silverpill  
@tesaguri The path component is a so called "opaque string". It is supposed to be implementation-independent and shouldn't be tied to routes used b...
スレッドを表示
1
tesaguri 🦀🦝 さんがブースト
+
silverpill

FEP-ef61 should be compatible with other DID methods.

did:tdw is one of those candidate methods: it is similar to did:web (supports rotation), but DID document can be migrated to a different domain.

1
tesaguri 🦀🦝 さんがブースト
+
silverpill

The path component is a so called "opaque string". It is supposed to be implementation-independent and shouldn't be tied to routes used by web application.

(How well that works in practice remains to be seen.)

0
+
tesaguri 🦀🦝

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

スレッドを表示
1
+
tesaguri 🦀🦝

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

1
+
tesaguri 🦀🦝

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

スレッドを表示
1+
+
tesaguri 🦀🦝

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

1
tesaguri 🦀🦝

ActivityPods、気になってはいるのだけど、これが怖くて足がすくんでいる（？）
docs.activitypods.org/tutorial
> 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.

0
+
tesaguri 🦀🦝

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

スレッドを表示
0
+
tesaguri 🦀🦝

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

1
+
tesaguri 🦀🦝

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

スレッドを表示
0
古いものを表示
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。

トレンドタグ

リソース

開発者向け

Mastodon とは？

fedibird.com

さらに…