[CEP-41] Open ended streams

[ContextVM-org]

Preamble

• Title: Open-Ended Streams
• Author: @ContextVM-org
• Type: Standards Track

Abstract

This proposal defines an open-ended stream transfer profile for ContextVM using MCP notifications/progress as the framing envelope. Unlike bounded transfer in CEP-22, this proposal is intended for exchanges where no single final reassembled payload is the right abstraction, such as incremental generation, event feeds, and long-lived result streams. The proposal uses the request progressToken as the stream identifier and defines ordered stream frames carried inside progress notifications. It includes stream lifecycle control, receiver acknowledgement for bootstrap when support is not already known, and explicit keepalive and termination semantics for long-lived streams. The goal is to standardize interoperable open streaming over the existing ContextVM transport model without introducing a separate transport channel or redefining MCP semantics.

Motivation

ContextVM already supports ordinary request/response delivery well, and CEP-22 covers bounded oversized payload transfer. However, some workloads are fundamentally stream-shaped rather than bounded-message-shaped. Examples include token-by-token generation, progressive computation output, subscriptions, event feeds, and other long-running operations that produce useful partial results over time.

Without a standard stream profile, implementations are forced into ad hoc patterns for partial output, lifecycle signaling, liveness, and receiver coordination. That creates avoidable interoperability problems and increases the chance that different SDKs and services will drift toward incompatible conventions.

This proposal addresses that gap by defining a single open-stream profile that remains compatible with the existing ContextVM event transport, reuses MCP progress notifications, and aligns shared handshake semantics with CEP-22 instead of inventing a parallel mechanism.

Rationale

The design reuses MCP notifications/progress because ContextVM already carries MCP messages through Nostr events, and progressToken already provides a natural per-request correlation mechanism. This avoids introducing a second transport abstraction solely for streaming.

The proposal is intentionally distinct from CEP-22. CEP-22 is for bounded reassembly of one final logical message, while this proposal is for open-ended streams where partial consumption is part of the intended semantics.

The handshake behavior is kept aligned with CEP-22: if sender support knowledge for the exchange already exists, transmission may proceed directly after start; otherwise the sender must wait for accept before sending chunk frames. This preserves shared semantics across both CEPs and reduces semantic drift.

The framing model is minimal on purpose. It uses start, accept, chunk, ping, pong, close, and abort frames, with progress as the normative ordering field. The proposal also keeps stream liveness explicit by requiring idle-time probing through ping and pong, rather than leaving long-lived stream health entirely to local heuristics.

Security Implications

Open-ended streams can consume memory, CPU, relay bandwidth, and implementation attention for extended periods. Implementations therefore need clear limits on stream lifetime, buffering, idle handling, and concurrent active streams.

This proposal includes explicit stream termination and keepalive behavior so that abandoned or half-dead streams do not remain indefinitely ambiguous. A peer that observes idle timeout must probe with ping, and failure to receive the matching pong before probe timeout causes the stream to fail. Implementations should still enforce hard resource ceilings, including maximum stream duration or other local policy limits.

As with other ContextVM transport features, implementations must validate framing strictly, reject malformed or out-of-order traffic, and treat abort as terminal. These measures reduce ambiguity and lower the risk of resource exhaustion through malformed or intentionally abusive stream flows.

Specification

Specification PR

[1amKhush]

Hey @ContextVM-org! Thanks for drafting this (the explicit ping/pong and idle timeout semantics are a really nice additions)

I read through the spec (did draw some parallels with CEP-22). I spotted a few edge cases and minor inconsistencies we might want to iron out (soem are semantics i thought we should get consistent)

