SmithSamuelM
commented
3 years ago Query Modes Development Work
Closed SmithSamuelM closed 3 years ago
SmithSamuelM
commented
3 years ago Query Modes Development Work
pfeairheller
commented
3 years ago @SmithSamuelM For either mode (disjoint / conjoint) is there a prescribed order for the types of receipts based on signer (witness, watcher, or validator) or on signer identifier type (transferable / non-transferable)?
SmithSamuelM
commented
3 years ago Order shouldn’t matter. The parser looks for counter and based on parsed counter code know what follows.Assuming using the new extended counter code table that has a unique code for the various attachment type.
SmithSamuelM
commented
3 years ago where first seen events by validator or watcher have to be witnessed. (two stage escrow) Prefix controller directly communicates to its witnesses.
chunningham
commented
3 years ago this topic has been moved to the agenda document for weekly discussion
Replay Modes
KERI enables and benefits from several different modes for replaying event logs. To a large extent this is a result of KERI's asynchronous design. Signatures and Receipts on events may be collected asynchronously. This means replay may be also performed asynchronously. This also introduces some complexity. This issues outlines the different options or modes for replay and how KERI may support them as well as the performance trade-offs for each of the modes. For interoperability sake, we need to road map and prioritize the implementation of the different modes.
The existing event and receipt messages allow what I call bare metal disjoint replay mode. This replays events over TCP with attached indexed signatures and then receipts each separably with attached indexed signatures, couples or quadruples as appropriate to the type of signer of the receipt, witness, watcher, or validator. This is the least efficient bare metal mode but the easiest to support. For example:
ICP Event Msg | Count Code |Attached Signatures | RCT Msg | Count Code | Attached Couples (Prefix + Signature) | VRC Msg | Count Code | Attached Signatures
The other mode is called bare metal conjoint mode because all the signatures, couples, and quadruples may be attached to the associated event message in a single composed stream of attachments over TCP without any intervening receipt messages. The expanded Counter Code table enables full explication of heterogenous attached streaming material required for bare metal conjoint mode. This is the most efficient mode. For example:
ICP Event Msg | Extended Count Code |Attached Signatures | Extended Count Code | Attached Couples (Prefix + Signature) | | Extended Count Code | Attached Signatures
Concurrent Version
CP Event Msg |Stacked Count Codes |Attached Signatures | Stacked Count Code | Attached Couples (Prefix + Signature) | | Stacked Count Codes | Attached Signatures
Another streaming replay mode is qb2 where a composed qb64 stream is converted en mass to qb2 and streamed and then at the other end either parsed in qb2 or converted back to qb64 before parsing.
Other modes would be to use a Rest Interface on HTTP to replay. The simplest is to replay the event in the response body and to replay the attached signatures in HTTP headers. But this does not stream events.
A more streaming like interface could be done with a push mechanism such as HTTP standard SSE (server sent events) in either disjoint or conjoint streaming of the events plus attached signatures, couples, or quadruples. Another HTTP related replay mode would be to use a web socket and then use either disjoint or conjoint streaming over the web socket.
The final suggested mode would be an enveloped Rest Query mode where the attached signatures are wrapped in a JSON, CBOR, or MsgPack envelope as a list of attachments and then returned as one large response body. This is probably the most cumbersome and least performant but may be a popular way to replay.
In addition to Replay over the internet (external replay modes) we also need to support internal replay for cloning the database as a security measure. Replay through the validation logic ensures the database was not undetectably corrupted while offline.
There is some replay logic to be defined for delegated identifiers where a replay of a delegated identifier is preceded by its delegators replay. Likewise for VRC receipts or else the escrow logic needs to be adjusted.
The replay roadmap also exposes the need to roadmap HTTP support, UXD (unix domain socket), and UDP support. For internal replay between processes, UXD is much more performant than TCP and unlike its cousin UDP, UXD is reliable and does not suffer from MTU fragmentation issues. UDP is the most performant and scalable of the external replay modes but requires designing a reliable fragmentation protocol to address UDP MTU size limitations. This is not difficult to do but does require some extra work.
A replay consumer needs some way to initiate replay. For each of the replay modes we need to define how to initiate. This suggest a new message types called a replay query by which a consumer can poll a KERL host for some or all of the KELs in its database. A clone query is all the KELs in its database. Where a focused query could simply ask for one KEL at a time or even just some events from a KEL. The query could also be limited to include some combination of controller signatures, witness signatures, watcher couples, and validator quadruples.
There are two types of replay in terms of event selection, full First Seen Replay and Recovered replay. Call these clone and sequence numbered replay.
For the HTTP ReSTful replay modes a query string format could provides all those query options. For a bare metal replay requests we need a message with one or more query fields that provide the same level of functionality.
Another consideration for replay is white listing replay and black listing play and replay.
The white list is used by a controller for playing message into its own KEL. It never accepts play in for its controlled KELs over the internet but only internally so that its own database never gets corrupted by inappropriate first seen events for its own KELs. It also may white list clones from other hosts so that it only accepts replay of either its own KELs or any KELs from hosts it trusts. A controller or any host for that matter may black list replay out or play in for KELs that have been erased. Or from duplicitous watchers or witnesses.
new message type
qryorqklorreqProposed RoadMap
A) Bare Metal TCP Disjoint Replay Add support for indexed witness attached signatures using new count code Add query replay message and query fields
B) Bare Metal TCP Conjoint Replay B1) Add support for count codes for couples and quadruples B2) qb2 streaming support B2) Internal Cloning of database (same process) B3) white listing B4) Composable Text Event Format (counter codes
C) Add HTTP support to KERI C1) Add HTTP Rest Interface for push, put of all messages with attached signatures in Signature headers C2) Define headers for attached signatures and receipt couples and quadruples C3) Add query syntax for get requests C4) Dump disjoint or conjoint replay into response body. Used chunked encoding. C5) Add SSE get response Push with disjoint or conjoint replay with chunked encoding C4) Add enveloped get response
D) Black Listing
E) Add UXD support to KERI for more performant internal inter-process replay (cloning)
F) Add UDP support to KERI
The order of events could be in the order listed or we could do A) and then parallelize B and C. Where one work stream is B) and the other in parallel is C). This would allow some implement E) before finishing B) C) D).
The design for B) that is not A) is mostly done now with the expanded counter codes so it could be underway while the design for C) is ongoing.