chat should serve XMPP, and the agent should join a room rather than be built into it

Reopened. I closed this earlier today on the grounds that Discord, Telegram and WhatsApp were deleted for carrying no traffic and XMPP would be a fourth channel. That was the wrong reading, and the better one is not "add a channel" — it is replace a bespoke one with a standard, in a service that already exists.

Two separate changes

1. The model comes out of the chat service

service/chat imports internal/ai, calls ai.Ask directly, carries its own prompts.json, and its roster comment reads "who is in the room: everybody connected, and the agent." The agent is welded in.

That is the thing agent/moderate was extracted to fix — "three services asking a model what their own answer should be" — and service/chat was the package filling in that analyzer variable. It still carries its own version of the same edge.

TestNoNewServiceCallsAnAgent asserts zero and passes, because these reach the model through internal/ai rather than through agent/. The rule is enforced against the import path and the violation goes underneath it. Seven services do this: apps, blog, chat, images, news, text, web — tracked separately, because they are not all the same act (generating an image is the state images answers about; composing a reply is a judgement).

The seam already exists and works for mail: service/mail publishes that something arrived and knows nothing about who listens; agent/mail decides which agent answers and how much of the thread it is reminded of. Chat wants the same shape — service/chat says somebody spoke in a room, an agent decides whether it has anything to say.

This is not a regression for chat-with-AI. It is what removes the cap on it. Welded in, a room can only ever hold you and the agent. Once an agent joins as a participant you can have two agents with different tool scopes, or a colleague and an agent, or an agent in a room on another server, or no agent at all — which is just chat.

Do this first and on its own. It is pure architecture, testable today, and porting a chat service with a model welded into it means porting the weld.

2. Then XMPP underneath it

Rooms become MUC, the roster becomes a real roster, presence comes free, and an agent joining is a client connecting like any other.

The service stays called chat. service/mail runs SMTP, IMAP and DKIM and is called mail, not smtp — the protocol is how it is served and the name is the domain. A service called xmpp would break the naming rule the same way service/vectors would.

What has to be decided first

/chat today is "discussion rooms attached to an item" — a comment thread under a news article. A real XMPP service with rosters and presence is a different product surface. Those may be two things wearing one name, and it is worth settling what /chat is before deciding what serves it.

Why the original framing was wrong

The reach argument still holds and is worth writing down so it is not re-litigated: asim+research@micro.mu is already reachable by any person, agent, form or cron job. XMPP adds presence and latency, not reachability, and federation only pays once other instances exist.

What changed is that this is no longer a proposal to add a channel. It is a proposal to stop hand-rolling one — which is the same argument as running our own SMTP rather than integrating with a mail provider, and it makes "we run the protocols" true rather than nearly true.

Prompted by Gultsch on 25 years of XMPP, whose framing is the one that survives: communication as infrastructure, and "self-hosting is structurally possible but not strictly necessary" — which is already Mu's shape.

Start by reading service/chat and agent/moderate, then compare their boundary with service/mail and the TestNoNewServiceCalls assertion. First settle whether /chat remains item-attached discussion rooms or becomes an XMPP-style product surface; done means the architecture and service boundary are decided before implementation.