fix

content/post/MatrixでDiscordSlackを所有する.md

@@ -1,22 +1,23 @@
 ---
 title: "MatrixでDiscord/Slackを所有する"
-date: 2023-10-01T10:50:58+09:00
-draft: true
+date: 2023-10-01T20:36:58+09:00
+draft: false
 tags: ['tech']
 ---
 
 ![](/img/212.png)
 
-先日のDiscord障害は週末夜を電脳空間で過ごそうと決めていた人々を絶望の淵に叩き込んだ。きょうびオンラインゲームをやるとなったらボイスチャットによるコミュニケーションはほぼ必須であり、とりわけDiscordは当該の分野で支配的な地位を占めている。なお、僕は一人で黙々とCounter-Strike2のランクマッチを回していたので関係がなかった。静謐。
+先日のDiscord障害は華金を電脳空間で過ごそうと決めていた人々を絶望の淵に叩き込んだ。きょうびオンラインゲームをやるとなったらボイスチャットはほぼ必須であり、とりわけDiscordは当該の分野で支配的な地位を占めている。ちなみに、僕は独りで黙々とCounter-Strike2のランクマッチを回していたので関係がなかった。静謐。
 
-しかし他に寄辺のない異常独身男性が集結せしDiscordサーバを運用している立場としては、一つのサービスの死がコミュニケーションの喪失を引き起こしかねない現状はまったく好ましくない。彼らは他のSNSをあまり使わない。以前から代替ツールを模索してはいたが、企業運営の類似サービスでは面白みに欠けるし、かといってセルフホスト型だと「そのためだけのアカウント」が余計に増えてしまう。なにしろ従来の形式ではサーバごとに別のアカウントを作らなければならないのだ。
+しかし他に寄辺のない異常独身男性が集結せしDiscordサーバを運用している立場としては、一つのサービスの死がコミュニケーションの喪失を引き起こしかねない現状はまったく好ましくない。彼らは他のSNSをあまり使わない。以前から代替ツールを模索してはいたが、企業運営の類似サービスでは面白みに欠けるし、かといってセルフホスト型だと「そのためだけのアカウント」が余分に増えてしまう。なにしろ従来の形態ではサーバごとに別のアカウントを作らなければならないのだ。
 
-そこで、ようやく目を付けたのがMatrixだった。技術系のコミュニティで広く使われていたり、やたら熱心な信奉者を見かけるこのプロトコルは、分散型ネットワークを形成するため一つのアカウントで他のサーバに接続することができる。友人たちに作らせるアカウントが（プロトコルの発展次第では）無駄にならないと説得しうる余地が大きい。
+そこで、ようやく手を出したのがMatrixだった。情報技術系のコミュニティで広く使われていたり、やたら熱心な信奉者を見かけるこのプロトコルは、分散型ネットワークを形成するためセルフホスト型でありながら一つのアカウントで他のサーバに接続することができる。（プロトコルの発展次第で）作ったアカウントが活かせるのは説得材料になりうる。
+
+7月に自鯖を持って以来、長らくActivityPubにかかりきりだったがそろそろ他の分散型プロトコルを触っても良い頃合いだ。さしあたり避難所的に運用してMatrixと関連エコシステムの手触りを学んでおいて損はない。本稿はMatrixのリファレンス実装サーバであるSynapseと、WebクライアントのElementを利用した構築方法について記す。
 
-7月に自鯖を持って以来、長らくActivityPubにかかりきりだったがそろそろ他の分散型プロトコルを触っても良い頃合いだ。ひとまずは避難所的に運用してMatrixと関連エコシステムの手触りを学んでおいて損はない。本稿はMatrixのリファレンス実装サーバであるSynapseと、WebクライアントのElementを利用した構築方法について記す。
 
 ## ファイルの取得と編集
-`docker`および`docker-compose`は導入済みと仮定する。まず、任意のディレクトリを作成して一階層ぶん深い位置に`docker-compose.yml`ファイルを作る。たとえばユーザ名が`matrix`の場合、`/home/matrix/1/2/`のような形になる。下記の記述例ではこの`1`に該当するディレクトリにファイル群が展開される。
+`docker`および`docker-compose`は導入済みと仮定する。まず、任意のディレクトリを作成して一階層ぶん深い位置に`docker-compose.yml`ファイルを作る。仮にユーザ名が`matrix`の場合、`/home/matrix/1/2/`のような形式になる。下記の記述例ではこの`1`に該当するディレクトリにファイル群が展開される。
 
 ```docker
 version: '3'
@@ -63,7 +64,7 @@ networks:
     internal: true
 ```
 
