のえる @noellabo@fedibird.com

やっちゃえオササン

PostScriptでライフゲームみたいな話？
https://srad.jp/story/03/05/26/1841247/

たまにはカレーの話題もいいですね（いつもしてるじゃないですか）

□ 在庫ありますか？

複数の在庫ありますか？（□ はい / □ いいえ）

みたいに、チェックボックス付きでコメント投げられるようにしてさ、チェックで確認する習慣を定着させたらいいんじゃないかとか思うね

ナチュラルはい（それアカンやつ）

DM（ダイレクトメッセージ）がタイムラインに流れる形式が使いづらい場合は、こちらの設定で隠すようにしてください。

で、ダイレクトメッセージを確認する専用のカラムが別にあるので、そちらを使ってください。

こちらのカラムには、未読管理したり、複数の参加者がいるときにアイコンが分割形式で複数みえるとか、ダイレクトメッセージ専用の機能がついてます。

#fedibird

よし、動くようになった

これ動かねえな？？

自分のMisskeyサーバもって……たわ

バトルスキンパニックの話した？

ほー

snowflakeの生成関数とかあって、snowflakeでIDつけていくテーブルがいくつかあるよ。当初はstatusesだけだったけど、今はaccountsも連番じゃないかな？

データベースの構造を変えると運用中のサーバにもの凄く大きな負担をかけるわけだけど、それでもやるとなれば、バージョンアップ自体を諦めたり回避するためにフォークするような事態になったりするので、そこまでの価値があるかは問われているよ。それで取り下げたプルリクもある。

全てのログを飲み干そうとしたサーバ、ありましたね。

Federation Botっていう、mastodon.hostに生えていたBotがあるんですが……

検索についてはFedibirdでいろいろ実験的な取り組みをしてきたので、思うところはあるよ。

Indexableは簡易だけど雑過ぎる。細かいことはユーザーに意識させなくていいけど、プロトコルレベルではsearchableByぐらいの粒度が欲しい。

ActorとNote（あるいは他にも）のsearchableByをサポートすることによって、公開範囲と同様に意志を反映させられるようになっていて欲しい。

（※ なんならLikeにsearchableByがあったっていい）

ひとつには、フォロー関係やブロックが反映されるようにすること。ブロックした相手に見つかりたくないとか、フォロワーには検索できるようにしたいとかあるでしょう？ Fedibirdは対応してるよ？

なお、fedibird.comにアカウント情報や公開投稿を突っ込む（インデックスさせる）には、Fedibird Relay Serviceに登録すればOKで、すでにある程度実現できる。

ActorのserachableByを設定するには、Fedibirdのようにネイティブ表現できない場合は、互換のハッシュタグ表現をActorのsummaryに含めることで実現できる。

まだできないのは、この検索能力を外部提供するAPIやプロトコルがないこと。

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

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

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

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

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

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

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

ひとつはServiceWorkerの不調。

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

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

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

Mastodonの通知が届く仕組み

大きく2種類あります。

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

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

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

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

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

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

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

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

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

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

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

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