Chienomi

Akkomaに関するお役立ち情報まとめ

製品・サービス::software

ユーザー向けの知識

前提知識

まず大前提として、AkkomaはPleromaの派生であり、Pleromaにいくつかの機能(例えばカスタム絵文字リアクション, 参照, MFM)を追加したものである。

MastodonやMisskeyはサーバーと1:1の関係にある「公式クライアント」というものが存在し、セットになっている。 対してPleromaはサーバーはサーバーであって、そのサーバーを利用するにはサーバーに対応した任意のクライアントを使うという方式になっている。 インスタンスにインストール可能なサーバーに対応したUIを “FE” (Front End) と呼んでいる。

公式のユーザー用FEとして、Pleroma FEがある。 また、Pleromaのサーバーを使うPleroma FE以外のFEとして、SoapboxとKenomaもある。

さらに、PleromaはPleroma API以外に、Mastodon互換のMasto APIもある。 このMasto APIを使うFEとして、Mastodon風のMasto-FEと、Fedibird風のFedi-FEがある。

しかし、より重要なのは、Masto APIが存在するため、「Mastodon用のクライアントがPleromaに対しても動く」ということだ。 もちろん、Pleroma固有の機能は動かなかったりするが、Pleroma固有の機能はそれほど重要なものでもないのであまり気にならない。

なんのFEが使えるかは、サーバー側の設定なので、ユーザーが決められるわけではないが、Pleroma-FEとMasto-FEなど共存可能なものもある。

ここまではPleromaの事情だが、Akkomaだと機能が増えているため、もう一枚レイヤーが増える。

AkkomaもPleroma同様、サーバー管理者が任意のFEを選んでユーザーに使わせることができる。 そして、Masto APIを使うMastodon用クライアントと、Pleroma APIを使うPleroma用クライアントを使うことが可能だ。

Akkomaの機能とクライアントの問題

ところが、Masto APIやPleroma APIを使うアプリは、Akkomaが拡張した部分を知らないので、Akkomaの機能を使うことができない。 Akkomaは参照、リアクションなど基本的な部分でPleromaに対して拡張されているため、Mastodon用クライアントやPleroma用クライアントを使うと、リアクションされたり参照されたことに気づくことができないなど結構不自由してしまう。

さらに、Akkoma用クライアントというものが(公式であるAkkoma版Pleroma-FE以外に)ないのだ。 唯一Android用アプリであるHuskyがカスタム絵文字リアクション表示に対応しているが、参照に対応しておらず、カスタム絵文字リアクションをつけることもできないので非常に微妙。

Akkoma用FEとしてManageneというのもあるのだが、Akkoma用であるにも関わらずMasto API相当の機能しか使えない。

BTW, Akkomaの場合はPCだろうがスマートフォンだろうが、おとなしくPleroma-FEを使おう。

Pleroma-FEが開放されていないAkkomaインスタンスに関しては、それらの機能は使えないインスタンスなのだと思ったほうが良い。

Pleroma-FEはPCだとちょっとクセが強いが、スマートフォンだと悪くない。 PWAにも対応している。まぁ、少しバッテリー消費が激しいのと、マルチアカウントしづらいのは難点だけれども。

LinuxだとFedistarがカスタム絵文字リアクションへの対応を始めていて、現状は厳しいが将来は有望。

Pleroma-FEの設定

ここでは日本語に設定している前提で項目を説明する。

タイムラインのストリーミング

デフォルトでは「読み込み」を押さないとタイムラインが更新されない。

「全般」にある「上までスクロールしたとき、自動的にストリーミングする」をオンにすると、タイムラインの一番上にいるときのみ自動更新されるようになる。

さらに、デフォルトでは「タブにフォーカスがないときストリーミングを止める」がオンになってる。 これは、ブラウザのウィンドウとタブがアクティブでないとストリーミングされない。 基本的にはこれはオフにしたほうが利便性が良いだろう。

なお、タイムラインをスクロールしていた場合や、公開タイムラインを見ていてホームタイムラインに戻ったときなどは、手動で読み込みする必要がある。

アニメーション絵文字

「全般」タブにデフォルトではオフになっている「カーソルを重ねたとき、GIFを動かす」という項目がある。

これがオフである場合、アニメーション絵文字は常に再生される。 オンになっていると、カーソルを載せないと再生されない。 これは基本的にうまく動かないので、オンになっているとアニメーションを無効にするのに近い。

検索とフォロー

「プロフィール」タブの「プライバシー」の項目にある。

