CEP Proposal: Stateless Session Discovery and Capability Learning (Informational)

[1amKhush]

This proposal introduces an Informational CEP to document stateless session discovery and capability learning behavior already used in the SDK.

Why
The behavior is currently distributed across multiple CEPs and implementation details, which makes interoperability expectations unclear.

Proposed decisions to lock:

1. Discovery replay semantics are first-message exchange in session context, not first-response-only.
2. Role-oriented discovery behavior: server discovery surface and client capability/negotiation surface are documented explicitly.
3. Local/bootstrap relay determinism remains SDK implementation profile guidance, not standards-level protocol requirement.
4. Implementations should expose known-tag accessors and raw tags for extensibility; unknown discovery tags should remain available for custom protocols.

Scope

• Add an Informational CEP as behavior source of truth.
• Add minimal references from CEP-6, CEP-19, and CEP-8.
• Add SDK docs implementation-profile note for local relay determinism.

[1amKhush]

@ContextVM-org I have defined an outline for the CEP draft. (up for review!)

CEP-25: Stateless Session Discovery and Capability Learning

Type / Intent

• Type: Informational
• Intent: Document behavior already used in SDK implementations and align cross-CEP interpretation
• Non-goal: Introduce new event kinds, new tags, or new normative protocol constraints

1. Abstract

• Describe first-message exchange discovery/capability learning behavior for stateless or handshake-light sessions
• Clarify this CEP stitches existing standards behavior and does not replace CEP-6, CEP-8, CEP-17, or CEP-19 norms

2. Motivation

• Current behavior is split across standards CEP text and SDK runtime logic
• Ambiguity today: first-response vs first-message semantics, role-specific tag surfaces, protocol vs implementation-profile boundaries, unknown-tag extensibility expectations

3. Scope

• Session bootstrap behavior model
• Role-oriented discovery surfaces
• Raw tag access and known-tag accessors guidance
• Profile boundary for SDK-local publication heuristics

4. Terminology

• Session
• First message exchange (first outbound message by each peer)
• Discovery tags
• Known protocol tags
• Raw tags

5. Behavior Model

5.1 First-message exchange negotiation

• Client includes discovery or negotiation tags on first outbound message
• Server includes discovery tags on first outbound message
• After first round trip, replay can stop unless implementation has reason to refresh

5.2 Role-oriented discovery surfaces

• Server side: metadata plus transport capability tags plus optional extension tags
• Client side: transport capability tags plus negotiation tags (for example payment negotiation) plus optional extension tags

5.3 Relationship to initialize lifecycle

• initialize and notifications/initialized remain valid recommended lifecycle semantics
• Model ensures capability learning still converges when those paths are skipped

6. Tag Handling and Extensibility

• Known protocol tags: convenience accessors recommended
• Raw tags: should remain available for extension protocols
• Unknown tags: preserve as raw tuples and avoid dropping solely because unrecognized
• Merge behavior: tuple-level dedupe guidance

7. Standards Mapping

• CEP-6: canonical announcement and discovery vocabulary
• CEP-19: support_encryption_ephemeral semantics and wrap negotiation
• CEP-8: stateless payment negotiation tags (PMI path)
• CEP-17: relay-list discoverability metadata

8. Implementation Profile Boundary

• Explicitly mark SDK-local relay publication heuristics as implementation profile, not protocol requirement
• Example profile notes:
• skip default bootstrap relays for local-only operational relays unless explicitly configured
• use relay-subset publication only for websocket targets; fallback to direct publish otherwise

9. Security / Interop Notes

• Unknown tag preservation reduces extension breakage
• First-message negotiation improves interop in stateless clients without requiring public-announcement prefetch

10. Backward Compatibility

• Fully additive documentation clarification
• No wire-format breakage
• No mandatory behavior added for existing implementations

11. Reference Implementation

• ContextVM SDK transport modules that currently implement this behavior

12. Minimal Follow-up Edits (cross-link only)

• CEP-6: wording alignment and informational CEP reference
• CEP-19: first-message phrasing plus reference
• CEP-8: stateless PMI path reference
• SDK docs: implementation-profile note for local/bootstrap publication determinism