Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 197 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Server-sent events (SSE) provide a streaming notification mechanism for KERI agents to receive real-time updates from the KERI system itself, functioning as a mailbox notification service that delivers system-generated events to agent user interfaces without requiring polling.
The server-sent event (SSE) term appears in the KERI/GLEIF glossary with an extremely limited definition. The canonical sources provide only two substantive statements:
These definitions appear in multiple glossary documents (github:WebOfTrust/WOT-terms, github:keri-foundation/vlei-glossary) but offer no implementation details, message formats, API specifications, performance characteristics, or architectural context beyond this basic characterization.
Critical Acknowledgment: The source material does not contain detailed technical specifications for SSE implementation in KERI systems. What follows is an analysis of how SSE technology generally relates to KERI agent architecture based on the minimal context provided, without fabricating specifics not present in the source documents.
Server-sent events represent a standard web technology (standardized in HTML5) that enables servers to push data to web clients over HTTP. The technology is well-established outside KERI and provides:
text/event-stream MIME typeWithin KERI terminology, SSE is positioned as infrastructure for agent user interface notifications rather than a core protocol component.
The glossary references KERIA (KERI Agent in the cloud) as the implementation context where SSE would be relevant. KERIA documentation describes a three-interface architecture:
SSE would logically fit within the Admin Interface layer to provide notification delivery from the KERI system to client applications, though the source documents do not explicitly state this implementation detail.
The term "mailbox notifications" in the SSE definition connects to KERI's asynchronous messaging architecture. KERI agents maintain mailboxes for inter-agent communication, and SSE appears to serve as the mechanism for alerting client interfaces when new messages arrive. However, the source documents provide no specifications for:
Important: SSE is not part of the KERI protocol specification itself. The protocol specifications for KERI, CESR, ACDC, OOBI, and IPEX do not reference SSE. Instead, SSE represents an implementation pattern used by agent software to communicate with user interfaces.
The KERI protocol defines:
SSE operates at a different layer, providing notification transport about events occurring within KERI systems rather than defining the events themselves.
The KERIA documentation references KRAM (KERI Request Authentication Method) for "replay attack protection" on requests to KERIA agents. The specification states:
"All requests from a web client must use KRAM (KERI Request Authentication Method) for replay attack protection. The method is essentially based on each request body needing to include a date time string field in ISO-8601 format that must be within an acceptable time window relative to the server's date time."
While KRAM is described for request authentication, the source documents do not specify how (or whether) KRAM applies to SSE connection establishment or event delivery. This represents a gap in the available documentation.
The glossary defines Signify as:
"a web client (key) event signing - and key pair creation app that minimizes the use of KERI on the client."
Signify client libraries (SignifyTS in TypeScript, SignifyPy in Python) implement the "signing at the edge" pattern where:
SSE would logically provide the notification channel for agent-to-client updates in this architecture, enabling clients to respond to asynchronous events like:
However, the source documents do not provide implementation specifications for how Signify libraries consume SSE notifications.
The available documentation reveals significant gaps in SSE coverage:
The source material establishes only:
KERI's architecture inherently supports asynchronous operations:
Witness coordination may require time for witnesses to receive, validate, and receipt key events. The KAACE (KERI Agreement Algorithm for Control Establishment) defines consensus mechanisms that don't require real-time synchronous responses.
IPEX (Issuance and Presentation Exchange) protocol supports multi-step credential exchanges where:
SSE provides a plausible notification mechanism for these asynchronous workflows, alerting user interfaces when state changes occur or actions are required.
The glossary defines agent as:
"A representative for an identity. MAY require the use of a wallet. MAY support transfer."
And cloud agent as:
"Cloud agent is software that is installed on the cloud server instances in order to provide security, monitoring, and analysis solutions for the cloud."
KERIA implements a cloud agent architecture where agents perform operations on behalf of controllers. SSE fits this architecture by providing the communication channel through which agents inform clients about operation results and system state changes.
While the source documents do not compare SSE to alternatives, standard web architectures typically use:
Polling: Client repeatedly requests updates (inefficient, high latency) WebSockets: Bidirectional full-duplex communication (more complex than needed for notifications) Webhooks: Server pushes to client-provided endpoints (requires client infrastructure) SSE: Unidirectional server-to-client streaming (efficient for notifications)
SSE represents a reasonable choice for agent notification delivery given its:
The KERI protocol heavily uses CESR (Composable Event Streaming Representation) for encoding cryptographic primitives and event streams. CESR provides:
While SSE could theoretically transport CESR-encoded content, the source documents do not specify this. The glossary definition positions SSE as providing "notifications from the KERI system" rather than transporting KERI protocol messages directly.
The KERI Protocol Interface in KERIA is explicitly described as "CESR over HTTP," distinct from the Admin Interface where SSE would logically reside.
The minimal SSE documentation suggests this is either:
The KERI ecosystem maintains multiple specifications:
None of these specifications define SSE, confirming its status as implementation infrastructure rather than protocol requirement.
Developers implementing KERI agents or clients must:
Systems integrating with KERI agents should:
The server-sent event entry in the KERI/GLEIF glossary represents a minimal stub definition that identifies SSE as a notification mechanism for agent user interfaces without providing detailed specifications. The available source material establishes only that SSE:
The lack of detailed specifications suggests SSE serves as implementation infrastructure rather than a protocol-level requirement, with specific implementations (like KERIA) defining their own SSE usage patterns. Developers working with KERI agents should treat SSE as a standard web technology applied to agent notification scenarios, consulting specific agent implementation documentation for technical details not present in the protocol specifications or glossary definitions.
The minimal documentation reflects SSE's role as supporting infrastructure rather than a core KERI innovation—unlike CESR, ACDC, or KAACE, which represent novel protocol contributions requiring detailed specification.