jochen
eadf301f9f
The operator would not read the Telegram ask for ADR 0343: thirty plain lines, every clause on one, no bold, no summary. A settings proposal was the same wall of text, its values masked so the approval was blind. - messenger: an ask's message is the asker's headline and explanation alone; who asked and when, what each answer does, the expiry, where else it is answered and the asker's Details travel as the message's note (asks.Message.Note). Answered, the message is one line, "You chose Approve at 16:06 on Telegram · <headline>". An explanation that does not read at a glance (asks.Glance) is shown and logged. On a kind that proves who answers, an ask's values are shown whole (asks.Ask.Whole), held to the secret rule alone (from the earlier work on issue 383, #178). - telegram: every message in HTML, never reworded: the title bold, a key line monospace, the note apart in a collapsed blockquote; markup escaped. A tap is compared by its words, whitespace aside, and a message shown before is still compared by the digest it was kept under. - desk-channel: the note follows the body. - mesh-knowledge: a record that needs the operator carries a brief (headline, summary, at most three points), the 30th per-record rule; its ask shows the brief and never the clauses. An ask made before is composed again as it was asked (form), so its warrant still holds. - claude-code: an instructions proposal's explanation is one summary line (the proposer's, or the module's), its text in the Details; a question's context is at most 300 characters and its recommendation one point. Older proposals and questions keep their form. The SDK is pinned at mesh-sdk 9588871 (fix/639-an-ask-reads-at-a-glance), which adds Message.Note and asks.Glance.
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 noverified-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. When the
notifier's bundle starts again on a machine (
dunst.started), its notifications stay on screen and the answers they waited for are lost: the desk keeps their ids and says in its standing when that happened (answers-lost-at); the router, which alone knows what is still open and unanswered, says that again under its handle, replacing the notification in place so its buttons work again. Nothing resolved, silenced or cancelled comes back. - 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 asendorshowunder a handle already shown (a reminder, an escalation), replace that message's notification on each machine by its id (the notifier'sreplace_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
secretto the notifier, which sends it transient in the categorymesh.secret: dunst's rules keep it out of its history, andnode-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 |