「あなたが認めた人だけ、あなたのアカウントをフォローできる」はいわゆる鍵垢設定である。 デフォルトはオフ。オンで鍵垢化。

「検索などのサービスでこのアカウントを見つけることを許可する」は、ユーザーページ、および個別ノートに対してindexを許可するかどうかである。 すべてのbotがこれに従うとは限らないが、少なくともGoogleは従う。 つまり、Google検索にユーザーやノートが登場することを許すかどうかである。 デフォルトはオフ。つまり、許可しない。

「フォロー中のアカウントが引っ越したとき、自動フォローを許可する」は引っ越し機能に関わるものだ。 デフォルトはオン。オフにすると、引っ越しに追従しない。 特別な理由がなければオンで良いだろう。

ダイレクトメッセージの受信設定

日本語されていない。 「プロフィール」タブの「名前とプロフィール」のところにある「Accept DMs From」である。

Everybody - 誰もがDMを送ることができる。

Nobody - 誰からもDMを受け取らない。

People I Follow - フォローしている人(フォロイー)からは受け取る。

ミュートとブロック

ミュート, ブロック, フィルターがどのように機能するかは「フィルタリング」タブに存在している。

この設定があるため、Misskeyなどと違い、ミュートやブロックがどのように振る舞うかが固定ではない。

タイムラインにリプライが掲載される

「フィルタリング」タブの「タイムラインのリプライ」で設定可能。

デフォルトは「すべてのリプライを見る」であり、タイムラインに掲載される対象の人が発信したリプライがすべて掲載される。

「私に宛てられたリプライと、フォローしている人からのリプライを見る」は、その説明に反して、自分が絡まないものは「フォロイー→フォロイー」のリプライだけが表示される。つまり、Twitterと同じ挙動である。

「私に宛てられたリプライを見る」は自分宛ての場合だけ見る。 つまり、自分が絡まないリプライは表示されない。

TLが画像まみれで困る

「フィルタリング」タブの「タイムラインのファイルを隠す」をオンにすると、画像がたたまれるようになる。

IMAGEと表示されるので、これをクリックすると画像が表示され、サムネイルは表示されない。

自動削除

「プロフィール」タブにある。 鍵垢であるだけでは飽き足らず、ノートを残すこともしたくない場合に役立つ。

Akkoma自身はノート削除は削除フラグを立てるだけで実削除しないこともあり、ローカルには負担は小さいが、ActivityPub経由だとMisskeyのようにノート削除処理が重いサーバーもあるため、あまり好ましくないことではある。

デザイン変更

「テーマ」タブでデザインを編集できる。

「プリセット」はサーバー側で用意されているものを呼び出すことができる。 編集はこれをベースに行える。

「保存」すると現在の設定をJSONファイルに保存する。 「ロード」はJSONファイルをアップロードしてテーマを再現する。

テーマの編集はそれなりに面倒。

「フォローしていないユーザーからの通知を拒否する」

いわゆるふぁぼ爆や通知破壊のような、大量にリアクションをとられることに困っており、当該リアクションの通知を全オフにはしたくなく、なおかつ特定ユーザーに限るわけでもない場合に有効。

フォロイー以外からのすべてのリアクションが通知に載らなくなる。

用語

カッコ内はTwitterでの用語。

  • 投稿のこと (ツイート) → ノート
  • 投稿すること (ツイートする) → サブミット
  • 返信 (リプライ) → リプライ
  • @ つきの発言 (メンション) → メンション
  • 投稿を再発信する (リツイート) → リピート
  • 引用 (引用リツイート) → 参照 (reference)
  • ☆ (ライク) → お気に入り (favorite)

PWAでマルチアカウントする

ブラウザはログイン情報をブラウザ内に保存するため、いちいちログアウト/ログインしないとアカウントを切り替えられない。 PWAはログインしっぱなしでなければ機能しないため、マルチアカウントできない。

これを解決する方法は、複数のブラウザでPWAをインストールすることだ。 ログインしているデータはブラウザ固有なのだから、別のブラウザを使えば良い。

比較的やりやすいのは、Firefox/Firefox Beta/Firefox Nightly, Vivaldi/Vivaldi Snapshotなど、バージョン違いが複数のアプリになっているブラウザを使う方法。

なお、AkkomaのPWAは使い勝手は良いが、バッテリー消費もやや重い印象。

ドメインをブロック

「このドメイン(インスタンス)からくるノート、嫌なのばっかりだなぁ」となった場合、ユーザーを展開したところの「︙」にある「ドメインをブロック」するとドメインまるごとブロックできる。

