Chat Service

chat is the service that handles inbound/outbound chat flows.

Responsibilities

For low-risk requests with clear intent, the Agent should default to executing directly instead of repeatedly asking about event titles, default platforms, or obvious time expressions.
For time expressions like "tomorrow", "2 PM", or "2 hours earlier", the Agent should first resolve them into absolute times using the current chat timezone, then state the exact execution time in the reply.
If an action depends on system permissions or third-party connectivity (for example Reminders, Calendar, or chat delivery), the Agent should probe availability first; if blocked, it should report the real blocker instead of promising success and then asking follow-up questions.

When chat service receives a message, it first identifies the speaking user and the source platform.
Access is judged by the speaking user's permission group, not by the group chat itself.
If the user has no explicit assignment yet, the default group is used automatically.

chat authorization rules are shared globally at the city level and stored in ~/.downcity/downcity.db.
When multiple agents bind the same channel account, the same platform user uses the same role binding.
In short, bot credentials and chat authorization policy are both city-level configuration. Agents only connect channel accounts.

Full explanation: Permissions

Chat service now stores a best-effort chat display name (chatTitle) in context metadata, so Console UI can show readable names (group/channel/DM peer) instead of only IDs.
Telegram usually provides this directly. Feishu and QQ are best-effort and may be empty depending on event payloads and permissions.

city service status chat
city chat status
city chat restart