機能 #486
未完了統合通知チャネルの選定
nop_thread さんがほぼ2年前に追加. 約5時間前に更新.
0%
説明
私的かつ統合された通知プラットフォームとして何を使うか考えたい。
要件:
- 私的な通知を含み、基本的に公にすることは考えない
- 複数プラットフォームからの通知をまとめられること
- 自前の bot 等から通知を発信できること
- PC / 携帯端末を問わずアクセス可能であること
- 返信や mention などによって、 bot に対して簡単な指示や通知への対応を送れること
NO nop_thread さんがほぼ2年前に更新 · 編集済み 操作 #1
今のところの案:
- matrix 自前鯖
- matrix 系のエコシステムそもそも使ってないし、連合したいわけでもないのだが、敢えてこれを選ぶ価値はあるだろうか？
- ActivityPub よりはプロトコルがまとも……かもしれない？
- Mastodon 自前鯖の新規アカウント
- SNS として使っているデータベースに通知を永続的に残しておくのもどうにも気持ち悪い。
- やるなら別サーバを立てたいが、リソースハングリーなのでコストが重すぎるか。
- Mastodon 以外の軽量 ActivityPub 実装の新規鯖
- 何を使う？ そもそも適した実装はあるのか？
- ntfy
- 通知だけを考えると悪くはないが、購読系の概念にまだ馴染めずにいる。まあ本格的に使い始めれば慣れるだろう。
- 一方向の通知がメインなのでインタラクションがやりづらい。
NO nop_thread さんがほぼ2年前に更新 操作 #2
- 説明 を更新 (差分)
- 前回確認日 を 2024/10/03 にセット
NO nop_thread さんがほぼ2年前に更新 操作 #3
- 次のチケットをブロック 機能 #528: Redmine のチケットを bot にリマインドさせたい を追加
NO nop_thread さんが1年以上前に更新 操作 #4
NO nop_thread さんが1年以上前に更新 操作 #5
Conduit - Your own chat server
Matrix サーバの Rust 実装。
NO nop_thread さんが1年以上前に更新 操作 #6
- ステータス を 新規 から 進行中 に変更
- 前回確認日 を 2024/10/03 から 2024/11/13 に変更
そういえば何故 Mattermost が選択肢に含まれていないのだったか。
実装の多様性がなさそうで、かつエンタープライズ向けに限定されている機能がいくらかあるのが不安要素だったからかも。
あとは、プッシュ通知が基本である以上は通知のコンテキストは発信元のアカウントによって識別・同定されるのが自然で、敢えてチャンネルという単位で空間ごと区分するのは過剰に思われたというモデル面での違和感のもある。
言ってみれば「共通な inbox が存在せず送信者メールアドレスごとにフォルダが分かれているメール UI」のようなもので、対話ではなく通知の受信を主目的として据えるならこれは無駄に煩雑なだけである。
NO nop_thread さんが約1年前に更新 操作 #7
nop_thread さんは #note-1 で書きました:
- ntfy
- 通知だけを考えると悪くはないが、購読系の概念にまだ馴染めずにいる。まあ本格的に使い始めれば慣れるだろう。
- 一方向の通知がメインなのでインタラクションがやりづらい。
ntfy には action buttons という機能を使うと、通知自体にリアクション機能のようなものを追加できるようなので、「あとで処理するから今は視界から消し去っておきたい」のようなことを考えない場合は ntfy でよさそう。
ただ「あとでやる」を考えるとやはりサーバサイドで長期間保持されるキューがあるのが望ましい。
明らかにリアルタイム通知が重要なものだけ分離するなどして併用しても良いが……
NO nop_thread さんが約1年前に更新 操作 #8
nop_thread さんは #note-6 で書きました:
あとは、プッシュ通知が基本である以上は通知のコンテキストは発信元のアカウントによって識別・同定されるのが自然で、敢えてチャンネルという単位で空間ごと区分するのは過剰に思われたというモデル面での違和感のもある。
https://social.jlinuxer.org/objects/8fe3d14c-9cc5-4a50-b4af-a538f88400e8
通知レベルを考えるとチャンネルで分離できるのが便利という話があり、なるほどそうなると Mattermost (あるいはその類型) はかなり有力な候補になってくる。
NO nop_thread さんが約1年前に更新 操作 #9
- 前回確認日 を 2024/11/13 から 2025/06/11 に変更
NO nop_thread さんが9ヶ月前に更新 操作 #10
- 関連している 機能 #839: 情報インフラ統合インターフェース を追加
NO nop_thread さんが4ヶ月前に更新 操作 #11
そのうち確認する: UnifiedPush
NO nop_thread さんが約2ヶ月前に更新 操作 #12
#484#note-16 に書いたとおり、再び ntfy サーバを立てた。
いつぞやのアップデートでアカウントや ACL も設定ファイルで宣言的に注入できるようになっており、 ansible で扱いやすく便利になった。
NO nop_thread さんが約2ヶ月前に更新 操作 #13
- 担当者 を nop_thread にセット
- 前回確認日 を 2025/06/11 から 2026/05/26 に変更
NO nop_thread さんが15日前に更新 操作 #14
- 前回確認日 を 2026/05/26 から 2026/07/02 に変更
nop_thread さんは #note-12 で書きました:
#484#note-16 に書いたとおり、再び ntfy サーバを立てた。
機能 #484: 外形監視のセットアップ (Uptime Kuma) で使ってみての感想だが、未読フラグの解除の端末間共有ができてなさげな雰囲気があって、少々面倒かもしれない。
たとえばサービス A がダウンしていることが Uptime Kuma から ntfy で通知されたとして、この通知が端末 B, C, D にプッシュされる。
ここまでは良いのだがその先が問題で、端末 B で確認して未読フラグを下ろした後でも C, D 側では未読状態として扱われている。
イメージとしては、 ntfy はあくまでイベントのディストリビュータであって、未読フラグとかは各端末側で (状態を共有せず) 独立して持っているという感じがする。
これはちょっと私の望むものと違うかもしれない。
たとえば 機能 #528: Redmine のチケットを bot にリマインドさせたい は典型的だが、結局のところ通知を飛ばす目的は究極的には「私という単一個体が適当なタイミングで何かを認識・想起すること」であって、つまりイベントへの反応状態は端末を跨ぐ単一の状態が共有されるべきである。
端末 B を見た私は端末 C, D を将来見るかもしれない私と同一なのであって、ここで未読フラグに限らず状態管理が端末ローカルになっているというのは基本的に私の想定する用途とはマッチしていない。
その点を考えると、やはりサーバで状態を保持・管理することが前提の matrix や Mastodon や Mattermost のようなものを使うべきように思われる。
NO nop_thread さんが15日前に更新 操作 #15
nop_thread さんは #note-6 で書きました:
そういえば何故 Mattermost が選択肢に含まれていないのだったか。
実装の多様性がなさそうで、かつエンタープライズ向けに限定されている機能がいくらかあるのが不安要素だったからかも。
このような例もあって、コミュニティ版 ("Team Edition") を使い続けるにも将来的な機能制限がないと信じられないところがある。
OIDC SSO を使えないのも残念。
NO nop_thread さんが約5時間前に更新 操作 #17
ntfy の機能はやはり通知であって、TODO リスト的な使い方がしづらい。
つまり対処を後回しにする可能性のあるタスクを積むのに向いていない。
プライマリな機能としてリアルタイム通知の発信がある。
加えて ntfy の web UI やアプリには、非アクティブ期間の開いていなかった通知に未読フラグを立てて提示してくれる機能もある。しかしこの未読フラグはアプリでチャンネルを確認した瞬間に全てがリセットされるので、「この通知だけあとで再確認する」のようなことはできない。
ntfy はあくまで情報の存在を認知させたり即座の応答を要請するためのものであって、「詳細を確認したかどうか」とか「処理済みかどうか」のような状態を管理したくば他の手段を使うほかないだろう。
NO nop_thread さんが約5時間前に更新 · 編集済み 操作 #18
- 前回確認日 を 2026/07/02 から 2026/07/17 に変更
nop_thread さんは #note-17 で書きました:
「詳細を確認したかどうか」とか「処理済みかどうか」のような状態を管理したくば他の手段を使うほかないだろう。
古いものから順番に処理するとは限らないことから考えても、通知そのものをプライマリな機能とするアプリは基本的に設計思想と用途が合わないと思われる。
また、処理済みのアイテムは非表示にする機能 (名目は削除でも「アーカイブ」でも未読フィルタでも何でもよい) が欲しいことを考えると、 Matrix や Fediverse 実装も基本的には適していない気がしてくる。
時系列順とは限らない非表示や既読管理があるという点ではメールかフィードリーダが圧倒的に使いやすいものと思われるが、フィードリーダは返信等によるインタラクションが難しいという欠点があり、メールはこの点でも問題がない。
フィードリーダが何にせよ web サーバを必要とするならインタラクションもそちらで行うという手はあるが、メールベースの bot の方が本質的に非同期処理できるぶん実装は楽かもしれない？