このほか、特定ユーザーのリピートをミュートする機能もここにある。 発言は見たいけどリピートは嫌というユーザーにも対応可能。

CW

Pleroma-FEでは「説明 (省略可)」となっている投稿の見出し部分を書くとCWになる仕組み。

Pleroma-FE以外のFE

概要

Pleroma/Akkomaにおいて公式に用意されているフロントエンド(クライアント)がPleroma FE。

まずFEという概念について(素人には少し難しい話だけれど)説明しておこう。

サーバーを利用するためには何らかのクライアントアプリケーションが必要となる。 これはAkkomaに限らず広くそうである。ユーザーはクライアントアプリケーションを操作し、クライアントアプリケーションがサーバーとやりとりをする。1

そのクライアントアプリケーションはたとえサーバーがwebサーバー(HTTPプロトコルを話すサーバー)であったとしても、ウェブアプリケーション(ウェブブラウザで利用するHTMLなどを利用したアプリケーション)である必要はない。 だが、必要がないとはいえ、多くの場合サーバーと一対のウェブアプリケーション(=ウェブインターフェイス=ウェブクライアント=クライアントアプリケーション)が用意されることが多い。 MisskeyやMastodonの場合は、サードパーティアプリを利用することはできるが、前提として公式のウェブインターフェイスが存在しているし、TwitterやFacebook, Instagramに関しては公式のウェブインターフェイス(あるいはモバイルアプリ)を強いる形になっている。

PleromaやAkkomaの場合、名目上あくまでこれらはサーバーの存在であり、クライアントは別であるということになっている。 だが、実際のところ、PleromaにもAkkomaにも公式で開発されているクライアントのPleroma-FE(Akkomaの場合は区別のためAkkoma-FEと開発上は呼ばれているが、正式な名前としてはPleroma-FE)が存在し、結局これがサーバー一対のクライアントであると言える状態である。

ただ、Pleroma/Akkomaは運営者がPleroma-FEを置き換えてサードパーティアプリをデフォルトのアプリとして使用することができる、という違いはある。

しかし結局のところFEとは何かという話になると、「そのサーバーにバインドされたウェブインターフェイス」という意味でしかない。 そのサーバーにバインドされた、というのは、そのアプリで他のサーバーを利用できないようにしてある、という意味である。

さて、難しい話はやめにして、素人にもわかりやすいように言うと

  • Akkomaはサードパーティアプリが (存在するかどうかは置いておいて) 利用できる
  • Akkomaは運営者側で公式アプリの代わりにデフォルトでサードパーティアプリを使う形にもできる
  • 公式アプリとは別にサードパーティアプリも使えるようにすることもできる
  • 「FE」とはこのアプリのこと
  • 「Pleroma-FE」とは公式アプリのこと

くらいに思っておけばいい。 なお、ウェブアプリなのでモバイルアプリの話と混同してはいけない。

デフォルトのFEが何であるか、またどのようなFEが用意されているかはあくまで運営者次第なので、Akkomaに常にあるわけではない。 というより、ないことのほうが圧倒的に多い。2

違うFEを使う意味

まず、AkkomaにTLのストリーミングがないとか言っている人がいるが、嘘である。 そもそもPleromaが専用のストリーミングAPIを持っていて、Pleroma-FEもデフォルトで無効になってるだけで、設定すれば利用できる。

ただ、デフォルトでは無効なのと、割と叩く間隔が長い(特にAkkomaのほうは長い)ため、しっくりこないという人はいるだろう。 現実的に、そんなコンマ数秒ごとに更新される必要がある人はあまりいないと思うが。

しかし、Mastodon方式でもPleroma方式でもストリーミングは可能なので、Pleroma-FE以外のアプリを使うとだいたい当たり前のように激し目のストリーミングがついてくるので、そういうストリーミングを切望する人には「他のアプリを使う」が解決方法になるし、わざわざ手元に導入しなくても他のFEを使うことができれば体験に好みのものを選べる。

まぁ、Twitterを使うのにTweetdeckを使うのと同じような話だ。

また、Pleroma-FEのUIがとっつきにくいという声もある。 実際のところちょっとデザインがそっけないだけで、別に普通というか、ちょっと前のTwitterやFacebookがだいたいこんな感じだっただろうと思ったりするのだが、他のFEは最近のTwitterもしくはTweetdeckに寄せているものがすごく多いので、見た目がものすごく大事だからAkkomaはダメだとか思っている人にとっては解決策になったりする。

