機能 #486
未完了統合通知チャネルの選定
0%
説明
私的かつ統合された通知プラットフォームとして何を使うか考えたい。
要件:
- 私的な通知を含み、基本的に公にすることは考えない
- 複数プラットフォームからの通知をまとめられること
- 自前の bot 等から通知を発信できること
- PC / 携帯端末を問わずアクセス可能であること
- 返信や mention などによって、 bot に対して簡単な指示や通知への対応を送れること
nop_thread さんが9ヶ月前に更新 · 編集済み
今のところの案:
- matrix 自前鯖
- matrix 系のエコシステムそもそも使ってないし、連合したいわけでもないのだが、敢えてこれを選ぶ価値はあるだろうか？
- ActivityPub よりはプロトコルがまとも……かもしれない？
- Mastodon 自前鯖の新規アカウント
- SNS として使っているデータベースに通知を永続的に残しておくのもどうにも気持ち悪い。
- やるなら別サーバを立てたいが、リソースハングリーなのでコストが重すぎるか。
- Mastodon 以外の軽量 ActivityPub 実装の新規鯖
- 何を使う？ そもそも適した実装はあるのか？
- ntfy
- 通知だけを考えると悪くはないが、購読系の概念にまだ馴染めずにいる。まあ本格的に使い始めれば慣れるだろう。
- 一方向の通知がメインなのでインタラクションがやりづらい。
nop_thread さんが8ヶ月前に更新
- ステータス を 新規 から 進行中 に変更
- 前回確認日 を 2024/10/03 から 2024/11/13 に変更
そういえば何故 Mattermost が選択肢に含まれていないのだったか。
実装の多様性がなさそうで、かつエンタープライズ向けに限定されている機能がいくらかあるのが不安要素だったからかも。
あとは、プッシュ通知が基本である以上は通知のコンテキストは発信元のアカウントによって識別・同定されるのが自然で、敢えてチャンネルという単位で空間ごと区分するのは過剰に思われたというモデル面での違和感のもある。
言ってみれば「共通な inbox が存在せず送信者メールアドレスごとにフォルダが分かれているメール UI」のようなもので、対話ではなく通知の受信を主目的として据えるならこれは無駄に煩雑なだけである。
nop_thread さんが20日前に更新
nop_thread さんは #note-1 で書きました:
- ntfy
- 通知だけを考えると悪くはないが、購読系の概念にまだ馴染めずにいる。まあ本格的に使い始めれば慣れるだろう。
- 一方向の通知がメインなのでインタラクションがやりづらい。
ntfy には action buttons という機能を使うと、通知自体にリアクション機能のようなものを追加できるようなので、「あとで処理するから今は視界から消し去っておきたい」のようなことを考えない場合は ntfy でよさそう。
ただ「あとでやる」を考えるとやはりサーバサイドで長期間保持されるキューがあるのが望ましい。
明らかにリアルタイム通知が重要なものだけ分離するなどして併用しても良いが……
nop_thread さんが20日前に更新
nop_thread さんは #note-6 で書きました:
あとは、プッシュ通知が基本である以上は通知のコンテキストは発信元のアカウントによって識別・同定されるのが自然で、敢えてチャンネルという単位で空間ごと区分するのは過剰に思われたというモデル面での違和感のもある。
https://social.jlinuxer.org/objects/8fe3d14c-9cc5-4a50-b4af-a538f88400e8
通知レベルを考えるとチャンネルで分離できるのが便利という話があり、なるほどそうなると Mattermost (あるいはその類型) はかなり有力な候補になってくる。