design(runtime): define inbound event handling boundary for uxc

[jolestar]

Summary

Define the product boundary for inbound messaging and event handling in uxc.

Now that uxc subscribe supports several long-lived subscription flows, the next question is whether message-receive behavior for IM systems should live inside uxc itself or be left entirely to higher-level apps.

Recommendation

uxc should own the generic inbound/event runtime primitives, but not the IM-specific bot/application logic.

In other words:

• uxc should provide reusable runtime capabilities for receiving and normalizing inbound events
• higher-level apps, skills, or agent workflows should decide what to do with those events

What belongs in uxc

These are protocol/runtime concerns, not product-specific IM logic:

• daemon-backed subscription lifecycle
  • start / list / status / stop
• transport/runtime support for long-lived inbound flows
  • WebSocket
  • SSE / NDJSON / streaming HTTP
  • polling-style subscriptions
  • webhook receiver runtime
• reconnect / retry / heartbeat / stop semantics
• event envelope normalization and sink integration
• auth / signature verification where it is protocol-level and reusable
• checkpoint/cursor support where the upstream protocol needs it

These capabilities are useful beyond IM systems, including market data, MCP resource updates, GraphQL subscriptions, and other event-driven APIs.

What should stay out of uxc

These are higher-level application concerns:

• bot command routing
• conversation memory
• mention/reply semantics
• moderation policies
• agent orchestration logic after a message is received
• product-specific workflow behavior for Slack/Telegram/Discord/etc.

Those belong in skills, agent workflows, or external applications built on top of uxc.

Why this boundary matters

If uxc does not grow generic inbound runtime support, it will remain biased toward request/response APIs and be weaker for real-world event-driven systems.

If uxc tries to absorb IM-specific bot frameworks directly, it will lose its identity as a general execution surface and become a product-specific bot platform.

The right boundary is:

• generic inbound runtime in uxc
• provider semantics in skills/integrations
• end-user bot/app behavior in higher-level systems

Candidate follow-up tracks

• polling runtime for APIs such as Telegram getUpdates or Matrix /sync
• webhook receiver runtime for provider callback-based systems
• richer sink/runtime orchestration after inbound events are captured
• provider-specific IM skills that reuse these primitives

Non-goals

• This issue does not commit to building a full IM bot platform in uxc
• This issue does not decide the exact CLI surface yet
• This issue is about product boundary and architecture direction