一方、Pleroma-FEはかなり高機能で細かい設定が可能なほか、Akkomaの場合はPleroma-FEがさらに拡張されているのに対し、Akkomaに対応したアプリはとても少ないので、他のFEを使うことで機能が制限される面もある。

Mastodon FE

Mastodon FE

MastodonのAdvanced Web Interface相当のUIを持つもの。

結構エラーが出るのと、Mastodon仕様で絵文字リアクションや参照がないため、Akkomaの機能が使えなくてちょっと使いにくい。 動作はかなりサクサクで負荷も小さいので、TLを眺める用としては結構良い。

Fedibird FE

Fedibird FE

Mastodon FEの代わりに使うことができるFedibirdバージョン。

私はFedibirdにアカウントを持っていないので比較できないのだが、基本的な話としては参照と絵文字リアクションが可能になっているので、Akkomaでも使いやすい。絵文字ピッカーはカスタム絵文字リアクションにも対応。

ただ、Mastodon FE同様の無理やり移植なのでうまく動かないところは多々ある。 Fedibirdはローカルタイムラインがない仕様であるため、Fedibird FEにローカルタイムラインの表示はあるが、クリックすると連合タイムラインになる。 ほかにもFedibird向けの(Akkomaにはない)機能の項目がそのまま残っていたりする。

Soapbox

Soapbox FE

SoapboxはすごくTwitterっぽい見た目を持つPleroma用のFE。

Pleroma用だが、運営者側でがんばればAkkomaでも利用可能。 Pleroma用でありながら、Pleromaにはない参照やカスタム絵文字リアクションに対応しているので、Akkomaでもおよそ無理なく使える。

SoapboxはもともとPleroma用のクライアントだったのだけれど、Soapboxの開発者がPleromaサーバーの開発に貢献していたということを背景として、Pleromaサーバーの開発に関して騒動を起こしてPleromaの開発からBANされ、その結果Soapboxの開発者とその支持者が出ていく形でPleromaの敵対的forkとしてSoapboxサーバーが誕生した。

そのため、より正確に言うと、Soapboxは現在はPleromaのクライアントではなく、Soapboxサーバーのクライアントだが、PleromaおよびAkkomaと結構互換性がある。 し、初歩的なレベルで言うならば結構使いやすい。 カスタム絵文字リアクションの確認が、ノートの詳細までいかないとできないとかいう問題はあるけれど。

また、Soapboxのユーザー登録画面がCAPTCHAに対応していないため、Akkomaサーバーで登録時にCAPTCHA認証をオンにしてると新規登録をSoapbox上で行うことはできない。

Mangane

Mangane

ManganeはSoapboxのAkkoma向けのforkで、Akkoma側で公式サポートはされていいないが、Mangane側ではAkkomaへのインストール手順を提示していて、Soapboxよりは容易に導入できるようになっている。

Akkoma向けにforkしたものだから、よりAkkomaに適していそうなものだが、なんとカスタム絵文字リアクションに非対応である。 というより、絵文字リアクション自体が限られたごく一部しか出来ない仕様。 さらに、つけられたカスタム絵文字リアクションも、ノート詳細画面では確認可能だが、ノート一覧画面ではそもそもリアクションがついているかどうかも確認できない。

他にもモバイル画面ではなぜか幅が突き抜けてしまって横スクロールするなど、Soapboxと比べると問題が多い。

利点としては、Manganeのユーザー登録部分はCAPTCHAに対応していることと、モバイルでのタイムライン切り替えが少し楽というあたりだろうか。

ヘビーユーザー向けの知識

Mangane

GitHubのManganeのリポジトリをクローンし、

% yarn install
% export NODE_ENV=develop
% yarn dev

という要領で起動、http://localhost:3036にアクセスする。 Mastodon/Pleroma/Akkomaの任意のインスタンスに対してアクセス可能。

今のところ、Node20では動かない。

Akkoma向けのFEだが、絵文字リアクションはなんでも表示できるが、つけられるのは非常に限られたものだけ。

Soapbox

GutHubのSoapboxリポジトリをクローンし、

% yarn install
% export NODE_ENV=develop
% yarn dev

という要領で起動、http://localhost:3036にアクセスする。 Mastodon/Pleroma/Akkomaの任意のインスタンスに対してアクセス可能。

Manganeとは逆に、Node20でないと動かない気がする。

見た目はほとんどManganeと同じだが、こちらはカスタム絵文字リアクションに対応。

Kenoma

GitLabのKenomaリポジトリをクローンし、

% yarn install
% export NODE_ENV=develop
% yarn start

