しかしコレクションのURIの指定を求めるとなると、対象のオブジェクトがそもそも該当するコレクションを持たない場合に表現が不能になるという問題があるか。
これはサポートしない操作を拒否できる能力という利点とも取れなくもないけど、現行の副作用を伴うあらゆる操作についてそのような能力の存在が嬉しいのかは疑問が残るな。例えばリプライ制御のユースケースのうち「あらゆるリプライの拒否」という意思表示についてはこの仕組みで自動的に解決されるとも考えられるけど、一方でデマの指摘のように宛先人が拒否することを承知でリプライを表明するということが不能になる。
まあこの例の場合はリプライでなく（コレクションへの追加を伴わない）「引用」でやりええという立場もあり得るか？ うーん
そもそも未知の拡張の副作用を扱えないことの何が困るかというと、拡張の可用性がサーバによる実装状況に依存することでサーバを透過的に扱いづらくなることだがあると思う。副作用がサーバによらず統一的に処理されたならば、拡張の解釈は送信側と受信側のクライアントの実装間の合意によって完結できただろうと考えられるので
特定のFEPの組み合わせであるアクティビティの副作用がTuring完全になる回（存在しない回）
毎度のJSONやめてバイナリにしたいだのMisskeyはMisskeyとだけ連合する方が幸せになる可能性があるだのの発言が実行に移されたためしは無いけど（失礼）、今回は文脈抜きで英語圏にまで拡散していてアレ
まあ今回のThe Fediverse Reportについては正直Hof氏の持論の引き合いに出されているという側面が強いような気がするけど
そういえばドイツにおけるgGmbhの立場を取り上げられていたのだったか
結びが「Join Mastodon.（`mastodon.social`のサインアップページへのリンク）」なのがいまいち締まらないな（？）
Today Mastodon is taking another step towards its founding ideals: independence and non-profit ownership. We're transferring ownership of key assets to a new, European not-for-profit entity, ensuring our mission remains true to a decentralised social web, not corporate control. #MastodonNonProfit
https://blog.joinmastodon.org/2025/01/the-people-should-own-the-town-square/
このアカウントは、notestockで公開設定になっていません。
winnow::_tutorial::chapter_0 - Rust
https://docs.rs/winnow/latest/winnow/_tutorial/chapter_0/index.html
チュートリアルが docs.rs にあるパターンなどもある
ブログをクレートにすることでサンプルコードに対してdoc testが実行できる！
の投稿
maia@crimew.gay
このアカウントは、notestockで公開設定になっていません。
かなり粗末な陰謀論だとは思っていたけど、実在のDittmann氏らしき人物が見つかっていたのか
の投稿
maia@crimew.gayこのアカウントは、notestockで公開設定になっていません。
の投稿
maia@crimew.gayこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
比喩を適切に調整するのが面倒だから不適切な喩えのまま書くと、これまで中央集権プラットフォーム残っていたような人々が求めるのが自由より統制された檻だったとしても別に突飛な発想ではないように思う。
発言を削除するのでなく文脈を付加する類のファクトチェックがそもそも検閲の定義を満たすのかについてはさておくとしても
「倫理的なWebの原則」と入力しようとして誤って「倫理的なWebのげんくそ」と入力してしまい全てがどうでも良くなった（？）
ブリッジへの言及があるけど、A New Socialとの関係はどうするつもりなのか気になる
本当に「検閲が無くなる」のだったらそれも一つのあり方だったかもしれないけど、実際に起こっているのはPixelfedなどの競合プラットフォームへの言及の規制だったりして、要はモデレーションは面倒だけど利益になると判断した検閲はなりふり構わず行っているだけなわけで……
ブリッジ、せっかくPDSがあってもブリッジのためのレコードしか書き込めないのでは正直面白味が微妙だけど、かといってActivityPub側の`outbox`に好き放題アクティビティを突っ込めない現状でAT Protocol側のPDSに好き放題レコードを詰め込めても仕方がないだろうしなあ
仮にAP側にまともにSocial APIを実装したとしても各種アクティビティとlexiconの間に割り当てるべき対応関係が非自明だし、というかPDSには`inbox`相当の仕組みが無いのでその違いの扱いもややこしそう
アイデンティティについても、真面目にDIDを共有したりしようとするとFediverse/atprotoの両者で合意できそうなメソッドが今のところ`did:web`くらいしかなさそうなのがまた微妙だな……
@kussy_tessy ははは、今は隠し機能っていうかテスト運用しかしてないんだけども、
フォローしてる人のアカウントカラムを最後まで遡ると、追加取得ボタンがあるよ。
これってFedibird固有の機能だったのか。いや、まあupstreamは<https://github.com/mastodon/mastodon/issues/34>がopenだし、それもそうか
このアカウントは、notestockで公開設定になっていません。
Misskeyのように`Like`をフォロワーに送りつけるフォロイーがいるのなら、愚直に実装するなら`inbox`にそれらの`Like`を貯めるのが正しいということになるのだよな。さながら旧TweetDeckのActivityカラムのような感じだろうか
ちょっと言葉足らずだった気がするけど、`inbox`に`POST`するのは今もごく当たり前に行われていることであって、それに対してここで想像していたのは`inbox`に対する`GET`への応答にそれらの`Like`を含めるといった挙動の話
FOFの<del>あの`margin: 0px; padding: 0px;`の謎レイアウトの</del>公開状にDoctorow氏が署名しているのがちょっと意外に感じたけど、氏は"there's *still* no fire exits on Bluesky"（<https://pluralistic.net/2024/12/14/fire-exits/>; 強調は引用者）という意見だったから、後は"fire exit"を追加するだけで良いという考えだろうか
というかpluralistic.net、場合によってJavaScriptとCookieを要求する？ ページを開くとdeflectなる何かが"Please turn on JavaScript and reload the page."などと表示してくることがある。"no ads, trackers, or data-collection"だったはずでは？（うるせえ）
ああ、最新の記事（<https://pluralistic.net/2025/01/14/contesting-popularity/>）で普通に"We can install our own fire-exits in Bluesky."と主張されているな
個人的にはshared pileをダブらせたところで独占が寡占になるだけで、一定の意義はあるものの根本的な解決にはならないように思うのだけど
みんなの手でshared pileをまとめる新しい郵便局を建てようというのは実に結構なことだけど、よしんばその郵便局の運営に「みんな」の意思が最大限適切に反映されたとしてそれはマクロな事象でしかなく、そのミクロな構成要素であるところの「私」の意思が有意に影響を及ぼせるとは限らないしなあ。結局は全体の意思が自分の意思と相容れなかったらお終いという問題は解消されない。
とはいえ現実の民主主義制だってそんなものだけど、別にこのインターネットの場においてまで国家の資源の集約と分配をモデルにする必要はないわけで。ここは物理的な距離に縛られないインターネットなのだから、郵便局なんて建てずに素直に相手の家の郵便受けに直接投函しにいけば良い
<https://dustycloud.org/blog/how-decentralized-is-bluesky/>は必読なので（？）、この記事で使われた"post office"などの比喩は特に断りなく流用するものとする
Bridgy Fedに微妙なところで打ち切られそうな文だなあと思いながら投稿していたのだけど、実際冒頭の"shared"の部分で打ち切られているな（<at://did:plc:lffon5yhpjy26636i2xjl6as/app.bsky.feed.post/3lfqgumo2gj42>）
QT: https://fedibird.com/@tesaguri/113829383265936570 [参照]
一人の金持ちによる支配というのは単なる（極端な）一例に過ぎなくて、本質的には金持ちだろうが合議だろうが関係なく、個人の制御が及ばないところに問題意識があるのかも知れない
"Pile"じゃなくて"heap"だったわガハハ（ｽﾞｺｰ）
Idea: Annotations / Labeling of content · Issue #4 · swicg/activitypub-trust-and-safety
https://github.com/swicg/activitypub-trust-and-safety/issues/4
既知の権威を購読するようなファクトチェックならまだしも、匿名の意見の集計の上に成り立つコミュニティノート的な仕組みは正直ActivityPubに馴染まないように思うのだよな
まあ中央集権的なサービスでも別に真に匿名でないことには違いないけど、かと言ってそこら辺のセルフホストのノードとそれらが同じかというと、少なくとも一般的な捉え方とは言い難いだろう。
というか非中央集権ネットワークでは自らが選択したノードとその他のノードではある程度信頼度が違って、一方で中央集権プラットフォームでは選択の余地がないだけでプラットフォーム自体が前者に相当する地位にあると言えなくもないだろうし
Blueskyのために作ったアカウントをそのまま他のAT Protocolのサービスに使えるというのはやはりonboardingの面で強そう。ActivityPubのエコシステムもC2Sのサポートがもっと普及していたらなあ（いつもの）
では例えばWhiteWindとかは実際どうなのかというと、ぱっと見atprotoオタクばかり集まっているような印象があるけど（失礼）。
旗艦のWebクライアントのトップページに集約した記事を並べられると、初期に形成された雰囲気のようなものから外れた記事を投稿しづらくなるみたいなところがありそう。丁度こちらでいうところの各サーバのローカルタイムラインのように。知らんけど
今はPixelfedが強そうだけど、今後どうなるのかね。私はInstagramも使ったことがないので個人的には特に関係ないけど
逆にまだPDSにアカウントを持っていない場合は……ここでBlueskyに誘導してonboardingに余計なステップを挟むことを厭ったAppViewの胴元が自前でPDSを用意したりすればPDSの分散のインセンティブになるか？ 知らんけど
PDSレベルのモデレーションに責任を持ちたい開発者がどれほどいるのかがアレかな（アレとは）
We just released Mastodon 4.3.3, 4.2.15 and 4.1.22. Tmastoadminn a few bug fixes as well as a security fix (medium severity, https://github.com/mastodon/mastodon/security/advisories/GHSA-5wxh-3p65-r4g6)
We recommend every instance administrator to update as soon as possible.
If you are using our nightly releases, a container image with the fix has been published with the `nightly.2025-01-17-security` tag.
Full release notes and update instructions are available on our GitHub release page: https://github.com/mastodon/mastodon/releases/
リリースノートで言及しているGHSAを公開状態にしてからリリースしてもろて
Partial Denial of Service due to insufficient validation of remote actors · Advisory · mastodon/mastodon
https://github.com/mastodon/mastodon/security/advisories/GHSA-5wxh-3p65-r4g6
このアカウントは、notestockで公開設定になっていません。
API v2から晴れて（？）"Tweet"が正式名称になっている。"Status"はもはやURLに名残が残っているのみ。
あーん、わざわざ`developer.twitter.com/en/docs/twitter-api`でリンクしたのにリダイレクトで書き換えられている（？）
このアカウントは、notestockで公開設定になっていません。
対応している拡張の交渉云々についてはこれに尽きると思っている
対応している拡張をサーバに宣言させるのはSocial APIをまともに実装した汎用のActivityPubサーバのようなものとも相性が悪そう（最近この話ばかりしているな）
大前提としてNodeInfoの`software.name`で何かを判断しようとするなというのはそれはそう
"ActivityPub"サーバとしては`inbox`に届いたアクティビティを概ねそのままクライアントに見せるだけであって、引用だのリアクションだのといったものに対してサーバレベルで特別な解釈をするとすればそれはActivityPubでなくMastodon API等のサーバに属する性質なのではないだろうか。つまり、NodeInfoより`GET /api/v2/instance`とかの領分な気がする（そもそもActivityPubはNodeInfoというプロトコルの存在についても特に認知はしていないわけだけど、それはそれとして）
fedibird:references のように副作用でコレクションに追加されるみたいな拡張機能であればまぁActivityPub拡張の対応等にはなるかもしれない
引用もリアクションも特にActivityPub上の副作用を持たないという想定で書いていたけど、そういえばFedibirdがいたな……
`fedibird:references`コレクションについては確かオブジェクトに付いた参照でなくオブジェクト自身が他のオブジェクトに対して持つ参照のコレクションだったから関係ないと思うけど、`fedibird:emojiReactions`コレクションは受け取ったリアクションが副作用として追加されるものだから、思い切り該当する
better service landing pages by bnewbold · Pull Request #2959 · bluesky-social/atproto
https://github.com/bluesky-social/atproto/pull/2959
プレーンテキストのアスキーアートはアクセシビリティが悪いからHTMLにしたほうが良いのではなどと横槍を入れていたものの、華麗にスルーされたね（？）
