jochen
cd85104988
mesh/merge-gate pass: builds desk-channel, messenger → novox; no bus step; every machine composes with the change as it did without (4 of 4 compose)
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-check-typescript.sh (typescript)
mesh/delivery superseded: a newer head of the same pull request
On 2026-10-10 the desk's notifier started again on two machines and the desk showed, from its own memory, nine old popups: resolved, silenced and cancelled ones among them. Its memory held every handle ever shown with buttons, and the router's edits (silenced, resolved) had reached only the newest handle of each problem, so the rest stood as if open. A channel's memory serves only to replace or edit a message in place. A notifier that started again lost its screen: the desk forgets that machine's notification ids and says in its standing since when the screen is new (shows-since). The router, which alone knows what is still open and unanswered, says that again on that kind: one message per problem under its handle with the words and answers of now, a silenced one edited to say so with no answers and no urgency, nothing that ended. Each move of shows-since is acted on once, and waits while the desk cannot send rather than going to Telegram. Telegram re-shows nothing on a restart (its messages stay in the chat) and says no shows-since. An edit that offers nothing and reaches no screen its message is on is taken with nothing to change; one that offers answers is said as failed, so the router says it anew.
59 lines
4.1 KiB
Markdown
59 lines
4.1 KiB
Markdown
# desk-channel
|
|
|
|
The desk as a channel of the operator's conversation: kind `desktop` of the `channel` and `intake` benches the
|
|
router (`messenger`) declares (novox/hq ADR 0258, ADR 0259). It shows the router's messages on the notifier of
|
|
each machine the operator sits at (the `node-notifier` seat), and says which button was chosen there.
|
|
|
|
- **It proves nothing about who clicked.** Any process of the operator's account can choose a notification's
|
|
action (`dunstctl action`), so its claim declares no `verified-sender`: the router offers here only
|
|
acknowledgements (Silence for a week, Details) and says in the words where an approval can be given.
|
|
- **An answer is taken only on a machine its message was shown on**, and once; a refused click is said where it
|
|
was made. A message with buttons stays until it is dismissed.
|
|
- **What it remembers is never shown again** (issue 384: on 2026-10-10 a notifier that started again was
|
|
shown nine old popups from the desk's memory, resolved and silenced ones among them). Its memory — which
|
|
notification each handle has on each machine — serves only to replace or edit a message in place. A notifier
|
|
that started again (`dunst.started`) lost what was on its screen: the desk forgets that machine's
|
|
notification ids and says in its standing since when the screen is new (`shows-since`); the router, which
|
|
alone knows what is still open and unanswered, says that again under its handle with the words and answers of
|
|
now, so it is shown anew there, once. Nothing resolved, silenced or cancelled comes back. An edit that
|
|
offers nothing and reaches no screen its message is on is taken with nothing to change; one that offers
|
|
answers is said as failed, so the router says it anew.
|
|
- A message no machine took is said to the router as failed; the router tries it again.
|
|
- **One notification per message** (issue 373): an `edit`, and a `send` or `show` under a handle already shown (a
|
|
reminder, an escalation), replace that message's notification on each machine by its id (the notifier's
|
|
`replace_id`), so a problem is one notification updated in place. An edit goes only where it was shown; a
|
|
message said again is shown anew on a machine it was not. A replace that fails on a machine keeps that
|
|
machine's notification on record, so a later edit still reaches it.
|
|
|
|
## What the operator gives
|
|
|
|
The machines to show on, as a setting: `settings` for `desk-channel` with
|
|
`{"desktop-machines": ["<the machine the operator sits at>", …]}`. Until then it says it cannot send, and the
|
|
router sends warnings to the channel that reaches the operator away.
|
|
|
|
## Where it runs
|
|
|
|
Held once for the mesh, on the same machine as the router, which is where it is assigned. **It runs as the
|
|
account `desk-channel`, in a runtime of its own, on a bus account of its own** (`runs-as`), as telegram does:
|
|
what it shows and the answers it says are out of reach of the operator's account, which agents run as. It asks
|
|
each machine's notifier through the mesh: nothing new runs on the machines.
|
|
|
|
## A link's code (the review of 2026-10-09)
|
|
|
|
- **It is shown only where it is seen.** Each machine's notifier says whether it is paused (`dunst.paused`, at
|
|
least every two minutes). A message the router marks secret is shown only on a named machine heard unpaused in
|
|
the last five minutes; while there is none, it is said to the router as failed and the desk says it cannot
|
|
send, so the router starts no link. A code held by a paused notifier would appear later, to whoever is at the
|
|
screen then.
|
|
- **It is kept nowhere.** Not in this module's state, and sent `secret` to the notifier, which sends it
|
|
transient in the category `mesh.secret`: dunst's rules keep it out of its history, and
|
|
`node-notifier.history`, which every caller of the mesh's verbs may read, leaves it out.
|
|
- **What remains**: while it is on screen, a program of the operator's account on that X display can read it
|
|
(X11 isolates no client from another). It is shown for as long as the router's code lives.
|
|
|
|
## Tools
|
|
|
|
| tool | does |
|
|
|---|---|
|
|
| `desk_channel_status` | whether it can show messages, the machines and each one's last answer, and its rules |
|