という要領で起動、http://localhost:3000にアクセスする。 Pleroma/Akkomaの任意のインスタンスに対してアクセス可能。

開発が停止してしまっている。 Nodeは16を使うのが無難。

サーバー管理者向けの知識

なぜかAkkomaで検索するとChienomiが2番目に出てくるし、日本語リソースがChienomiしかないっぽいので、管理用の情報を掲載しておく。

Akkomaの利点

Pleromaも同じだが、MastodonやMisskeyと比べ圧倒的に軽く、また安定している。

現状、Akkomaサーバーが4、Misskeyサーバーが1という構成だが、Pleromaからマイグレーションして壊れてしまったJLinuxer Pleromaを除けば、自分のミス以外でAkkomaは問題が生じたことがなく、手間のかかり度合いだと3つのAkkomaより1つのMisskeyとなっている。

加えて、リソース消費量が4つのAkkomaより1つのMisskeyのほうが(CPU/メモリ/ストレージいずれも)大きく、少ないリソースでも非常に快適に動き、ユーザーのアクションによって大きく負荷が高まるようなこともないため、リソースが厳しい状態でも安定していて不安がない。 さすがにMisskey.ioのような規模になったときに何が起きるかは分からないが、少ない数だけで見れば、ユーザー増加による負荷の増加もMisskeyよりずっと少ない。

一方、PleromaはMastodonを踏まえたソフトウェアであると見ることができ、機能的にもMastodonに準じている。 対してMisskeyは驚くほどに機能が豊富だ。

AkkomaはPleromaをベースに、Misskeyを意識して作られているものであるため、Pleromaよりも機能が多い。 特にカスタム絵文字リアクションは、実際に運営すると驚くほどにコミュニティ形成に絶大な影響力を発揮するため、その存在はとても大きい。 また、引用はMastodonにおいては思想的な理由で採用されていないし採用されないものになっている。 Pleromaが引用を採用しない理由は分からないが、Akkomaには引用(参照)がある。

投稿が引用可能であることは、好みの問題が大きいところではあるが、アクティビティを増大させる要素であるのは間違いないだろう。 加えて、カスタム絵文字と引用を認識し、取り扱うことができることは、Misskeyなどのサーバーを含めてPleromaよりもActivityPubフレンドリーであると見ることができる。

Mastodonは動かすと思うところがありすぎるのだが、Pleromaに関しては「軽い。だがないものも多い」という印象になる。 対Mastodonだとそうでもないのだが、対Misskeyだと特にその印象が強い。 そして、受け取ることもできないため、Pleromaを立ててしまうとFediverse内での断絶を感じることがある。

Misskeyは極めて強力なコミュニティ形成機能を持っており、使い方も幅広い。 そのため、(Misskey.ioのように)極めて多いユーザーを持ったときにもサブコミュニティが機能し、ユーザーの使い方という意味では破綻しにくい。

Akkomaも単独でそのような巨大なコミュニティを持てるようなものでもないが、そのような巨大なコミュニティを構成するもののひとつとしては十分機能するというのがPleromaとの大きな違いになるだろう。 Pleromaの場合は、引用とカスタム絵文字が交換できないため、Misskeyとは違う宇宙になりがちなのだ。

他のSNSソフトウェアと比べ思想色が非常に薄いのも魅力かもしれない。

非常に軽いという利点を活かして、Masto-FE/Fedi-FE/Manganeを使う前提で運用する方法もある。 ただこの場合はAkkomaの機能を使えないため、特にMasto-FE, Fedi-FEを使う場合はPleromaのほうがメリットがありそうに思える。

Archlinuxへのインストール

公式ドキュメントの通り。

手順が文章中に含まれているものもあるので注意深く進めること。

Systemdユニットの

; Uncomment this if you're on Arch Linux
; Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl"

を見逃さないようにすること。

Pleromaからのマイグレーション

絶対にしてはいけない。

JLinuxer PleromaはPleromaからAkkomaにマイグレーションしたが、「絵文字の幅がおかしい」「画像をアップロードしようとするとFrontendが壊れる」「画像や投稿などが破損したりする」など問題が多発した。

データベースマイグレーションの問題らしく、ソフトウェアを完全に消去した上でAkkomaをインストールし直しても問題は解決しなかった。

Akkoma運営上の注意

他と比べてAkkoma版Pleroma-FEは設定によって個人的な好みにかなり寄せられること、そもそもデフォルトのPleroma-FEに結構クセがあることから、このページで紹介しているような案内をしたほうが良い。

絵文字の追加

手動インストールの場合、SINSTALL_PATH/instance/static/emojiがデフォルトの置き場。

