Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 35 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.
rpy is a three-character message type code in the KERI protocol that designates a reply message. It follows KERI's convention of using compact, Base64-compatible codes for message type identification within CESR (Composable Event Streaming Representation) streams. Reply messages serve as responses to queries, providing requested data such as key event logs, key state information, or acknowledgments of received events.
Within the KERI ecosystem, rpy messages are fundamental to the protocol's query-response architecture. When a validator or verifier needs to obtain information about an AID (Autonomic Identifier), they send a query message (typically a qry message) to a witness, watcher, or other KERI infrastructure component. The responding entity returns the requested data encapsulated in an rpy message.
Key characteristics of rpy messages include:
r) indicating the type of data being returned (e.g., /ksn for key state notices, /kel for key event logs)Reply messages follow KERI's standard message format with a JSON body and optional CESR signature attachments. The message body includes:
KERI10JSON)rpy)/ksn, /kel, /loc)Signature verification: Implementations must verify signatures on rpy messages to ensure authenticity of the responding entity. This is particularly critical when receiving key state information that will be used for subsequent validation operations.
Route handling: Different route types (/ksn, /kel, /loc, etc.) require different processing logic. Implementations should maintain a registry of supported routes and their corresponding handlers.
Asynchronous processing: Reply messages may arrive out of order or with significant delays. Implementations should use correlation identifiers or sequence numbers to match replies with their originating queries.
Caching strategies: Frequently requested data (such as key state notices) returned in rpy messages can be cached to reduce network overhead, but cache invalidation must respect KERI's first-seen policy and duplicity detection requirements.
In the ACDC (Authentic Chained Data Container) credential ecosystem, rpy messages play a critical role in IPEX (Issuance and Presentation EXchange) protocols. When credentials are requested or presented, the responding party uses rpy messages to convey the credential data, supporting both issuance exchanges and presentation exchanges.
The rpy message type is particularly important in witness and watcher infrastructure, where these components maintain copies of KELs and respond to queries about identifier state. When a client resolves an OOBI (Out-Of-Band-Introduction), the endpoint typically returns an rpy message containing the current key state and service endpoint information.