-`POSTGRES_PASSWORD`は`openssl rand -hex 16`などで乱数生成する。`ports`の左側はデフォルトの8008番ポートが埋まっている場合に置き換える。編集が終わったら`docker-compose run --rm synapse generate`で必要なファイル群を吐き出させる。次に、`/home/matrix/1/data/homeserver.yaml`を書き換える。
+`POSTGRES_PASSWORD`は`openssl rand -hex 16`などで乱数生成する。`ports`の左側はデフォルトの8008番ポートが埋まっている際に置き換える。変更が済んだら`docker-compose run --rm synapse generate`でファイル群を吐き出させる。次に、`/home/matrix/1/data/homeserver.yaml`の編集に進む。
 
 ```yaml
 server_name: "あんたのドメイン"
@@ -107,13 +108,13 @@ trusted_key_servers:
 suppress_key_server_warning: true
 ```
 
-大抵の環境ではドメイン部分の修正のみで機能すると思われる。`自動生成`と書かれている箇所は失うと一巻の終わりなのでバックアップをとっておく。保存後、`docker-compose down`で一旦終了してから`docker-compose up -d`で再起動を行う。なぜかたまに起動がコケるので`docker-compose logs -f`で変なエラーが出ていないか確認する。
+大抵の環境ではドメイン部分の修正のみで機能すると思われる。`自動生成`と記されている箇所は失うと一巻の終わりなのでバックアップをとっておく。保存後、`docker-compose down`で一旦終了してから`docker-compose up -d`で再起動を行う。なぜかたまに起動がコケるので`docker-compose logs -f`で変なエラーが出ていないか確認する。
 
 
 ## Webクライアントの導入
