/** * The receive-side sliding window for one REST context's request channel. * * `admit(counter)` either returns — the counter is accepted and recorded — or * throws a `RecordError` carrying one of the two §9 codes that apply here: * * - `E2EE_SEQUENCE_VIOLATION` for a counter this window can PROVE it has * already seen, and for one outside the counter's own range. A claim about * the peer, and true only because the frame was authenticated first; * - `E2EE_CTX_UNKNOWN` for one that fell out of the window. It cannot be * proven a replay — the bit that would say so has been reused by a counter * 1024 positions later — so it gets the RECOVERABLE code, which is what * `RestResponseSealer.accept` already answers on its own below-window edge. * A client that lags this far behind re-opens and retries rather than * dead-ending. */ export declare class RestReceiveWindow { #private; /** * The width, in counters. Deliberately the SAME width as the response * sealer's, and taken from it rather than repeated as a literal. * * §13(a) is what couples them: at most one sealed response per accepted * request counter, and a counter this window still accepts must therefore be * one the sealer can still answer. Two literals would let the widths drift in * a later edit, and the failure that drift produces is not a rejected request * — it is a request accepted here and refused there, i.e. an accepted request * that can never be answered. */ static readonly WINDOW_COUNTERS = 1024; constructor(); /** * Judge one AUTHENTICATED counter. Returns on acceptance; throws otherwise. * * The four outcomes, in the order they are decided — and the order is * load-bearing. Below-window is tested BEFORE the bit, because a counter that * has fallen out of the window reads a bit that now belongs to the counter * 1024 positions later: whatever that bit says is about a different counter, * so the range check has to answer first. */ admit(counter: bigint): void; } //# sourceMappingURL=rest-window.d.ts.map