Is one host with multiple frontends (Web + IM bot) a supported architecture?

[Acache]

Question

Is one dsh host with multiple frontends (e.g. the Web UI and an IM bot) a supported architecture, or is the intended shape one host per frontend?

I am not asking for a feature commitment — a clear "one host per frontend is the contract" is a useful answer. I would like to know which way the architecture is pointing before investing further in a fork.

Why I am asking

I use the Web UI daily and also want Feishu (via the @dsh-feishu/dsh-feishu bundle). The documented pattern runs the Feishu bundle in its own profile, i.e. a second host with its own session store. That works, but the two hosts cannot see each other's sessions: a conversation started in Feishu is invisible in the Web UI, cross-frontend /resume does not exist, and approvals/questions are pending only on the side that raised them.

For a personal assistant, "same conversation from either frontend" is the whole point, so I built a local fork of the Feishu plugin that mounts into the web profile and shares the host. It works (shared session map, broadcast approvals with first-answer-wins, external-turn mirroring, tool scoping, log de-duplication), but every one of those behaviours is a guess about a contract that I could not find documented.

What a contract would need to define

If N frontends per host is supported (or planned), these are the questions a frontend plugin has to answer, and today each plugin answers them differently:

1. Session ownership — one store per host, so any frontend can create/resume; how are id collisions handled when a frontend resumes a session that already exists on another frontend?
2. Event fan-out — does every mounted frontend observe every session event, or only sessions it created/bound? Is there a subscription seam, or is it "whatever the plugin can reach on ctx"?
3. Interactions — approvals/user-questions are single-answer. Is "broadcast to all frontends, first answer wins, cancel the rest" a host responsibility, or does each frontend have to implement it?
4. Tool scoping — host-wide registries (tools, commands, exporters) leak into every session. Is there a supported way for a frontend to scope a tool to the sessions it owns (we use tools.restrict on agents not bound to a chat)?
5. Lifecycle — is mounting a frontend plugin into an already-running host (hot mount / profile reload) a supported path with defined disposal semantics?
6. Isolation — a co-hosted frontend shares the process: is the blast radius (one plugin bug takes down the Web UI) considered acceptable, or is process isolation the intended safety boundary?

Trade-offs I can see

• One host per frontend is simpler, isolates failures, and keeps each frontend's assumptions local — at the cost of duplicated state and no cross-frontend continuity.
• N frontends per host gives continuity and a single registry — at the cost of shared failure domains, ambiguous interaction semantics, and a larger surface for every frontend plugin to get right.

Note on terminology

By "frontend" I mean the thing a plugin like @dsh-feishu/dsh-feishu is: the UI binding for a conversation (Web page, IM bot). I am aware surface already has a different, specific meaning in the session subsystem (the ordered projection over the event log), so I am avoiding that word here.

What I will do with the answer

• If N-per-host is supported/planned: I would rather upstream the co-hosting behaviour (or a minimal version of it) than maintain a fork, and I can open a design note / incremental PRs against @dsh-feishu/dsh-feishu.
• If one-host-per-frontend is the contract: I will keep the fork, document it as unsupported, and stop proposing it.

[lubenkov]

Your co-hosted fork demonstrates that this is possible, but it doesn’t establish a supported public contract. I’d treat it as experimental until the maintainers confirm session ownership, interaction arbitration, tool scoping, and hot-reload semantics.

For now, I’d keep the integration behind an adapter and add regression tests for simultaneous approvals, reconnect/resume, and plugin disposal. Separate hosts remain the safer isolation boundary, but they won’t give you shared session continuity.

[Acache]

still sounds like a trade-off

[lubenkov]

Fair, it is a trade-off, and that's the honest answer while no contract exists. But what is guaranteed today isn't a trade-off, it's a fact: nothing, which is why the fork is experimental rather than wrong.
The sharper test that actually answers your question: for each of your six seams, can it be implemented inside a frontend plugin without patching the host? If yes to all six, N-per-host is just undocumented and the fork is an upstream candidate. If even one needs host internals - approvals as a host broker, defined disposal on hot unmount, then one host per frontend is the contract by default, not by preference. That's checkable by reading the code and doesn't depend on anyone's view of blast radius.
So post the useful artefact: which host files your fork had to change, and which of the six you got through public ctx alone. That decides whether the gap is docs, a small API, or a redesign. And it's what I'd need before calling it supported