-ElementはMatrix用クライアントの一つである。他にもいくつか[種類があるが](https://matrix.org/ecosystem/clients/)今のところはElementが頭ひとつ抜けている。当初はこれも`docker-compose.yml`に加えてコンテナ化するつもりでいたが、うまく動かなかったのでビルド済みのバイナリをディレクトリに直接置く形を採った。
+ElementはMatrix用クライアントの一つである。他にもいくつか[種類があるが](https://matrix.org/ecosystem/clients/)今のところはElementが頭ひとつ抜けている。当初はこれも`docker-compose.yml`に加えてコンテナ化するつもりでいたが、うまく動かなかったのでビルド済みのバイナリをディレクトリに直接置く形を採った。公式のドキュメントでもそのやり方が推奨されているようだ。
 
-`/home/matrix/1/element`などの形式でディレクトリを作成して、そこに`wget https://github.com/vector-im/element-web/releases/download/vv1.11.45/element-v1.11.45.tar.gz`でバイナリを置く。バージョン部分は2023年10月1日時点での最新。ダウンロードが済み次第、`tar xvzf element-v1,11.45.tar.gz`で解凍する。続いて、`element-v1.11.45/config.json`の編集を行う。
+まずは`/home/matrix/1/element`などの形式で任意のディレクトリを作成して、そこに`wget https://github.com/vector-im/element-web/releases/download/vv1.11.45/element-v1.11.45.tar.gz`でファイルを置く。バージョンは2023年10月1日時点での最新。ダウンロードが済み次第、`tar xvzf element-v1,11.45.tar.gz`で解凍する。続いて、`element-v1.11.45/config.json`の編集を行う。
 
 ```json
 {
@@ -222,22 +223,25 @@ server {
 
 Cloudflareユーザでオリジンサーバ証明書を設定していない人は[この記事](https://riq0h.jp/2023/07/22/204725/)の冒頭を参考に取得することを強くおすすめしたい。他に特筆すべき点はHTTPSポートの443番以外に8448番ポートをlistenしているところで、これは他のサーバと通信する際に用いられている。
 
-同様に、`.well-known/*`の記述部分は後述の連合機能を正常に動作させる認証として働く。すべての作業が終わった後に[Matrix Federation Tester](https://federationtester.matrix.org/)にドメインを入力すると前もって状態を調査できる。必須の作業工程ではないものの、障害発生時のトラブルシューティングにはなにかと役立つ。
+同様に、`.well-known/*`の記述は連合機能を正常に動作させる認証として働く。すべての作業が終わった後に[Matrix Federation Tester](https://federationtester.matrix.org/)にドメインを入力すると前もってサーバの状態を調査できる。必須の作業工程ではないものの、障害発生時のトラブルシューティングにはなにかと役立つ。
 
-`nginx -t`で構文エラーの有無を確認して、`systemctl restart nginx`で再起動を行う。ここまでの手順に誤りがなければ設定したドメインからElementのスタートページにアクセスできるはずだ。ただし、`homeserver.yaml`で登録を無効化しているため、最初のユーザ登録はCLIで実施する。
+`nginx -t`で構文エラーの有無を確認して、`systemctl restart nginx`で再起動を行う。以上の手順に誤りがなければ設定したドメインからElementのスタートページにアクセスできるはずだ。ただし、`homeserver.yaml`で登録を無効化しているため、最初のユーザ登録はCLIで実施する。
 
 ```zsh
 docker-compose exec synapse register_new_matrix_user -c /data/homeserver.yaml http://localhost:8008 -u あんたのユーザ名 -p あんたのパスワード -a
 ```
 
-なお、パスワードに記号類を含めると正常にハッシュ化されずログインが不可能になる。これを避けるには英数字のみで作成してからWeb上で変更するか、または`homeserver.yaml`の`enable_registration`と`enable_registration_without_verification`を`true`に書き換えて初回登録もWeb上で行う。以上で構築作業は終了となる。
+なお、ここでパスワードに記号類を含めると正常にハッシュ化されずログインが不可能になる。これを避けるには英数字のみで作成してからWeb上で変更するか、または`homeserver.yaml`の`enable_registration`と`enable_registration_without_verification`を`true`に書き換えて登録もWeb上で行う。無事にログインに成功したら構築はおおむね成功と見てよい。
 
 
-## 諸機能の確認
+## 機能の確認
 最後に、Matrixプロトコルの醍醐味である連合機能を検証する。「ルーム」の横の＋ボタンから前述の`servers`に列挙したサーバに属するルームを検索できる。ルームへの初回参加には仕様上かなりの時間がかかるが、参加後はDiscordやSlackとほとんど同じように使える。
 
-設計思想の違いとして、これらはサーバと各ルームが半強制的に連動しているのに対して、Matrixはルーム単位での参加が可能な点が挙げられる。これによりユーザは単一のサイドパネル上で別のサーバのルームを一覧化できる。分散型ネットワークによって構成されている割にサーバを意識せず横断可能なのは素直に使い勝手に優れていると感じた。
+![](/img/213.png)
+（大規模Mastodonインスタンスで知られるFedibirdの雑談ルームにお邪魔したところ、さっそく鯖缶に捕捉された。）
 
-一方、DiscordやSlackでは特定のサーバの一つのルームが目当てでも、UIの都合上、サーバ単位での参加が前提なので中央集権型の割に管理が手間と感じることが少なくない。それに引き換え、Matrixは分散型でありながら高度な透過性をもたらすエコシステムを実現している。
+設計思想の違いとして、上記二つはサーバと各ルームが強力に紐付けられているのに対して、Matrixはルーム単位での参加が可能な点が挙げられる。これによりユーザは単一のサイドパネル上で個別のサーバのルームを一覧化できる。分散型ネットワークで構成されている割にサーバ全体を意識せず横断が行えるのは素直に使い勝手に優れていると感じた。
 
-企業運営にしては良心的な料金形態を持つDiscordやSlackの牙城を崩すのは難しいかもしれないが、何者にも支配されない自由な私的空間ないしは単純に避難所としてこうしたホームサーバを所有する意義は相応にあると思われる。なんにせよ、無意識に受け入れていた仕様を見直す上で競合の存在は必要不可欠に違いない。
+DiscordやSlackでは特定のサーバの一つのルームが目当てでも、UIの都合上、サーバ単位での参加が前提なので中央集権型にもかかわらず管理が手間と感じることが少なくない。一方、Matrixは分散型の利点を維持しつつも高度な透過性をもたらすエコシステムを実現している。
+
+営利企業にしては良心的な運営方針を持つDiscordやSlackの牙城を崩すのは難しいかもしれないが、何者にも支配されない自由な私的空間として、あるいは単純に緊急時の避難所としてこうしたホームサーバを所有する意義は大いにあると思われる。なんにせよ、無意識に受け入れていた様々な仕様を見直す上でも競合の存在は必要不可欠に違いない。