このアカウントは、notestockで公開設定になっていません。
のえる(@noellabo@fedibird.com)の投稿
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
このアカウントは、notestockで公開設定になっていません。
の投稿
Mitsouko@mstdn.f72u.net
このアカウントは、notestockで公開設定になっていません。
しゅいろのチャンネルの取り組みでちょっとホットになってるから、前に書いたグループの話をブーストしておくね。
グループの話(1/5)
まず、ActivityPubの概要から。
Mastodon、Pleroma、Misskeyは、それぞれまったく異なるプログラムですが、ActivityPubというプロトコルに従ってやりとりすることで、相互接続を実現しています。
ActivityPubをざっくり言うと、Actorが別のActorに対してActivityを送信し、相互作用する仕組みです。
Actorはユーザーのアカウントに相当するものです。通常のユーザーはPerson、botはServiceという種類のActorとして表現されます。
Activityは『投稿を・作った』とか『投稿を・気に入った』『Actorを・フォローする』というようなメッセージです。
Actorは、受け取ったActivity、送ったActivity、フォローしているActor、フォローされているActorなどのコレクションを保持しています。
・ActorとActorがやりとりする
・ActorにPersonやServiceなどの種類がある
・Activityを送り合う
・フォロワーなどのコレクションを保持している
グループの話(2/5)
Actor同士が直接やりとりする投稿は、当事者以外、他の人には見えません。
そこで、Activityの宛先として、Publicコレクションという特殊な宛先を指定することができるようになっており、各サーバプログラムでは、これを誰にでも見えるようにしたり、連合タイムラインやローカルタイムラインに流して表示しています。
フォロワー限定やダイレクトが基本形で、公開や未収載が特殊な公開範囲だということです。
また、連合タイムラインやローカルタイムラインはユーザーを探すための場所ですよ、と説明されるのは、こういった事情があるためです。
公開投稿をどのように扱うか（見せ方を工夫するか）は、サーバ次第です。
なお、Activityの宛先には、メールと同様にToとCcがあります。一般に、PublicをToに指定したものが公開投稿、PublicをCcに指定したものが未収載として扱われています。
ここまで、なんとなくつかめましたでしょうか？
グループの話(3/5)
グループは、ActivityPubによるユーザーの集合の表現で、コミュニティやチャンネルを実現することができる仕組みとして利用できます。
Actorの種類としてGroupが定義されているので、これを用います。
Group Actorを宛先とすることで、Groupに参加しているActorへ間接的にActivityを送ることができます。
（ただし、第三者となるActorがActivityを転送するにはJSON-LD署名が必要で、現実的には投稿と削除ぐらいしか対応していない状況です）
Groupのメンバーを表現する方法はいろいろ考えられますが、Mastodonなどの既存実装との互換性を考えると、Groupのフォロワーをメンバーと見做す実装が現実的であるため、私はそれを採用しています。
グループの話(4/5)
投稿するActorがGroupへメンションすると、Group Actorがそれを、メンバー（自身のフォロワー）へAnnouce Activityで転送します。これが基本形です。私はこれを、アクティブ方式と呼んでいます。
もう一つ、Group Actorからフォローバックして、ハッシュタグなど特定の条件が揃った場合にブーストする方式も可能で、私はこれをパッシブ方式と呼んでいます。
パッシブ方式は、無意味に多くの投稿をGroupに配送してしまう弱点がありますが、メンションせずにグループに投稿を流せるので、利便性はなかなかのものです。
これらは、既存のMastodonなどのサーバでも十分に機能しますが、サポートする機能を実装することで、より効率良く、使いやすくすることが可能です。
このあたりは、色々とアイデアがあって進めているところです。
グループの話(5/5)
グループは、連合する、サーバをまたぐコミュニティの構築に活用することができます。
ローカルタイムラインがコミュニティとして利用されてきていますが、その弱点を補うことができます。
Group Actorをホストしているサーバにメンバー管理と配送を依存していますが、投稿は参加者のサーバから発信され、参加者のサーバに配送されて保存されていくので、容易には失われません。
また、引っ越し機能でフォロワーを移し替えることで、コミュニティホストを引っ越すことすら可能です。
チャンネルに用いることもできます。これは、自身の投稿のうち、特定の内容だけをフォローしたいユーザーニーズに応え、投稿する側も配送先を使い分けることができるようになります。
複数アカウントの使い分けと比べ、リプライやお気に入り・ブーストが単一のアカウントにフィードバックされたり、メインアカウントのフォロワーに対して全てをまとめて配送できたりするメリットがあります。マルチポストが防げます。
こちらのらりおさんの記事をぜひ。これを実現可能なものです。
https://blog.cardina1.red/2018/02/25/strongest-dist-sns-i-think/
Fedibirdのグループは、サーバと分離したコミュニティを、いかに連合する仕組みの中に作るか、ということなので、方向性はちょっと違うとは思うんだけどね。
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がメディアの変換に使われています。
Fedibirdの現在の構成図です。
基本的な構成と比較していきます。
マシンの台数を増やしています。同じ構成のサーバを2台置いて、負荷の分散・処理能力の増強、片方が落ちてもサービスが停止しないように構成しています。
データベース（PostgreSQLとRedis）は、2台が同じものを参照する必要があるので、別のマシンに分けて実行しています。
Storageは、ローカルファイルシステムだと両方のマシンから読み書きできないので、外部のオブジェクトストレージ（Amazon S3）に変更しています。
Sidekiqは、キュー毎にプロセスを分離しています。
PostgreSQLへ同時接続するプロセスがどんどん増えていくので、pgbouncerを経由して接続することで、PostgreSQL側の接続数を一定以内に制限し、接続を再利用することで効率化しています。
2台の手前にHAProxyを置いて、外部からは一つのサーバに見えるようにして、2台のサーバに接続を分散させます。
全文検索用にElasticsearchを追加しています。
あとは、二重化したりバックアップする機構です。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ところで、こういう構成図は何で描いたら良いんですか。
アテがないので、結局、全部Illustratorで描いちゃうよ。なんでもできるけど、効率が悪いよ。
Illustrarorはソースコード見られないのでMastodonほどは詳しくわかりませんが、もうかれこれ28年ぐらい付き合っているので……
このアカウントは、notestockで公開設定になっていません。
の投稿
kuloma@fedibird.com
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
OK、ジミー。いいだろう。確かに私は以前寄付をした。今度はプラチナバッジをくれるのかい？ ……でもまぁ、そういうことではないんだよ。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
の投稿
kuloma@fedibird.comこのアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
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がメディアの変換に使われています。
エステバリスって、こう、割り切った設計といい、それにより生まれた特性といい、夢とロマンが詰まっていていいよね。
エヴァンゲリオンや士魂号のような『生きてる！』って感じのアレはまた別の良さがあるけど、それはそれとして。
ナデシコは、見ていた当時はそれほど自覚していなかったのだが、過ぎてみれば、かなり気に入っていたようだ。あとでもう一度全話見直しているし、色々と影響を受けている。
このアカウントは、notestockで公開設定になっていません。
＊「『もん』だって、そんなに使わないもん。たまたま浩平がよく聞いてるだけだよっ」
＊「両方とも今、使ってるじゃないか。ふたつ合わせて『だよもん星人』と命名してやる」
このアカウントは、notestockで公開設定になっていません。
