meta(0.5.0): plan miso-chat for OpenClaw-as-MCP and multi-provider message-plane

[itsmiso-ai]

Title: meta(0.5.0): plan miso-chat for OpenClaw-as-MCP and multi-provider message-plane

OpenClaw is moving toward also being an MCP-capable message layer, which changes how miso-chat should evolve.

This should push miso-chat toward a capability-driven operator UI for OpenClaw-backed conversations, instead of letting provider-specific assumptions leak into the core product model.

Why this matters

• OpenClaw can become the universal transport/control layer across a wider set of message providers
• miso-chat should not hardcode product behavior around any one provider or one legacy message channel path
• the UI should branch on capabilities and normalized events, not provider strings wherever possible

Planning goals for 0.5.0

1. Treat OpenClaw as the message-plane source of truth

• Keep miso-chat focused on operator/UI concerns
• Avoid duplicating transport/provider routing logic in the app
• Prefer backend capability discovery over frontend provider-specific branching

2. Define a capability contract
   Session/message capabilities should be explicit and drive the UI, e.g.

• can_reply
• can_edit
• can_react
• can_send_attachments
• can_quote_reply
• can_thread
• can_abort
• supports_presence
• supports_voice

3. Define a normalized event contract
   miso-chat needs a stable event envelope for timeline/state updates across providers, e.g.

• message created
• message updated
• reaction added/removed
• typing/presence
• delivery/read state
• attachment available
• run started/completed/failed
• tool approval required

4. Harden the timeline model for partial capability parity
   Different providers will have weird edges. The UI must degrade cleanly when some features are missing or partial:

• replies available but edits unavailable
• text yes, attachments no
• inbound-only channels
• delayed or missing delivery state
• no stable threading

5. Separate core timeline model from provider decorations
   Keep one coherent conversation model, then layer on optional decorations such as:

• quotes
• reactions
• thread markers
• provider badges
• delivery state
• system/runtime events

6. Surface OpenClaw-native runtime concepts cleanly
   Do not flatten everything into plain chat bubbles if richer runtime state exists. We should plan to expose:

• tools used
• approvals pending
• session/runtime status
• structured events
• agent identity/mode

7. Keep provider metadata explicit but non-authoritative
   It is still useful to expose metadata such as provider/surface/chat-type/remote IDs for debugging and UX hints, but core behavior should prefer capabilities over provider-name switches.

8. Tighten auth/session ownership boundaries
   If miso-chat fronts a wider provider graph through OpenClaw, access boundaries matter more:

• session authorization should be explicit
• channel/session access control should be explicit
• provider account binding/impersonation risks should be reviewed early

Proposed 0.5.0 deliverables

• capability schema for sessions/messages
• normalized event envelope for timeline updates
• UI audit to remove provider-hardcoded assumptions from core flows
• timeline rendering that gracefully handles unknown or partial capabilities
• OpenClaw-native status/abort/approval/runtime affordances
• attachment model review for cross-provider behavior
• provider metadata layer for debug/context without driving most product logic

Anti-goals

• Do not build fully custom UI behavior per provider unless unavoidable
• Do not overfit to one MCP implementation detail too early
• Do not assume feature parity across providers
• Do not move product logic into provider adapters if OpenClaw can normalize it upstream

Open questions

• What capability/event surfaces should be guaranteed by OpenClaw vs treated as optional?
• What minimal runtime state does miso-chat need to render a good operator experience?
• Which existing UI paths still branch on backend/provider assumptions and should be generalized first?
• How should attachments, replies, and system/runtime events be represented in a unified timeline?

This issue is for planning and scope-shaping the 0.5.0 direction, not for implementing provider-specific features yet.