Interaction multiplexing

Posted Dec 22, 2025 16:58 UTC (Mon) by SLi (subscriber, #53131)
In reply to: Interaction multiplexing by mathstuf
Parent article: Conill: Rethinking sudo with object capabilities

> I don't see why it needs all this extra stuff. You run an agent to answer requests (polkit, passwords, etc.) where you interact (the DE, the I-ssh'd-in tmux session, etc.). Any agent can answer a request; any agent's answer is sufficient. Requests come over the standard protocols (DBus, inotify-on-a-directory) and you manage them given the UI you provide. If you want to know you're in tmux and broadcast it with `tmux display-message -c $client` (or `display-popup`) so that you don't even need the agent's session to be active, that sounds a lot simpler to me.

A broadcast model like this would probably work for a password prompt, in a sense. It would fail for other examples of the same problem class ("which DISPLAY to connect to"). Even for the password prompt, I think it does have some downsides.

First, it's not really very symmetric across transports. GUI agents work well with dbus + desktop notifications; TTY agents require explicit discovery and focus; and headless/multiplexed contexts are rather second class.

Second, I think a generally useful idea is "route this request to the same place the user typed the command". I think a broadcast model of, essentially, "route this request somewhere and hope the user notices" is sufficient for things like boot time disk unlocks, and more frustrating for interactive admin commands over ssh+tmux.

So, yes, I think the broadcast model works, but it gives up the correlation. Maybe that's sufficient.