#fedibird ちょっと、再起度してから、何かおかしいようです 🤔
調査中にて、少々お待ちください。
使えてる範囲での利用は差し支えありません。たびたび500がでてるかと思いますが、とりあえず無視しといてください。
#fedibird 軽めのメンテいれますねー。ちょっとだけ繋がらないタイミング入りますが、我慢して!
ここまでの経緯として、プロダクトとしてのMastodonがNFTを採用することはないと思いますが、各サーバやフォークが何を実装していくかはそれぞれが主体的に判断するものです。
Fedibirdは、クリエイターが報酬を得る仕組みや、売買などの機能を否定しません(いつか実装するかもしれません)が、NFTは筋が違うと考えています。 #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分かからずに切り替えできました。
なお、論理レプリケーション自体はさほど難しくないですが、ストリーミングレプリケーションのような完全複製とならないため、少しだけ実行時にコツが必要です。
ActivityPubの連合は、基本的な枠組み以外は規定されていないので、実装についていろいろと前提がおけず、互換性がない機能が存在します。
既存の実装同士で仕様を揃えたり違いを考慮することで、ある程度実用に耐える運用が可能になっているのですが、規格ベースではないので、今後さらに実装が増えてくると、それもなかなかうまくいかなくなってきます。
実装同士、話し合ってすりあわせていけるところもありますが、考え方の違いで合意できないものもありますし、運用者がカスタマイズで互換性を壊すケースもあります。
どこまでこの非互換を受け入れ、あるいは拒否していくか、悩ましいところです。 #fedibird
#fedibird ちなみに、FedibirdのデータベースはPostgreSQL 13.4ですが、その手前にPgBouncerがあって、コネクションを交通整理したり再利用したりして、効率向上を図っています。
このPgBouncer、データベース接続要求を一時的に保留しておくことができるので、ごく短時間の再起動であれば、Mastodonなど接続元にエラーを返さずに、復帰してから処理継続することで、わずかに遅延させるだけで済ませることができます。便利機能。pauseとresumeです。
今回もこれを使っていたのですが、再起動に時間がかかったため、停止が長いだけでなく、タイムアウトしてエラーが発生してしまったようです。
#fedibird test
#fedibird いうのわすれてたけど、メンテしてて重いと思うけど、よろしくね。
#fedibird Nightly Fedibirdですが、昨晩よりPostgreSQL 14に切り替えて運用中です。特に問題はないかと思いますが、しばらくこちらで様子をみていこうかと思います。
Fedibird系使ってる人限定ですけど、タイムラインの表示がおかしくなる(同じ投稿が何度も表示される)などの現象をなおせたか、少し気にしておいてください。
この増殖、おそらく原因は、タイムラインに投稿を追加読み込みした際に何らかの原因で同じ投稿が重複してタイムラインに保持され、Reactで同じkey propsが指定されることにより発生する誤動作だと思います。
内部的に重複排除するようにしたことで、今後は発生しなくなると予測しています。(名残惜しい……) #fedibird
QT: https://fedibird.com/@noellabo/107052817055589730
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。