のえる @noellabo@fedibird.com

#fedibird この対策してから、Fedibirdで現象再発してる人います？ なおった？

#fedibird ActivityPubのネットワークは、公開投稿を主体とするものであると捉えるのが自然です。ここは敢えて言い切っておきます。

さまざまな公開範囲や、リプライを関係者だけにみせるようにするなどの工夫などはありますが、

本質的には、一切暗号化はされておらず、各ActivityPub実装が紳士協定のようなものでルールをすりあわせているだけです。

ひとたび投稿され、連合されれば（他のサーバに配送されたりfetchされれば）、公開範囲が守られる保証はありません。

拡散した情報を回収することも困難です。

まあ、何事も完全なものはなく、それでも公開範囲は十分機能するわけですが、公開が基本のネットワークにいることは意識していた方が良いでしょう。

なお、同じ連合するネットワーク（別のFediverse）であるMatrixは、クライアントで暗号化されるエンドツーエンドで、いわゆる公開投稿が存在しない世界です。

Matrixの場合、ものすごくメンバーの多いルームをパブリックと捉えることもできますが、そういう使い方を主体とする考え方ではないと思います。

非常に対照的です。

#fedibird 投稿がユーザー個別のinboxに届くと、サーバ全体の窓口であるshared_inboxと違い、そのユーザーに対するサイレントのメンションが付与されます。

これはあまり知られていない概念かもしれないので説明しておくと、投稿には、メンションの一覧が保持されています。通常は、@ をつけて明示したものが記録されているのですが、投稿本文中に明示されていない、いわば隠しメンションが存在しています。

公開範囲ダイレクトではメンションされた人だけが投稿を参照できますが、

この隠しメンションだけの投稿は、ダイレクトに似ていますが、目に見える形ではメンションがありません。

このような投稿は、明示的なメンションを含まない形で、ユーザーのinboxに直接配送することで生まれます。

これが、limitedという投稿範囲（visibility）です。

Hubzillaが早くからサポートしており、互換をとるために産まれました。Mastodonでもサークルにより実現され……かかりましたが、採用されていませんw

Fedibirdにあるサークルというのは、このlimitedの一形態です。

#fedibird えーと全体が追い切れてないけど、わかるところでコメントしましょか。

理論上は、フォローしてフォロワーになるというのは、発信者（サーバ）からの配送と、fetch可能かというあたりになります。

公開投稿は、広く目に触れるためブーストされやすく、リレーによって流通する仕組みになっているので、他の公開範囲に比べてたくさんの投稿データが行き交っていますが、

未収載やフォロワー限定、ダイレクトまで、すべてサーバがユーザーに代理してキャッシュする仕組みになっているため、流通量は少なくても、同様の取り扱いが可能です。

Fedibirdでは、MisskeyのGhostに相当する機能はあえてもたせていません。（匿名アカウントを代理にしてサーバに配送させることで、個別フォローによらず、サーバ上で参照できるようにする手法です）

購読機能でも、公開投稿だけを対象とする縛りを入れています。未収載は、unlisted、そうしたリストに掲載しない公開範囲と解し、これも対象外としています。

このあたりは、あるべき姿の設計思想、ポリシーに基づくもので、技術的制約ではありません。

#fedibird データベースサーバを引っ越しし、PostgreSQL 13.4から、PostgreSQL 14に移行しました。同時にサーバスペックを引き上げ、チューニングしました。

本件に先立ち、Nightly Fedibirdで13.4から14への移行をテストしています。こちらはpg_upgradeによる同一サーバ上での自動変換によるもので、スムースに移行できましたが、概ね30分ほどのダウンタイムとなりました。

同じことをFedibirdでやってもいいのですが、データベースサイズは7倍弱、単純計算で3時間半、正確にはわかりませんが、かなりのダウンタイムとなることが予想されました。

そこで、Fedibirdでは今回、論理レプリケーションによってバージョン違いのPostgreSQLのレプリケーションを行い、完了後に切り替える方法で、ダウンタイムを最小にする作戦をとりました。

結果として、概ね1分かからずに切り替えできました。

なお、論理レプリケーション自体はさほど難しくないですが、ストリーミングレプリケーションのような完全複製とならないため、少しだけ実行時にコツが必要です。

#fedibird DB切り替え、大丈夫そうですね。ちょっと様子をみますので、あとで報告しますー。

#fedibird ちょっとDB切り替えメンテいきますー。失敗したら切り戻すかも。

ActivityPubの連合は、基本的な枠組み以外は規定されていないので、実装についていろいろと前提がおけず、互換性がない機能が存在します。

