OpenClaw Matrix push rules for quiet previews
How quiet streaming marks the finalised edit, the per-recipient override rule that notifies on it, getting the recipient's token, verifying pushers, installing and checking the rule, one rule per bot, what stays a normal notification, and the Synapse and Tuwunel notes
Quiet streaming solves half of the Matrix notification problem: the bot stops ringing on every edit. The other half is homeserver-side, because only a push rule on the recipient's account can say which edit deserves a notification. This page is for operators who self-host Synapse or Tuwunel and want that rule installed for each recipient. Here is the mechanism, the steps, the multi-bot rule, and the two homeserver notes.
The mechanism
- With the streaming mode set to quiet, OpenClaw streams the reply by editing a single preview event in place; previews are sent as non-notifying notice events, the finalised edit is marked with an OpenClaw finalised-preview property, and clients notify on that final edit only if a per-user push rule matches the marker.
- Progress mode finalises its drafts through the same path, so the same rule also fires for progress-mode finalised edits, and operators who only want stock notification behaviour use partial mode or leave streaming off.
- The prerequisites are a recipient user who should receive the notification, the bot user that sends the reply, the recipient's access token for the API calls, the bot's full Matrix ID as the sender match in the rule, and a recipient account that already has working pushers, because quiet preview rules only work when normal push delivery is healthy.
- The steps begin by configuring quiet mode in the channel block and getting the recipient's access token, reusing an existing client session token where possible or minting one with a password login request against the homeserver, exporting it for the calls that follow.
Push rules are keyed by ruleId: re-running PUT against the same ID updates a single rule.
Installing the rule
Verify pushers with the pushers endpoint under the recipient's token, and fix normal push delivery for that account before continuing if none come back. Then install an override push rule under a rule ID unique per bot and per recipient, following the finalised-preview pattern with the bot's name, whose four conditions match a room message event type, a relation type of replace, the finalised-preview property set to true, and the sender equal to the bot's full ID, with actions of notify, the default sound tweak and highlight off; replace the homeserver URL, the token, the rule ID and the bot ID, remembering that the sender is the bot rather than the recipient. Verify by fetching the same rule URL, then test a streamed reply: in quiet mode the room shows a quiet draft preview and notifies once the block or turn finishes, and the rule is removed later by deleting the same URL with the recipient's token.
Multiple bots and homeservers
- Push rules are keyed by rule ID, so re-running the install against the same ID updates a single rule, and several OpenClaw bots notifying the same recipient need one rule per bot with a distinct sender match; new user-defined override rules are inserted ahead of the server-default suppress rules, so no ordering parameter is needed.
- The rule affects only text-only preview edits that can be finalised in place: media replies, stale-preview fallbacks and final texts that would activate Matrix mentions are delivered as normal notifying messages instead.
- Synapse needs no homeserver config change, only that the push-rules path reaches Synapse through any proxy or worker layout and that the pusher process is healthy, and because the rule uses the event-property-is condition added to Synapse in 2023, older releases accept the install call but silently never match, so a finalised edit that never notifies means upgrading; Tuwunel follows the same flow with no specific config, and notifications that vanish while the user is active elsewhere point to its suppress-push-when-active option added in 1.4.2, which intentionally suppresses pushes to other devices while one is active.
OpenClaw on Matrix is the channel post this rule serves, and OpenClaw Matrix message behaviour the quiet streaming mode it completes.
One rule per recipient, per bot
The design keeps the decision on the recipient's side: the bot only marks its final edit, and each person installs a rule that says whether that marker should ring, per bot, which is why the rule ID carries the bot's name. OpenClaw Matrix accounts and homeservers covers running several bot accounts against one homeserver, and OpenClaw Matrix encryption the verification that keeps those accounts trusted.
On Diali
Matrix is on Diali’s connectable list, alongside WhatsApp, Telegram, Discord, Slack, Mattermost, SMS and voice: the homeserver account and the room allowlist are yours, the Gateway is ours. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary that applies to each connected channel.
- Quiet mode marks the final edit; the recipient's rule rings on it.
- Healthy pushers first, then the override rule.
- Old Synapse accepts the rule and never matches it.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