1. Mismatched type names
The spec uses "type": "open-stream" in the overview and most JSON examples, but the chunk example uses "type": "open-stream-transfer". We should probably pick one (maybe just open-stream since it's shorter) and use it everywhere so SDK implementations don't fail to parse each other's frames.

2. ping/pong spam and big nonces
Since every ping and pong is a separate Nostr event, what stops a malicious peer from spamming ping frames just to force the server to echo pongs back, doubling relay traffic?
Also, since there's no size limit on nonce, someone could send a multi-megabyte nonce in a ping that the receiver is forced to echo back. We might want to add a recommendation to rate-limit pings and cap the nonce size (e.g., max 64 bytes).

3. progress jumping because of control frames
The spec says ping and pong are frame types, and that progress must increase monotonically across the stream. This means a ping will consume a progress number. So a stream might look like: chunk (1) -> chunk (2) -> ping (3) -> pong (4) -> chunk (5).
Is it intended that progress doesn't strictly map to chunk count anymore? If so, we might want to explicitly note that receivers shouldn't use progress to count data fragments.

4. When exactly is accept required?
The spec says: "if confirmation is required for the stream, accept MUST be received before the first chunk". But it doesn't clearly define when confirmation is actually required. (e.g. Is it mandatory in stateless flows unless capability tags were already exchanged?). Clarifying this would help ensure different SDK implementations don't get stuck waiting for an accept that isn't coming.

Overall this looks really solid, just wanted to point these out! Lmk your thoughts!

[kushagra0902]

Hey @ContextVM-org ! I read the specs and felt it was great! There are a few areas that I think can have more clarity:

1. Behaviour on duplicate start: What exactly happens if, suppose a stream is ongoing and another start is sent? I think the specs should mention how this case will be handled, whether it will be a protocol error, or if it is ignored, or if the previous stream is interrupted(should not be the case ideally)
2. Are empty streams intentionally stopped, or is the case for them missed? Though it makes sense to stop empty streams but just points out that the Validation section says "MUST fail a stream if close is received before a valid monotonic progress sequence has been observed." This also flags empty streams as disallowed.

Rest of the points are well covered by @1amKhush

[kushagra0902]

One more thing that maybe scoped to a different CEP: What about we make the stream concurrent in both directions? The current CEP makes due to its global shared progress token, making it turn-based, as concurrent streaming may make a lot of collisions between progress tokens.
Does is makes sense to make the stream two-sided concurrently by introducing direction-wise progress tokens and direction-wise token tracking.
lmk your views on this idea

[1amKhush]

2. Are empty streams intentionally stopped, or is the case for them missed? Though it makes sense to stop empty streams but just points out that the Validation section says "MUST fail a stream if close is received before a valid monotonic progress sequence has been observed." This also flags empty streams as disallowed.

I think empty streams are actually allowed (mostly the wording can be improved to make this more apparent ig). Since a start frame with progress: 1 followed immediately by a close frame with progress: 2 technically is a monotonic sequence, an empty stream works. But the phrasing makes it sound like chunk frames are mandatory. We should probably reword this to something simpler like: "MUST fail a stream if frames arrive out of order (i.e. non-monotonic progress)."

One more thing that maybe scoped to a different CEP: What about we make the stream concurrent in both directions? The current CEP makes due to its global shared progress token, making it turn-based, as concurrent streaming may make a lot of collisions between progress tokens.
Does is makes sense to make the stream two-sided concurrently by introducing direction-wise progress tokens and direction-wise token tracking.
lmk your views on this idea

Regarding this, I don't think we actually need direction-wise tokens, a progressToken in MCP isn't a global shared state; it's scoped strictly to the sender of the progress. So streams are inherently one-way. If the client wants to stream audio to the server, it initiates a stream with progressToken: "client-req-1". If the server wants to stream LLM tokens back, it responds with progressToken: "server-res-1". And since they use different tokens, they can happen concurrently in both directions without any progress collisions.

Also i had another question on the CEP, a client sends tools/call with a progressToken. The server starts streaming chunks. Eventually the server sends close. But... does the server also still need to send a normal JSON-RPC response (id: 1, result: {...}) for the original request? Or does the stream replace the response entirely?

[abhayguptas]

Great draft! I was reading through the spec and the comments above, and I think there are a couple of edge cases we still need to cover regarding how this works over Nostr.

1. Detecting dropped frames (The sequence problem)
Building on what @1amKhush mentioned about progress numbers jumping due to control frames: since Nostr is inherently a lossy network (relays drop events), this creates a bigger issue. If progress is allowed to legally jump, the receiver has no way of knowing if a frame was dropped by the network or if the sender just skipped a number for a control frame.

If a data chunk gets dropped, the receiver will silently stitch together corrupted data without throwing an error.

Fix idea: We should probably add a strict, contiguous chunkIndex (0, 1, 2...) inside the chunk payload itself so the receiver can instantly detect network drops.

2. Relay spam and flow control
If a server streams data really fast, it's going to spam the Nostr relay with thousands of progress events per second. The relay will likely rate-limit or ban the server. Do we need a way for the client to say "slow down" (backpressure), or should we just add a note that implementations must throttle themselves to respect relay limits?

3. The final JSON-RPC response
Regarding @1amKhush's question about the final response: I checked the MCP spec, and it requires every request to get exactly one final JSON-RPC response. The progress stream doesn't replace it. So even after the stream sends close, the server still has to send a final { "id": X, "result": ... } to officially close the lifecycle.

The current examples in the draft stop at close and don't show the final response. We should probably add the final response to the examples so developers building this don't accidentally leave their clients hanging forever!

[ContextVM-org]

Hey guys! appreciated so much your review and comments. I went through the issues and updated the spec to address them.

Fixed the framing inconsistency and now use open-stream consistently throughout. Also clarified that accept is only conditional bootstrap confirmation, and I explicitly aligned that language with CEP-22 so there is less semantic drift between the two transfer profiles.

For keepalives, I kept abuse prevention at the local-policy layer, since that is the only place it can be enforced effectively against malicious peers. The spec now recommends bounding nonce size, with 64 bytes as the interoperable recommendation, and allows implementations to ignore, coalesce, reject, or abort on redundant consecutive ping traffic.

On sequencing, I kept MCP progress as the monotonic ordering field for the whole stream, including control frames, and made it explicit that it is not a chunk counter. To solve dropped-frame detection cleanly on lossy relays, chunk frames now carry a contiguous chunkIndex, which receivers use for payload ordering and completeness checks.

I also clarified that a second start on an already active progressToken is malformed, while multiple concurrent streams are still valid as long as each uses a distinct token. Empty streams are now explicitly allowed, so start -> close is valid.

For relay pressure, I kept transport-level backpressure out of scope for v1 and instead made it explicit that implementations should throttle conservatively and respect relay-specific policies.

Finally, I clarified the request lifecycle semantics. The stream does not replace the originating JSON-RPC response. close ends stream delivery, but the sender must still send the final MCP response for the originating request, and the example now reflects a valid MCP-shaped tool response.

Let me know what do you think!

[harsh04044]

building on @abhayguptas point about the final JSON-RPC response, the gap is more concrete from an SDK implementation perspective. when a client sends tools/call with a progressToken and the server streams chunks then sends close, the client transport has a pending correlation entry for the original request id sitting in its store. if no JSON-RPC response ever arrives, that entry leaks indefinitely (or until LRU eviction at capacity). the spec should clarify whether close signals the SDK to clean up the pending correlation for the original request, or whether the server is still required to send a normal JSON-RPC response after close. CEP-22 avoids this by materializing a synthetic final message, CEP-41 explicitly skips that but leaves the cleanup path undefined.

[ContextVM-org]

Thanks @harsh04044 But this was addressed in the latest commit of the darft. Check it out and share your thoughts again if there is other issues https://github.com/ContextVM/contextvm-docs/blob/feat/open-ended-streams/src/content/docs/spec/ceps/cep-41.md#request-completion-semantics

[harsh04044]

Thanks @harsh04044 But this was addressed in the latest commit of the darft. Check it out and share your thoughts again if there is other issues https://github.com/ContextVM/contextvm-docs/blob/feat/open-ended-streams/src/content/docs/spec/ceps/cep-41.md#request-completion-semantics

thanks for the quick update! the new "Request Completion Semantics" section addresses it clearly. looks good 👌

[1amKhush]

@ContextVM-org The spec is much more robust now! Just a couple of ambiguities that could be ironed out:

• I see that chunkindex was added as a counter to solve the out of order problem (great!), but what should a receiver do if chunks arrive out of order due to relay reordering? say for example chunkIndex: 2 arrives before chunkIndex: 1. Should it buffer? reject?
• The chunk frame says data: chunk payload but doesn't say if it must be a string, can be JSON. (imo it would be better to have this clearly/explicitly defined.)

[kushagra0902]

This new version looks pretty solid. There are one or two places where I felt more precise draft can be made (some are making the wording of the specs more concise)

• "Request-Level Activation" says a progressToken on a JSON-RPC request is mandatory; "Clients that want to permit open-ended streaming for a request MUST include a progressToken." But the stateless client-to-server bootstrap example shows the client emitting a notifications/progress frame as the opening move with no prior JSON-RPC request visible.
• What happens when a pong arrives for a nonce that was never sent, or for an already-acknowledged ping? A receiver has no guidance in such cases on whether it should abort the stream, ignore it, or log it?
• The spec says implementations MAY abort on "redundant consecutive ping frames." A sender has no way to know whether its first ping was delivered. In this case it is natural to send consecutive ping frames. Therefore instead of redundant consecutive here, we can use some rate limit, or some "n" consecutive.

Other than these points and ones mentioned above, it lgtm

[ContextVM-org]

Attached you comments. Please let me know if there are some more issues. I'll start with the reference implementation of this asap

[1amKhush]

@ContextVM-org
Hey! Just some final nitpicks that imo would make the draft cleaner in terms of logic. (went through the new version and found a few more things worth thinking about)

1. close should probably include the final chunkIndex
This is the one I feel strongest about. Now that we have out-of-order buffering via chunkIndex, when a receiver gets close, it needs to know if it has all the chunks. Consider:

• Receiver has chunks with chunkIndex [0, 1, 3] buffered (chunk 2 is still in transit or lost)
• close arrives
• The stream is now terminal, but did the sender send 4 chunks total? Or 5?

Without a lastChunkIndex (or totalChunks) field on close, the receiver can't tell the difference between "I have everything" and "I'm missing data." CEP-22 solves this by putting totalChunks in the start frame, but since streams are open-ended here, the sender doesn't know the count upfront. Putting it in close makes more sense for this profile.

Something like:
{ "cvm": { "type": "open-stream", "frameType": "close", "lastChunkIndex": 3 } }
This lets the receiver verify it has a contiguous sequence from 0 to lastChunkIndex before considering the stream successfully complete.

2. Race between close and buffered out-of-order chunks
Related to point 1: the spec says "receivers MUST NOT treat a gap alone as terminal failure while the stream remains active." But once close arrives, the stream is terminal. So if the receiver still has unresolved chunkIndex gaps at that point, what should it do?

Some of the choices i could think of were:

• Wait a bounded grace period for the missing chunks to arrive (they might just be slow through the relay network)
• Immediately fail if any gaps exist at close time

I think a short grace window makes sense since relays don't guarantee ordering, but either way the spec should probably state what the expected behavior is.

3. What does "fail" mean concretely?
The spec says "MUST fail" and "MUST cause the stream to fail" in several places (non-monotonic progress, duplicate start, malformed close), but doesn't define what failing a stream actually entails. Should the receiver send an abort back to the sender? Just clean up local state silently? Both?
A short note like "A peer that fails a stream SHOULD send abort with an appropriate reason when it is still able to transmit, and MUST release all local resources for the stream" would ensure SDK implementations behave consistently.

4. Minor: start frame metadata (optional, maybe v2)
The start frame still only carries mode: "stream". For real-world use, receivers often need to know what kind of data is coming before the first chunk. Even optional fields like contentType (e.g. text/plain, application/json-lines) or encoding (utf-8, base64) would help receivers decide how to handle chunks without guessing from the payload itself. Totally fine to defer this to a future version though!

5. Editorial: CEP-35 still missing from Dependencies
The capability advertisement section references CEP-35 but it's not listed in the Dependencies section at the bottom.

Overall this is in great shape, cool work on the revisions!