やり方は色々あるが、単純にこの下に$CATEGORY/$NAME.pngの形で配置すれば使える。

サーバー再起動してもうまく反映されない場合、Admin-FEで “Emoji” から “Import packs from the server filesystem” をクリックすればOK。

スタイルの追加

手動インストール時、スタイルの定義はデフォルトで $INSTALL_PATH/instance/static/frontends/pleroma-fe/stable/static/style.json にある。

ここに

"redmond-xx": "/static/themes/redmond-xx.json"

のような記載があるが、/static/themes/は$INSTALL_PATH/instance/static/frontends/pleroma-fe/stable/static/themesを指す。

Pleroma-FE上でテーマを編集したあと「保存」を押すとJSONファイルとしてダウンロードできるので、これをリネームして配置し、style.jsonを編集すれば良い。

デフォルトのテーマ設定はAdmin-FEのInstanceセクションから。

Favicon

手動の場合、$INSTALL_PATH/instance/static/favicon.pngがデフォルトの場所。

これとは別に、Pleroma-FEのロゴはAdmin-FEのFrontendセクションに、サーバーのアイコンはInstanceセクションにあるので注意。

利用規約

かなりわかりにくいけれど、$INSTALL_PATH/instance/static/static/terms-of-service.htmlがその場所。

パネルドキュメント

Pleroma FEの設定でパネルドキュメントを表示するようにすると現れる。

パネルドキュメントの設定そのものはAdmin-FEのInstanceタブにあるが、WYSIWYGエディタを備えているものの、リンクボタンが機能しなかったりと微妙。 本体は$INSTALL_PATH/instance/static/instance/panel.htmlにある。これまた、これしかない場所だ。

ファイルアップロードサイズの制限

サイズ上限に引っかかった場合、サーバーはシンプルに413 Payload Too Largeを返す。

それは良いのだが、Pleroma-FEが413を受け取ったときに、そうだとわかる挙動になっていない。

各種サイズ制限は、Admin-FEに対しても適用される。 つまり、インスタンスのバナーやアイコンがサイズ制限に引っかかってアップロードできなかったりする。

また、Upload limitに

File size limit of uploads (except for avatar, background, banner)

と書いてあるが、 これらよりもUpload limitのほうが優先 であり、他のlimitよりもUpload limitが大きいか同じである必要がある。

(Misskeyのような) ユーザーファイル総量制限

できない。

PleromaのほうではMisskeyっぽいドライブ機能を搭載しようとしていた形跡があるので、そのうちできるかも。

Mangane on Akkoma

唯一の「Akkoma用クライアント」であるManganeだが、Pleroma-FEと入れ替える形で使うようになる。

UIは非常にTwitterに似ているが、参照もカスタム絵文字リアクションも使えない仕様で、Akkoma用といってもAkkomaの機能は何も使えない。 というか、大部分の機能は使えないし、連合タイムラインが無効になっていても連合タイムラインの項目は消えない。

個人的にはあまりおすすめしない。

READMEの通りにインストールしただけだとうまく動作しないので、Nginxの設定のserverセクションに

    proxy_hide_header Content-Security-Policy;
    add_header Content-Security-Policy "upgrade-insecure-requests;script-src 'self';connect-src 'self' blob: https://example.com wss://example.com;media-src 'self' https:;img-src 'self' data: blob: https:;default-src 'none';base-uri 'self';frame-ancestors 'none';style-src 'self' 'unsafe-inline';font-src 'self';manifest-src 'self';" always;

という記載が必要。(example.com は必要に応じて書き換えること。まぁ、書き換えなくても動いたけど)

READMEだと;が:になっている。

Mangane/Soapbox standalone

ユーザーとしてのManganeの利用と似た感じだが、

% yarn install
% export NODE_ENV=production
% export BACKEND_URL=https://example.com
% yarn build

のようにインスタンスを固定してビルドする。

ビルドされたものはstatic/ディレクトリ以下に吐かれるので、これをそのままサーバーにアップロードする。

サーブされるとき、/index.htmlでないとうまく動かないので、基本的にはMangane/Soapboxをサーブするためにサブドメインを切るような形になる。 アプリケーション自体はSPAであり、静的なJavaScriptファイルであるため、GitHub Pagesなどに置くことも可能。

