このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ファミリーベーシックのスプライト表かと思ったわ
QT: https://m.huling.org/notes/9y1a6204vn [参照]

Fedibirdは、MastodonもMisskeyもローカルタイムラインを中心としたローカルコミュニティありきのサーバしかなかった状況をみて、

Mastodonは、Fediverseはそういうもの

と思われてももったいないし、もっと可能性を広げたかったので、

あえてローカルタイムラインをなくし、ローカルコミュニティ色が生じにくいいサーバを作ったのね。

コミュニティは他にたくさんあるから、それ以外を、ということで

だから、ローカルのあるサーバも大事なんだよ。

@ottoto2017 .env.productionにMASTODON_USE_LIBVIPS=trueを記述

@ottoto2017 /usr/local/lib/libvips.so.42かな。

Mastodon本体は、バージョンでいうとv4.3.0-beta.1以降で対応になります。

@ottoto2017 所有者は通常root:rootですが、permissionが-rwxr-xr-xなど誰でも読めるように設定されているかと思います。

@ms06j 感谢您的报告。目前内部错误较多，响应速度极慢。我们计划稍后留出时间进行主要维护。对于给您带来的不便，我们深表歉意。

Mastodonのデータベースを論理レプリケーションする際のハマりどころ

・いくつかのテーブルに主キーがない（accounts_tags, preview_cards_statuses, statuses_tags）ことで失敗する。

こちらのプルリクエスト以降で解決
https://github.com/mastodon/mastodon/pull/25210

・シーケンスが複製されないので、新しいDBに切り替えた時におかしくなる（シーケンスを既存IDの最大値にリセットする） [参照]

Mastodonの通知が届く仕組み

大きく2種類あります。

・Webアプリケーションのプッシュ通知（デスクトップ通知）
・アプリのプッシュ通知

デスクトップ通知は、主にPC上のブラウザやPWAのための通知の仕組みです。つまりWebUIのための通知です。

ブラウズ中に出てくる通知の求めに対して許可すると、ブラウザの裏でServiceWorkerというプロセスが常駐するようになります。

この常駐プロセスによって、ブラウザを立ち上げていない状態でも通知を受け取れるようになります。

Mastodon側は、このServiceWorkerとやりとりしてユーザーの環境に通知表示を行います。

アプリのプッシュ通知は、主にモバイル環境のiPhoneやAndroidのための通知の仕組みです。

モバイル環境の場合、AppleやGoogleのサーバを経由して通知しなければなりませんが、Mastodonはこれに直接対応していません。

そこで、各アプリの作者は、ServiceWorkerに相当する中継サーバを設置し、それをMastodonに呼びだしてもらうようにします。そこからAppleやGoogleのサーバに通知することで、アプリからの通知が可能になります。

さて、通知が届かないとか、遅れてきたりするのが何故か。

ひとつは大元のMastodonサーバの不調。

タイムラインが遅延していたり、画像のアップロードが失敗するなど、様子がおかしいときは、Mastodonサーバ本体が原因かもしれません。

ひとつは中継サーバの不調。

アプリごとに中継サーバがあり、ここが過負荷になったりダウンしていると、通知が届かなくなります。

この場合、アプリ単位で、どのサーバの通知も届かなくなります。

アプリの提供にはAppleやGoogleに開発者登録するコストはかかりますが、あとはユーザーのスマホでアプリが動いているだけなので追加コストはかかりません。でも、この中継サーバはアプリ作者がコストをかけて運用しなければなりません。

ひとつはServiceWorkerの不調。

ブラウザの背後で動いているプロセスですが、これが何かおかしい。稀にですが、間違って多重起動していて通知が二重に来る、みたいな不具合がおきることもあるようです。

ServiceWorkerの不具合の場合、違う環境ではちゃんと通知が来たりします。PCは駄目、スマホのPWAはOKなど。

これは、PCやスマホを再起動したり、ServiceWorkerを一度削除するなどの、ユーザー側での対応が必要です。