# sloppy-logs

雑なログやメモ。更新の見込みのないスナップショット的な記録の置き場。

# 2023-10: 自分用 PixelFed サーバを立てようとしたが、やめた

## 結論

PixelFed v0.11.9 は個人用に導入するには早すぎる。将来に期待できる可能性はあるので様子見はしたいが、立てるとしても今ではない。

## 文脈

### PixelFed とは

写真の投稿に特化した、 ActivityPub による distributed SNS 実装。 Instagram クローンなどとして見られているらしい。

2023-10-08 時点での最新リリースは v0.11.9。

### なぜ立てようとしたのか

#### 写真

近々写真を撮りまくることになりそうな予定が入ったため、 Mastodon の汎用アカウントに投げまくるよりも専用のアカウントがあった方が勝手が良いのではないかと考えた。そもそもせっかくちゃんとしたカメラを持っているのだから、いくら出不精といっても使わなければ損であり、サーバを立てればカメラを使う動機にもなるやもしれぬと思った。

#### ゲームのキャプチャ

ゲームプレイのキャプチャ画像も連投したり後からまとめて一覧したくなったりなどが考えられるため、汎用の SNS としての Mastodon 実装ではなく画像専用の実装を使った方が都合が良さそうに思われた。

## 解決したかった課題

画像を投げる専用の ActivityPub 実装が欲しかった。

画像特化となると欲しいのは次のような機能。

- 投稿一覧で画像が主役になっている。
- 撮影してからのアップロードが楽。
- Mastodon のメインアカウントから参照・拡散しやすい。 
    - Mastodon でなくとも、 ActivityPub に乗っていれば将来的に collections に突っ込むようなことができるかもしれない。
- (Optional) 実写の写真ではなくゲームプレイのスクリーンショット等であっても問題なく扱える。
- (Optional) 合理的な範囲のコストでメンテナンスできる。
- (Optional) Docker 等で運用でき、リソースが余ったり不足したりした場合に別のホストへ簡単に移動できる。

## 検討した選択肢

### Mastodon アカウントをそのまま使う

画像が一級市民ではない実装であり、あまり画像を蓄積する場として使うには望ましくない。

たとえば画像一覧でサムネイルが小さいとか、あくまで投稿の中に画像が埋め込まれているのであって画像がメインでキャプションが付いているというスタイルではないとか。

### PixelFed サーバを立てる

画像を主役とした ActivityPub 実装なので、これが使えるならこれが望ましかった。

### SNS スタイルではないギャラリーソフトを使う

スタイルとしては、あり。

ギャラリーソフトは無数にあるのでまず選定が面倒で、次にメタデータ (せめてキャプション) 付きのアップロードが簡単でないと画像の追加すら面倒という問題がある。これをクリアできる実装に今のところ心当たりがない。探せばあるのかもしれないが。少なくとも条件を緩くすれば無数にあるのは間違いない。

#### Nextcloud Photos

