グループの話(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/

オフィス入居！ オフィス入居！

ヘドバン
ヘドバン

吉野家の肉だく牛カレー大盛

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がメディアの変換に使われています。

せるぶ

エステバリスって、こう、割り切った設計といい、それにより生まれた特性といい、夢とロマンが詰まっていていいよね。

エヴァンゲリオンや士魂号のような『生きてる！』って感じのアレはまた別の良さがあるけど、それはそれとして。

どいつもこいつも好きだが、やはりウリバタケが熱い。

ナデシコは、見ていた当時はそれほど自覚していなかったのだが、過ぎてみれば、かなり気に入っていたようだ。あとでもう一度全話見直しているし、色々と影響を受けている。

ナデシコのホウメイさんを思い出している

＊「『もん』だって、そんなに使わないもん。たまたま浩平がよく聞いてるだけだよっ」

＊「両方とも今、使ってるじゃないか。ふたつ合わせて『だよもん星人』と命名してやる」

Tissueのスマホクライアント「PocketTissue」