Files

T

elton 509475e17a mmnotify: der Rueckweg aus dem Teamspace, als Werkzeug

Andreas: "kannst du neben dem goimapnotify einen mmnotify daneben setzen?
das waere doch genau das werkzeug, was wir nun fuer alle brauchen. Auch
gerne in go, auch gerne sehr robust, automatischer wiederaufbau und so."

Dieselbe Bauform wie goimapnotify: ein kleiner Prozess, der lauscht und
bei einem Ereignis einen Befehl ausfuehrt. Er schreibt nie selbst in
einen Kanal -- er klopft nur an, der Agent liest und antwortet mit seinen
eigenen Werkzeugen.

Zwei Wege, und der Boden ist der tragende. Der Websocket beschleunigt,
darunter laeuft ein Boden, der ohnehin nachsieht. Uebernommen aus hive
(channels/team.py) und dort begruendet: ein Strom, der still ausfaellt,
darf uns spaet machen, nie blind.

Hier ist das nicht nur Vorsicht: Gegen Mattermost 11.7.10 gemessen kommt
die Verbindung zustande, die Anmeldung wird mit status OK quittiert, und
danach kommen hello und status_change -- aber KEIN posted, auch wenn ein
anderes Konto in einen Kanal schreibt, in dem der Agent nachweislich
Mitglied ist. Ursache offen, Verdacht sind Broadcasts an Verbindungen,
die ueber ein Personal Access Token angemeldet sind. Mit dem Boden
arbeitet der Dienst trotzdem, nur langsamer.

Daraus folgt die zweite Entscheidung, ebenfalls von hive: mmnotify liest
den Beitrag NICHT aus dem Ereignis. Zwei Leser waeren zwei Antworten.

Robustheit, wo sie noetig ist: Wiederaufbau mit wachsendem Abstand bis
60 s; Herzschlag alle 30 s gegen halboffene Verbindungen; hoechstens ein
Lauf gleichzeitig, sonst loesen fuenf Beitraege fuenf Agentenlaeufe aus,
die sich ueberholen; eigene Beitraege und system-Ereignisse wecken nie.

2026-09-01 20:38:01 +02:00

3.1 KiB

Raw Blame History

mmnotify

Hört am Mattermost-Websocket und weckt einen Agenten, wenn er gemeint ist.

Gegenstück zu goimapnotify für Mail: ein kleiner Prozess, der lauscht und bei einem Ereignis einen Befehl ausführt. Der Agent liest und antwortet danach mit seinen eigenen Werkzeugen — mmnotify schreibt nie in einen Kanal, es klopft nur an.

mmnotify -conf /etc/mmnotify.json

Konfiguration

{
  "url": "https://team.42i.org",
  "token": "<persönliches Zugriffstoken des Agenten>",
  "on_mention": "/root/run-agent.sh team",
  "on_direct": "",
  "debounce_seconds": 5,
  "floor_seconds": 60,
  "ignore_users": []
}

Die Datei enthält ein Token und gehört mit 0600 dem Dienstbenutzer.

Feld	Bedeutung
`on_mention`	Befehl bei Erwähnung (`@name`) im Kanal
`on_direct`	Befehl bei Direktnachricht; leer = `on_mention`
`debounce_seconds`	Mindestabstand zwischen zwei Läufen (Standard 5)
`floor_seconds`	Nachsehen auch ohne Ereignis (Standard 60, `0` schaltet ab)
`ignore_users`	Absender, die nie wecken

Der Befehl bekommt die Ereignisdaten über die Umgebung: MM_TRIGGER (event oder floor), MM_CHANNEL, MM_CHANNEL_NAME, MM_CHANNEL_TYPE, MM_SENDER, MM_POST_ID, MM_ROOT_ID, MM_MESSAGE.

Zwei Wege, und der Boden ist der tragende

Der Websocket ist der Beschleuniger; darunter läuft ein Boden, der ohnehin nachsieht. Die Aufteilung stammt aus hive (hive_runtime/channels/team.py) und ist dort begründet: „A stream that dies quietly must make us LATE, never blind."

Hier ist der Boden nicht nur Vorsicht. Gemessen am 2026-09-01 gegen Mattermost 11.7.10: Die Verbindung kommt zustande, die Anmeldung wird mit status: OK quittiert, danach kommen hello und status_change — aber kein posted, auch wenn ein anderes Konto in einen Kanal schreibt, in dem der Agent nachweislich Mitglied ist. Ursache offen; Verdacht sind Broadcasts an Verbindungen, die über ein Personal Access Token angemeldet sind. Mit dem Boden arbeitet der Dienst trotzdem, er ist dann nur langsamer.

Daraus folgt die zweite Entscheidung: mmnotify liest den Beitrag nicht aus dem Ereignis. Es klopft an; was zu tun ist, entscheidet der Agent, wenn er nachsieht. Zwei Leser wären zwei Antworten.

Robustheit

Wiederaufbau mit wachsendem Abstand (1 s bis 60 s). Ein Server, der neu startet, wird nicht von einem Client bestürmt, der im Sekundentakt anklopft.
Herzschlag alle 30 s, Lesefrist 90 s. Eine halboffene Verbindung liest sich sonst für immer wie Stille.
Höchstens ein Lauf gleichzeitig; wer währenddessen schreibt, wird vom laufenden Durchgang mitgenommen. Ohne das lösen fünf Beiträge in einer Minute fünf Agentenläufe aus, die sich gegenseitig überholen.
Eigene Beiträge und system_*-Ereignisse wecken nie — sonst antwortet ein Agent auf sich selbst.
SIGTERM beendet sofort und sauber.

Bauen

go build -o mmnotify .

Ein statisches Binary ohne Laufzeitabhängigkeiten — gedacht zum Einbacken in das Agenten-Image, neben goimapnotify.