ファイルの保管と公開を同時に行える実装として Nextcloud Photos も考えられたが、ギャラリーを特定フォルダのみに限定するなどが不可能らしいこと ([nextcloud/photos#141](https://github.com/nextcloud/photos/issues/141))、Nextcloud の Android client の auto upload や同期の挙動がマルチアカウント環境下で信頼できないこと ([nextcloud/android#11088](https://github.com/nextcloud/android/issues/11088))、また過去にアップグレードに伴うマイグレーションを雑にやって失敗しデータを飛ばしかけたことがある経験などから、 Nextcloud には最低限の機能しか与えたくなかったので却下した。

### 公開しない

べつに公開する必要はないが、自己引用したかったり未来において参照したくなったときなどに便利そうなので、躊躇う理由がなければできるだけデフォルトで公開しておきたい。

## PixelFed で遭遇/発見した問題

致命的とは限らないが、とりあえず列挙しておく。

### 公式 Docker image がメンテされていない

一応 Dockerfile と docker-compose.yml (not compose.yaml) はリポジトリに含まれているのだが、ちゃんとメンテナンスされている形跡がない ([pixelfed#3337](https://github.com/pixelfed/pixelfed/issues/3337), [pixelfed#4517](https://github.com/pixelfed/pixelfed/issues/4517), [pixelfed#4521](https://github.com/pixelfed/pixelfed/issues/4521))。公式ドキュメントにも情報がないため、「プルリクか実験でとりあえず突っ込んではみたが、誰もマトモに使っていないし公式の手段として提供されていない」といったあたりだろう。

べつに Docker 対応がないこと自体に何か致命的な問題があるわけではなく、単に運用しづらくなるだけなのだが、シングルバイナリでもなくミドルウェア依存の強い (LAMP/LEMP) web アプリで Docker 非対応、しかも outdated なファイルがずっと残っている、というのは率直に言って不安である。

### 無劣化最適化がない

jpegoptim や optipng は画像を無劣化で (つまり、最適化によって余計に情報を失うことなく) 最適化することができるが、 jpeg に対して敢えて lossless 最適化を無効化しているようである ([config/image-optimizer.php at v0.11.9](https://github.com/pixelfed/pixelfed/blob/v0.11.9/config/image-optimizer.php#L16-L31))。設定で無劣化にできるといった様子もなく、「サイズは気にしないしユーザは自分だけなので、画質について妥協しない」という選択肢は存在しないらしい。

さらに言えば、そもそも最適化を無効にするオプション自体がまともに機能していないようだ ([pixelfed#1797](https://github.com/pixelfed/pixelfed/issues/1797))。

### リポジトリのファイルパーミッションが微妙

マニュアルでは以下のようにしてリポジトリ内のファイルのパーミッションを設定せよと書いてある。

```bash
cd /usr/share/webapps # or wherever you choose to install web applications
git clone -b dev https://github.com/pixelfed/pixelfed.git pixelfed # checkout dev branch into "pixelfed" folder
```

```bash
cd pixelfed
sudo chown -R http:http . # change user/group to http user and http group
sudo find . -type d -exec chmod 755 {} \; # set all directories to rwx by user/group
sudo find . -type f -exec chmod 644 {} \; # set all files to rw by user/group
```

だが、これをそのまま実行するとリポジトリ内の 100755 権限のファイルのパーミッションが変更され、 git 側から差分として検出されて次回の git pull で unstaged changes があると文句を言われてしまう。これ自体は `git config --local core.filemode false` で無視できるが、根本的に、理想的な状態でないパーミッションのファイルがリポジトリ内に放置されていること自体が望ましくないといえる。

100755 なファイルとしては、たとえば Docker コンテナ内に置く用のスクリプトや public/img/icon/ 以下の諸々の SVG ファイル等) がある。前者で実行可能ビットが立っているのは妥当だが、後者については明らかに望ましくない。おおかた Windows か何かで編集したファイルをそのまま git に突っ込んだのであろう。

また、コメントの "set all files to rw by user/group" も間違っていて、コードでやっていることは user のみに write 権限を持たせる処理だし、本来の意図としてもそちらが正しいはずだから、ドキュメント用に追加された補足コメントだけ雑に書かれているということになる。実害はないが、どうなんだそれは。

### Postgres 対応？ 非対応？

ドキュメントでは Postgres に対応しているような記述になっているが、どうやらバグが多いらしい ([pixelfed#2727](https://github.com/pixelfed/pixelfed/issues/2727))。 YunoHost で楽してホスティングしようとした人は Postgres を使っていることがあるらしく (デフォルトかは知らないが)、却ってトラブルを抱え込んでいる様子が見受けられる。

これについては MySQL/MariaDB を使えばよさそうで DB 移行も一応スクリプトか何かからのエクスポートとかで対応可能なようなので回避策はあるが、なんにせよ品質面で不安に思うには十分である。

### 意外とメモリを食う？

[https://lemmy.world/comment/313181](https://lemmy.world/comment/313181) によれば、 2023-06-18 時点で、 load average では問題ないがメモリが 1 GB では心許ないらしい。ユーザ規模やデータ規模が不明なのでなんともいえないが、不安要素には違いない。

> I just set up Pixelfed myself. I’ve got it running on a 1GB Linode. Would definitely recommend at least 2GB RAM, because mine is using swap like there’s no tomorrow.
> 
> Processor wise, one core seems to be OK. My load averages are 0.11-ish.

ちなみに Linode の 1 GB というのは、「共有 CPU プラン」のことだとすると Nanode 1 GB ($5/mo.) で RAM 1 GB, CPU 1 core, ストレージ 25 GB である。

## 総括

何か一発で却下とするような致命的な問題があったわけではないが、インストール段階で既に複数の「それはどうなんだ」案件に出会したこと、永続するデータをホストするための長期的な運用を視野に入れていること、既存の Mastodon アカウントという代替手段を既に持っていることから、今回 PixelFed サーバを自分用に立てるのは見送ることにした。