このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

#fedibird ストリーミングがちょこちょこ切れる不具合が出ています。

以前に発生した現象と同じ様子ですが、原因がまだ判明していません。解消まで少々お待ちください。

#fedibird ストリーミング調整中です。たぶん今、連合流れない。

#fedibird ストリーミング、たぶんこれで直りました。

直近のEugenさんの配送の最適化コミットで処理順序が入れ替わり、改造しているFedibirdでは購読や連合のストリーミング配送のpayloadが空になってしまい、ストリーミングサーバがエラーになって、その都度再起動されるという現象でした。

ご不便お掛けして申し訳ございません。

@nonbiri

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

毎日エンバグ

風のリグレッション

デバイスだ……

特別送達とか受け取りたくないにゃん

@giraffe_beer てげどんかな

このアカウントは、notestockで公開設定になっていません。

んば〜

ウチもずっと エントマライフハック が張り付いてるね。楽しいからいいけど（そうじゃない）

きっとやきたまさんがなんとかしてくれる

てす

#fedibird 不具合で、一時Pleromaの投稿が詰まっていたかと思います。さっき解消させたので、突然大量い流れてきたかも……。

ActivityPubのCreateを処理する際に、conversationの処理にバグがあり、sidekiqで再試行に詰まれてました。

contextでした。（マージされてない開発中のコードの話です）

このアカウントは、notestockで公開設定になっていません。

ねむいのだわ

このアカウントは、notestockで公開設定になっていません。

【Mastodonサーバ管理者向け】サービス終了したサーバへの対応方法

たとえば、てげどんは今日の12:00に停止（サービス終了）したんで、もう配送しても届かない。そういう場合はこう。

bin/rails r "UnavailableDomain.create(domain: 'tegedon.net')"

これで、sidekiqに積まれているてげどん（tegedon.net）向けのActivityPub::DeliveryWorkerは何もせずに正常終了するようになって、自然に消えていくよ。

ほっといても概ね7日後にこの状態になるんだけど、すぐに適用したい場合は自分で登録しちゃえばOK。

UnavailableDomainに登録する方法の場合、単に配送しなくなるだけだから、既存のアカウント情報や投稿は削除しないので、負荷はかからないよ。

ドメインブロックしたり、tootctl domains purgeしてもいいけど、全部消そうとするから一時的に大きな負荷になるよ。

でもまぁ、容量を節約したり整理したいなど、いずれ消すつもりなら、思い切ってやってしまった方がいいかもね。

テレホタイムになったら一斉にリダイヤルしまくって、みんなで回線を取り合ってチャットするんですよ！（ところで何の話だろう）

このアカウントは、notestockで公開設定になっていません。

@nelsoncoffeeroaster 割り込まれたら即座に回線を奪われるので、また誰かが脱落する隙を狙ってリダイヤルし続けるんですよ！！

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

完璧じゃぁないか！

OK。よくわからん。寝て起きて考えよう。

夜を食べたのだわ

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

カリーブルスト的な何か

このアカウントは、notestockで公開設定になっていません。

ﾎﾟﾍﾟ

クソ、インフラエンジニアめ！

このアカウントは、notestockで公開設定になっていません。

@kiroha いまアプデしました！

#fedibird masterの変更点を2つご紹介（適用済み）。

リストにリプライを表示する方法を、リストごとに指定できるようになりました。

Glitch-soc（Mastodonのフォークの一つ）で長らくサポートされてきた機能の移植で、2018年の11月ぐらいから作成されていた古いPRが、ここにきて仕上げてマージされたものです。

・リプライを表示しない
・リストメンバーのリプライを表示
・全てのリプライを表示

となります。
https://github.com/tootsuite/mastodon/pull/9205

もう一つ。

ホームに、昔のように、自分自身のダイレクト投稿が表示されるようになりました。

あわせて、タイムライン上にダイレクト投稿が表示される際の、背景色のハイライトは行われなくなりました（他の投稿と同じ背景色に）。

