@silverpill I've never heard of `did:tdw`, but a self-certifying, key-rotatable and `portable` alternative to `did:web` sounds quite promising!
@silverpill I've never heard of `did:tdw`, but a self-certifying, key-rotatable and `portable` alternative to `did:web` sounds quite promising!
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
考えてみれば、リモートのオブジェクトの`id`を不透明な文字列として扱っているのをローカルのオブジェクトにも一般化すれば良いだけの話か。どうせクライアント側での署名を考えると特定のパスの形式を強制するのは難しいだろうし
QT: https://mitra.social/objects/01935ec0-ca11-2b5e-00a7-ab0dbafd534e [参照]
というかアクターがサーバの協力なしに脱出できるようになると「ローカル」と「リモート」という分類の意味するところすら変わりうるな
このアカウントは、notestockで公開設定になっていません。
いわゆるauthorized fetchで弾きたいようなアクセスはある程度の敵対的関係を前提にしたケースが多いと思うけど、公開オブジェクトについては許可リスト連合でもない限りはいくらでも迂回のしようがあるし、脅威モデルとしては「行儀良くアクセスしてくれる敵対者」という奇妙な存在が仮定に含まれるということになりそうだよなあ
(自律しろ)の投稿
fono@ma.fono.jp
このアカウントは、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のサービス」という話題性……うーん？
このアカウントは、notestockで公開設定になっていません。
このアカウントは、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…?
このアカウントは、notestockで公開設定になっていません。