その点 bluesky は bsky.app / bsky.social のサービス名だしソフトウェアは @atproto/pds なのでちょっと分離してる
その点 bluesky は bsky.app / bsky.social のサービス名だしソフトウェアは @atproto/pds なのでちょっと分離してる
このアカウントは、notestockで公開設定になっていません。
マイクロブログばっかり読んでるとマイクロブログに文章が最適化されるよなあ。今読んでる『天才による凡人のための短歌教室』って本に「いっぱい歌集を読んで短歌を頭にインストールしろ」みたいなことが書いてあったし、つまりそういうことだろう。
BlueskyがうまくやればATP上で拡散しやすいサービスになるだろう
現状のMastodonは拡散に弱い
ActivityPubじゃダメ←いいえ
今日までGroup actorを有効に使う実装が生まれてなかっただけでプロトコルの欠陥のような評価をされると技術評価としては変でしょ。そういうのはMastodonを批判してくれ
APでだってGroup actorやそれこそ同じ名前のリレーで拡散することはできなくはないしみたいな
アーキテクチャとして旧BGSのリレーが存在することで拡散しやすく見えるって話だとは思うけどAPに対するATPの優位性で語るにはレイヤーが違うよねって感じ
今のAPより狭いはその通りというか元が単一世界のところで実験的に連合させてるだけでまだ開放されて自由ってわけじゃないので
atproto.com lexicon の describeRepo でホワイトリストのサーバーが返した時だけ取得する感じになると思う
ホワイトリストにplc.directoryから取得したatproto endpointが含まれてたら取得するとかになるんじゃないかしら
いまってdiscordで許可を得れば連合できる認識なんだけど、野良でPDS建てて連合してなくてもそれいけるの……？
gitのshallow cloneみたいな仕組みがあるかはわからないけど普通に取得したらツリーの完全取得なのでむしろAPよりは抜けがなくなる
did:plc に対して endpoint で相手のサーバーを知ることができて、それは git repository みたいにマークルツリーで遡れるのでクローンすれば完全なデータが手に入るよ
PDSから引っ越すのだってFederationしてるものに限るんじゃないかな Federationしてないものにどうデータ渡すんだって話になるし
拡散する対象もFederationしている範囲に限るから下手したらAPより拡散しないよね
どうせデータの持ち出しの今想定されてるアーキテクチャ、ほとんどの人間がフローをちゃんと理解できなくて鍵の管理もできなくてうまくいかないでしょの気持ちがあるよ
技術で可能になることとユーザーへの見せ方とユーザーの使い方を誘導する力はBlueskyの方がMastodonよりうまいとは思うけど
ATPが明確に優位性持ってるのデータの持ち出しぐらいで他はAPでだって技術的に解決可能な問題じゃない？本当にATPだから出来ることなの？みたいな気持ち
サーバーを跨いでやるの分散型だけど拡散しやすいほんまか？ATPそこまでか？となる