ダイレクトメッセージのタイムラインはこれまで通りで、ホームに追加で表示されるようになった感じです。
https://github.com/tootsuite/mastodon/pull/8940

DMは、暗号化したメッセージ交換の仕組みと、サークル機能を作り始めてから、位置付けが変わってきており、今回の変更はその一環と思われます。

@squid999 こういうデザインもできるのか。すげえ。格好良いナース服だねぇ。

ちなみにアスタルテ（Glitchsocベース）ではこんな表示になっている。

Eugenさん、ことりこ大好きだね！

このアカウントは、notestockで公開設定になっていません。

@circledev サークル機能は、新しい仕組みの導入に踏み切って、次の段階に入っています。

サークルは、最初の投稿者が、自分自身で作成したサークル（フォロワーの中から選んだメンバーリスト）に向けて投稿します。

このメンバーリストは、最初の投稿者以外は誰も知ることができません。

サークル投稿への返信は、サークルのメンバーに配送したいのですが、これは最初の投稿者（のサーバ）にしかできません。

そこで、サークルへの返信は、最初の投稿者のサーバに委譲する仕組みを導入することとなりました。

通常のリプライはリプライを行う投稿者のサーバから発信されますが、サークルへの返信では、これをスレッドの先頭の投稿のサーバへ預けて、そこからメンバーに配送する仕組みとなります。

これを実現するために、いくつかの拡張が行われています。

--
ここから先はちょっと難しい話になります。一応、ざっと説明しますので興味のある方は読んでみて下さい。

新しい仕様で、試行錯誤している最中ですので、まだ、誰もわからなく大丈夫ですw

@circledev ひとつは、bearcapsという仕組みの導入です。

Mastodonの投稿には公開範囲が設定出来ます。

投稿は固有のURLを持っていてHTTPによって参照できます。

この時、誰がアクセスしてきているのか確認する方法がなければ、公開範囲という機能が実現できません。

そこで、署名付きのHTTPリクエストを行うことで、誰がアクセスしてきているのか、そのアカウントは本物なのか、確認する仕組みが使われています。

サークルでは、参加できるメンバーを確認する、これとは別の仕組みを導入することになりました。

サークルの投稿では、Createアクティビティで投稿本体を配送する代わりに、BearerトークンとURIをセットにしたBearcap URIsをObjectに持たせて配送します。

bear:?u=https://fedibird.com/@noellabo/104787881912364707&t=xxxxxx

bearcapsを受け取ったユーザーのサーバは、指定のURIに投稿本体を取得しにいく際に、このBearerトークンを添えてリクエストします（Authorization: Bearer xxxxxx というヘッダを付ける）

@circledev このモデルが採用されると、サークル機能と互換性のない実装では、サークルの投稿アクティビティを受け取っても内容を取得することができなくなります。

これまでは未対応でもフォロワーのみ（従来のMastodon）・ダイレクト（Pleroma）として認識されていました。

もう一つは、宛先として、ActorやPublicの他に、/contexts/xxxxという表現を追加したことです。contextはActorのサブセット的なもので、idとinboxとtypeだけを公開するtype: Groupのオブジェクトです。

内部的には最初のサークル投稿に紐付いていて、このcontextのinboxにリプライを配送することで、contextのメンバーに転送されるという動作をします。

リプライでは、Noteのtoに指定するだけでなく、contextにも同じIDをそえます。メンバーに転送するNoteの条件として、このcontextをチェックします。

bearcapsについては、こちらに仕様がありますので参照してください。
https://github.com/cwebber/rwot9-prague/blob/bearcaps/topics-and-advance-readings/bearcaps.md

@nacika @circledev なるほど。

現在の方向性としては、投稿を見ることが出来る人はトークンを持っている＝サークルのメンバーっていう扱いになっているから、メンションを禁じる可能性もあるね。

これ、本当に試行錯誤している感じで、まだどうなるかわかりません。

UIは私が勝手に提案していますが、そちらの検討もこれからです。