のえる @noellabo@fedibird.com

@circledev サークルを少し整理し、Fedibird上では日本語化しました。現時点での概要をざっと説明します。提案中のもので、本家が採用する仕様ではありません。

スクリーンショット中心にお伝えしますので、雰囲気でみてください。

公開範囲『サークル』を使って投稿します。あらかじめ自分でサークルを作成しておいて選ぶ方法と、リプライする際に使える『返信先の投稿者』『スレッドの全投稿者』を選ぶ方法があります。スレッド（返信の返信……）になっているかどうかをみて自動選択されますが、変更可能です。

サークルは投稿そのものに宛先として記録されます。あとからサークルのメンバーを変更しても影響を受けません。

自分の投稿の○印をクリックすると、宛先の一覧が確認できます。この宛先は、投稿した人以外は見ることが出来ません。

サークルによる投稿は、フォローされている相手にしか見えず、届きません。また、メンション（@ で始まるユーザー名記法）されていないため、通知は行われません。

密かに大量送信し易い仕組みではありますが、相手からのフォローが必要なので、スパム送信には使いにくくなっています。

@mei23 いまさっき、toとccが空っぽで、本文中に @ 付きのメンション記述がない投稿をめいすきーのめいめいのこのアカウントに送ったけど、たぶん見えてないと思うんだ。shared_inboxじゃなくて、アカウントのinbox宛。

どこかで弾かれるんだと思うんだけど、これ受け取ってもらうにはどうしたらいいかな？

（いま実装中のMastodonのサークルの投稿）

ﾃﾞｽﾖﾈｰ

ワードミュート、ユーザー設定のフィルターで作成するんだけど、チェック状態を全部反転させるのが最適というアレがある（以前、めいめいが指摘してくれた）

今日はコンビニ調達だったので、適当に買ってきてくれた『劇辛！スパイシーカレー』をいただきました。

からい……。
#gochisou_photo

TootCloudでワードクラウドを作成しました！ #TootCloud https://tootcloud.ml

深藍さんのRemixも良いね。

このへんとか聴いてる

喫茶ソワレのゼリーポンチはいかがでせう？

Gmailになんか届いてるな……しばらく見なかったことにしよう……

Fedibirdの現在の構成図です。

基本的な構成と比較していきます。

マシンの台数を増やしています。同じ構成のサーバを2台置いて、負荷の分散・処理能力の増強、片方が落ちてもサービスが停止しないように構成しています。

データベース（PostgreSQLとRedis）は、2台が同じものを参照する必要があるので、別のマシンに分けて実行しています。

Storageは、ローカルファイルシステムだと両方のマシンから読み書きできないので、外部のオブジェクトストレージ（Amazon S3）に変更しています。

Sidekiqは、キュー毎にプロセスを分離しています。

PostgreSQLへ同時接続するプロセスがどんどん増えていくので、pgbouncerを経由して接続することで、PostgreSQL側の接続数を一定以内に制限し、接続を再利用することで効率化しています。

2台の手前にHAProxyを置いて、外部からは一つのサーバに見えるようにして、2台のサーバに接続を分散させます。

全文検索用にElasticsearchを追加しています。

あとは、二重化したりバックアップする機構です。

Mastodonの基本的な構成図です。

Mastodonをシンプルに構成すると、図のような構成になります。

一番手前にNginxを置いて、バックエンド側の、WebUIとAPI（Puma）、ストリーミング（Node）、メディアファイル（Storage）へのアクセスを中継します。

データベース（PostgreSQL）へ、Puma、Node、Sidekiqがそれぞれ接続します。

もう一つのデータベース（Redis）へ、Puma、Node、Sidekiqがそれぞれ接続します。

ローカルファイルシステム（Storage）へは、Puma、Sidekiqが読み書きを行い、Nginxが読み出してユーザーのリクエストに応えます。

PumaとSidekiqは、インストールしたrubyの環境で実行されます。

Nodeは、node.js v12〜の環境で実行されます。

Pumaは、ユーザーのブラウザに初期値とJavaScriptのコード（WebUI）を渡して、それ以降はAPI経由でやりとりします。

この他、ImageMagickやFFmpegがメディアの変換に使われています。

Mastodon(Fedibird)

#fedibird の構成をざっくり。

まず、ユーザー側（インターネット側）からは、本体のHAProxy鯖とメディアのCloudflareがあります。たまにHAProxyの前にCloudflareを挟んでテストすることもありますが、普段は本体には通していません。

メディアの方は、Cloudflareの内側に、Lightsailにnginxを置いて、S3へのアクセスをキャッシュしています。キャッシュが有利なことはもとより、Lightsailの価格に転送量が含まれているため、S3に直接アクセスさせるより費用の節約になるためです。

本体側のHAProxyはロードバランサーです。2台のVPSのnginxへアクセスを振り分けています。片方がダウンしている時は、そちらにはアクセスが振り分けられないようにして、ダウンタイムを少なくすることに貢献しています。

各VPSの構成は図の通りで、sidekiqは3系統に、外部鯖のredisへのアクセスはmainとcacheに分け、PostgreSQLへのアクセスはpgbouncerを経由。メディアはS3に直接保存します。

まぁしょうがない、こういうのはスクショであげとくか。復帰したら消す。

@stux Adding a VPS to an existing single server configuration.

キジです

唐突ですが、ねこです。

唐突にトゥートしていくか。

焼肉です！（再掲）

#おなかがすきましたね
#gochisou_photo

押すなよ！ 絶対に押すなよ！