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