両者を比較すると、全体的にManganeよりSoapboxのほうが良い。 そもそもManganeはAkkoma向けなのに、Akkomaの機能にほぼ対応しておらず、Soapboxは結構対応しているという状態だ。 SoapboxはNキーで入力に入れるのがとても良い。 1点だけ、モバイル版だとSoapboxはローカルタイムラインにアクセスしづらいというところだけがManganeにアドバンテージを感じる。 しかし、Manganeのモバイル版は幅がおかしい。

Soapboxの問題点として、NSFWがつけられているとテキストもろとも隠されるのだが、MRFでインスタンスの全メディアをNSFWにしているとすべてが隠されてしまう。

一見良さそうなのだが、ところどころ微妙な挙動があり、特にモバイル版は微妙、かつPWAに対応していないため本当に微妙。 「選択する」ならPleroma-FEのほうが良さそう。

非常にTwitterっぽく、見た目も良いのでとっつきやすいというメリットはあるが、Pleroma-FEのきめ細やかさと軽さは魅力としてとても強いことから、結局のところPleroma-FEが良いとなりやすい。

とはいえ、この方法なら手軽にSoapboxやManganeを提供できるので、選択肢として用意しておくのは良さそう。

standaloneで提供する場合は、Nginxの設定が必要。 soapbox-nginx-configにあるが、実際の宇宙庭園の設定としては少しだけ調整して

