新しいものを表示

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

スレッドを表示

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

スレッドを表示

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

スレッドを表示
tesaguri 🦀🦝 さんがブースト

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

スレッドを表示

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

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

スレッドを表示

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

スレッドを表示

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

tesaguri 🦀🦝 さんがブースト
tesaguri 🦀🦝 さんがブースト

FediverseにはBlueskyにおける「スターターパック」に相当するものはありますか?

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

スレッドを表示

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

スレッドを表示

Voiceover issues on web · Issue #6116 · bluesky-social/social-app
github.com/bluesky-social/soci
atproto-browser.vercel.app/at/
atproto-browser.vercel.app/at/
> All the buttons for quoting, replying, retweeting, liking are all divs. Not even a `role="button"` in sight.
これについては既に修正済みらしいとはいえ、なかなか衝撃的だな……

というのも、私自身も理解が滅茶苦茶曖昧なので……(?)

スレッドを表示

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

tesaguri 🦀🦝  
リポジトリの購読までは"small world fallbacks"で解決できても、例えばリプライの存在の通知といったレベルの"reach"ですらAT Protocolのアーキテクチャでは恐らくネットワーク全体の集約に依存せざるを得ないので、これもかなら極端な設計と言えるかも知れない。 <...

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

スレッドを表示
tesaguri 🦀🦝 さんがブースト

"bluesky is not yet decentralized" it is! anyone can move their data to their own server. it requires some technical expertise right now, but we'll make this process easier. and we expect other companies to offer this as a service too — so it won't require technical expertise in the future

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

古いものを表示
Fedibird

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