既存の実装同士で仕様を揃えたり違いを考慮することで、ある程度実用に耐える運用が可能になっているのですが、規格ベースではないので、今後さらに実装が増えてくると、それもなかなかうまくいかなくなってきます。

実装同士、話し合ってすりあわせていけるところもありますが、考え方の違いで合意できないものもありますし、運用者がカスタマイズで互換性を壊すケースもあります。

どこまでこの非互換を受け入れ、あるいは拒否していくか、悩ましいところです。 #fedibird

#fedibird ちなみに、FedibirdのデータベースはPostgreSQL 13.4ですが、その手前にPgBouncerがあって、コネクションを交通整理したり再利用したりして、効率向上を図っています。

このPgBouncer、データベース接続要求を一時的に保留しておくことができるので、ごく短時間の再起動であれば、Mastodonなど接続元にエラーを返さずに、復帰してから処理継続することで、わずかに遅延させるだけで済ませることができます。便利機能。pauseとresumeです。

今回もこれを使っていたのですが、再起動に時間がかかったため、停止が長いだけでなく、タイムアウトしてエラーが発生してしまったようです。

#fedibird いまちょっと止まったかと思いますが、データベース設定の切り替えのため、データベース本体を再起動しておりました。ごめんねー。

#fedibird test

#fedibird いうのわすれてたけど、メンテしてて重いと思うけど、よろしくね。

#fedibird うん、NERVの投稿が普通に届くようになってるね…… #fedibird

#fedibird Nightly Fedibirdですが、昨晩よりPostgreSQL 14に切り替えて運用中です。特に問題はないかと思いますが、しばらくこちらで様子をみていこうかと思います。

Fedibird系使ってる人限定ですけど、タイムラインの表示がおかしくなる（同じ投稿が何度も表示される）などの現象をなおせたか、少し気にしておいてください。

この増殖、おそらく原因は、タイムラインに投稿を追加読み込みした際に何らかの原因で同じ投稿が重複してタイムラインに保持され、Reactで同じkey propsが指定されることにより発生する誤動作だと思います。

内部的に重複排除するようにしたことで、今後は発生しなくなると予測しています。（名残惜しい……） #fedibird
QT: https://fedibird.com/@noellabo/107052817055589730

#fedibird 導入して数日経ちますが、WebUIの投稿の中でURLが既知の投稿を指している場合、別のウィンドウ・タブではなくWebUIの中で直接開くようになっています。

なお、Ctrlキー・Commandキーを押しながらクリックすれば、別のウィンドウ・タブで開きます。

サーバがまだ取得していないURLには対応していません。

また、Mastodonが投稿として認識しないコンテンツは通常のリンクになります。

地味に使い勝手が向上していますので、ぜひご活用ください。

#fedibird タイムラインで投稿が増殖する不具合について、予防措置をとりました。

この投稿以降、WebUIをリロードしてから、投稿が増殖する不具合が再発したら報告願います。

ちなみに激しく発生するとこんな感じです。
https://fedibird.com/@noellabo/103806624643002578

程度が軽い場合は、同じ投稿が間をあけてなんども挟まってきたりします。

ウチ、misskey.ioの認識しているアカウントのうち、フォロー関係にあるアカウントの割合やたら高いからね……。 #fedibird
QT: https://fedibird.com/@noellabo/107036958977765869

#fedibird ウチのデータベースバックアップの取り方としては、全部プライマリからで、24時間に一度フルバックアップをとっていて、それと合わせて最長60秒でWALバックアップをとってる感じです。これを7日保持。

レプリケーションという、リアルタイム複製も行っていて、これがあるとプライマリが落ちた時にすぐ復旧できて便利なのですが、不整合（破損）があった場合はそれも複製されるので、単純なハードウェア障害からの早期復旧に使います。

#fedibird のElasticsearchは7.15.0です。日本語の形態素解析にsudachiを組み込んでます。

（素のMastodonの場合は対応が必要です）

普段はElasticsearchが自動更新されないように、aptではholdしてあります。apt updateしてて、あ、更新きてるなって気が付いたら、手動でアプデを実行します。

Elasticsearchは、バージョンがあがるごとにプラグインの対応バージョンも一致していることを比較して弾くので、アップデートに合わせて同時にプラグインもあげなければなりません。結構Breaking Changeもあるので、まぁ安全だとは思いますが。

なので、プラグイン（ここではelastic-sudachi）を消して、Elasticsearch本体アプデして、対応するバージョンのプラグインをインストールし直して、という流れになります。

elastic-sudachiは、githubからサーバ上にcloneしておいて、その場で対応バージョンにビルドしてます。gradle使うようになってから凄く簡単になりました。