server {
    server_name soapbox.uchu-teien.com;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml;

    ssl_trusted_certificate   /etc/letsencrypt/live/soapbox.uchu-teien.com/chain.pem;
    ssl_certificate           /etc/letsencrypt/live/soapbox.uchu-teien.com/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/soapbox.uchu-teien.com/privkey.pem;

    root /srv/webapp/garden/soapbox/;
    location / {
        try_files $uri /index.html;
    }

    location /about/tos {
        return 301 https://uchu-teien.com/doc/tos.html;
    }

    # here goes long list of what we will use from real instance
    location ~ ^/(api|.well-known|nodeinfo|proxy|media|emoji|oauth|favicon.*) {

        proxy_http_version 1.1;
        proxy_pass       $scheme://localhost$request_uri;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host uchu-teien.com;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

という感じになっている。 これはManganeの場合も同様。

AVIFとWebPに関して

AVIFで画像投稿した場合、話は少し複雑になる。

まず、Pleroma.Upload.Filter.AnonymizeFilenameが入っているかどうかにより、これが入っている場合はPNGに変換され、ストアされる。 これを入れている場合、サーバーからすればAVIFをアップロードされるのは負担が増えるのであまり嬉しくない。

このフィルタが入っていない場合は、AVIFはAVIFのまま配置される。

なお、このフィルタを外しても、ファイル名は維持されず、Hex Hashっぽいファイル名に変換される。

AVIFはAVIFのままであった場合、ローカルでは当然ながらAVIFのまま画像として配信される。 つまり、見られるかどうかはユーザーの環境がAVIFに対応しているかどうかに依存する。

リモートではどうなるか。

Pleroma/Akkomaはリモートの画像をローカルで持たないので、AVIFのままである。 かつ、リモートのAVIF画像はPleroma/Akkomaでは画像として認識されない。 単なるファイル扱いになり、ダウンロードは可能。

Misskeyの場合は、リモートの画像をローカルで持つかどうかの設定がある。

ローカルで持つようになっていた場合、WebPに変換され、WebPで配信される。 これは、Misskeyローカルを含むデフォルトの挙動である。

ローカルで持たないようになっている場合、AVIFのままリンクとして配信される。 このため、ローカルと同じく見られるかどうかはユーザーの環境による。

Mastodonでは「利用できません」と表示され、見ることができない。 ダウンロードは可能。

WebPの場合、ストアされ方と配送方法は同じ。 AkkomaではWebPはリモートのものでも問題なく表示可能で、Mastodonも4.1.4だと表示可能だった。

このため、AVIFよりもWebPを使うほうが良い結果になりそうだ。 AnonymizeFilenameを外して容量低減を狙うならWebPを使うようにアナウンスしていくのが良さそう。

バブルタイムラインの活用

バブルタイムラインは、連合タイムラインの指定ドメイン限定版だと思えば良い。 サーバーが持っている公開投稿の中で、指定したドメインのものだけが掲載される。

ここに「親和性は高いが、独立した存在である必要はある」程度のインスタンスを書いておくと、拡張公開タイムラインのような感覚で使える。

ただ、Akkomaはリストに入れても他サーバーの投稿を取りにいったりはしないし、サーバーに届いている投稿だけの話になるので注意が必要。 それなりにユーザー数が多くないと機能しない。

MRF? ドメインブロックはどこに?

Pleromaのドキュメントを参照。

Pleroma/Akkomaは通常、単一のユーザーがなにかをしたことで重くなるようなことはないようになっているが、MRFを書くと話が違ってくる。 利用に対しては注意深くなったほうがいい。 インスタンスを深くカスタマイズしたい場合向け。

PleromaでMRFを使ったことがないため、Akkoma側でカスタマイズされているのかもしれないが、Admin-FEではそこそこ扱いやすくなっている。

インスタンスをブロックしたい場合はAdmin-FEの “MRF” セクションで “Policies” として SimplePolicy を選択すれば良い。 すると項目が出てくるので、 “Reject” に対象インスタンスを追加する。ちなみに、reasonセクションもある。 reasonセクションがどのように機能するのかは知らない。 MRF Transparencyが有効な場合に表示されるのかもしれない。

MRFを作ると、結構な部分でAkkomaそのものをいじらなくてもインスタンスのカスタマイズができる。

ルーナノヴァ…？

プレースホルダーの日本語文はPleroma-FEのsrc/i18n/ja_pendantic.jsonにあるのだけど、ビルドしたものは組み込まれた状態になっているのでどうにもならない。

どうしてもという場合はこんな感じのスクリプトで対応。 pleroma-feディレクトリで実行する。

#!/bin/ruby

unless Dir.pwd.split("/").include?("pleroma-fe")
  abort "Use this script under pleroma-fe directory."
end

FIX_MAP = {
  "ただいまルーナノヴァ魔法学校に到着しました" => "注目！ 今からすごいことを言います！",
  "例: 岩倉玲音" => "例: アルティメットアンコサークル"
}

target_files = []

FIX_MAP.each do |original, replace|
  IO.popen(["grep", "-Flr", original]) do |io|
    io.each do |line|
      target_files.push line.strip
    end
  end

  target_files.each do |fn|
    data = File.read fn
    data.gsub!(original, replace)
    File.open(fn, "w") {|f| f.write data}
  end
end

日本語はある程度できなくはないけど、英語は無謀。 これも完全とは言えない。

ちなみに、「ルーナノヴァ魔法学校」というのはアニメ「リトルウィッチアカデミア」に登場するものだそうで、Akkoma自体がその作品に出てくる主人公の名前に由来しているらしい。 そのこともあり、Akkomaのロゴは”Akkoma Witch”である。

ありがちなミス

Pleroma-FEの上書き

アップデート作業でPleroma-FEのインストールが書かれているのだが、これをするとPleroma-FEのディレクトリがまっさらから作り直される。この中で注意が必要なのが、themesが消えてstyle.jsonも元に戻ること。

themesは退避しておいて、rsync -av --ignore-existingするのが無難。

style.jsonに関してはそもそもユーザー定義の部分は分けてまとめておき、退避してアップデート後にcatしてコピペ&修正する方法をとっている。

MIX_ENV忘れ

export MIX_ENV=prodしておく必要があるが、手順の中にあるsystemctlが普通はAkkomaのユーザーがsudoersにいないため、sudo systemctlが効かず一旦rootに戻ったりする。

そうすると環境変数が失われるため、$MIX_ENVのセットし忘れが発生したりする。

私は.zshrcにexport MIX_ENV=prodと書いて対応している。

アプデ作業

公式のままだけれど、よく確認することになるのでここに再掲。 手動インストールの想定。

  • Akkomaユーザーのシェルを獲得
  • export MIX_ENV=prod
  • git fetch
  • ツリー更新 git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)
    • masterやdevelopを使っている場合は git pull
  • mix deps.get
  • mix compile
  • Akkoma止める sudo systemctl stop akkoma
  • mix ecto.migrate
  • Akkoma動かす sudo systemctl start akkoma
  • Pleroma-FEの更新
    • themesとstyle.jsonを退避 rsync -av instance/static/frontends/pleroma-fe/stable/static/{style.json,themes} instance/backup/
    • mix pleroma.frontend install pleroma-fe --ref stable
    • themesを戻す rsync -av --ignore-existing instance/backup/themes/ instance/static/frontends/pleroma-fe/stable/static/themes/
    • style.json を修正

公式ではリリースタグを使うようになっているけど、基本的にはmasterで良さそうではある。

systemctlするために、私は2つのシェルで入っている。 GNU ScreenやtmuxやByobuを愛好している人なら、rootでターミナルマルチプレクサを使うといいかもしれない。 私はGNU Screenを使っているのだけど、最近Zellijを使い始めた。Zellijは設定しなくてもScreenよりだいぶユーザーフレンドリー。