SSE (text/event-stream) framing for event streams

[goelakash]

What this is

A question about whether Smithy should be able to model event streams framed as Server-Sent Events (text/event-stream), and if so, how the trait should look. I've built a TypeScript prototype and want maintainer input on the design before it goes further.

What I can state

• Smithy models event streams with @streaming unions. In the implementations I looked at (smithy-typescript and smithy-java), the on-the-wire framing is the binary application/vnd.amazon.eventstream encoding. I have not checked smithy-rust, smithy-python, or smithy-go, so I can't claim SSE is absent ecosystem-wide — please correct me if it exists somewhere.
• In smithy-java, text/event-stream appears only inside the MCP proxy (HttpMcpProxy), not as a modeled protocol for @streaming unions — its rpcv2 event-stream path sets application/vnd.amazon.eventstream.
• I could not find a way to model SSE framing in Smithy today. If there is one, this discussion is moot and I'd appreciate a pointer.

Prototype (TypeScript only)

I have a working prototype in smithy-typescript (PR smithy-lang/smithy-typescript#2177, tracking issue #2176): an SSE event-stream marshaller with the same interface contract as the binary one, plus an experimental sseJson protocol behind an opt-in flag. In TypeScript, the typed @streaming union and per-event serde were reusable unchanged — only the wire framing differed. I don't know whether that reuse holds in other languages.

Questions

1. Is there existing support for SSE-framed event streams anywhere in Smithy that I've missed?
2. If not, is this something Smithy wants — as a first-class protocol trait, or a framing modifier on existing HTTP protocols?
3. Wire mapping: is event: = Smithy event-type name reasonable? How should modeled exceptions and the unmodeled/$unknown case be represented?
4. Should this be designed in core so all languages stay consistent, or is a per-language protocol acceptable?

I'm not asserting SSE belongs in Smithy — I'm asking. Happy to adapt or drop the prototype based on the answer.

---

Earlier discussion thread on this topic: #3221.

[kuhe]

1. No
2. This type of feature request has to go through the Smithy team and not me (a TypeScript-specific maintainer). I believe they'll want you to go through internal channels rather than having the conversation on GitHub. It's not a secret or anything, just faster.
3. TBD pending Smithy team review of the proposal
4. I believe it will have to be a specification update if accepted, which the individual languages will have the option of implementing.

[mtdowling]

What's the pitch for why we'd add SSE?

[goelakash]

Thanks @kuhe, I'll reorient this ask towards the core Smithy group.

@mtdowling SSE is used to stream tokens over an open HTTP channel by agents to UIs. This is a popular contract (e.g. AG-UI) for chat-based interfaces that connect directly to Agents/LLMs responding to requests. My understanding is that building a Smithy based service model currently doesn't support such a protocol/contract. Since my focus is to build lightweight TS based apps (and not Java/Rust based systems), smithy-ts seemed like the place to first start this conversation.

[goelakash]

I have a discussion post here as well: #3221