import { type Operation } from "effection";
import { type Cigar, Diger, SerderKERI } from "../../../cesr/mod.js";
import type { AgentCue } from "../core/cues.js";
import { Deck } from "../core/deck.js";
import { type TransIdxSigGroup } from "../core/dispatch.js";
import { OOBI_MAILBOX_TOPIC } from "../core/mailbox-topics.js";
import { type Role } from "../core/roles.js";
import { type ReplyProcessDecision } from "../core/routing.js";
import type { Exchanger, ExchangeRouteHandler } from "./exchanging.js";
import type { Hab, Habery } from "./habbing.js";
import type { Notifier } from "./notifying.js";
import type { Reactor } from "./reactor.js";
import { type RuntimeServices } from "./runtime-services.js";
export declare const OOBI_REQUEST_ROUTE = "/oobis";
/**
 * Runtime-tracked OOBI resolution job.
 *
 * The OOBI component enriches this shape as soon as a URL is parsed, then uses
 * the same record to write `oobis.`, `coobi.`, `eoobi.`, and `roobi.` state
 * transitions during resolution.
 */
export interface OobiJob {
    url: string;
    alias?: string;
    cid?: string;
    role?: Role | string;
    eid?: string;
    said?: string;
    state?: string;
}
interface OobieryOptions {
    cues?: Deck<AgentCue>;
    services?: RuntimeServices;
}
/**
 * Durable OOBI processing component for one `Habery`.
 *
 * KERIpy correspondence:
 * - this is the closest local analogue to `Oobiery`
 *
 * Ownership model:
 * - authoritative queue state lives in `oobis.`, `woobi.`, `coobi.`, `eoobi.`,
 *   and `roobi.`
 * - this component owns the fetch/parse/persist flow for those records
 * - transient in-memory state stays local to the fetch operation and does not
 *   leak back to the `AgentRuntime` root
 */
export declare class Oobiery {
    readonly hby: Habery;
    readonly reactor: Reactor;
    readonly cues: Deck<AgentCue>;
    readonly services: RuntimeServices;
    constructor(hby: Habery, reactor: Reactor, options?: OobieryOptions);
    /** Register `/introduce` on the shared reply router. */
    registerReplyRoutes(router?: import("../core/routing.js").Router): void;
    /**
     * Queue one OOBI for durable later processing.
     *
     * Current `keri-ts` rule:
     * - like KERIpy, the durable queue is the DB record in `oobis.`
     * - unlike the older bootstrap runtime, there is no root in-memory OOBI deck
     */
    resolve(url: string, alias?: string): void;
    /**
     * Process one queued durable OOBI record, if any.
     *
     * Behavior:
     * - reads the next queued `oobis.` / `woobi.` record
     * - fetches it under Effection cancellation control
     * - routes any returned KERI bytes through `Reactor`
     * - transitions the durable record into `eoobi.` or `roobi.`
     */
    processOnce(): Operation<void>;
    /**
     * Continuous OOBI doer for the long-lived runtime host.
     *
     * This mirrors the KERIpy model where OOBI resolution is its own long-running
     * doer rather than root-owned queue plumbing.
     */
    oobiDo(): Operation<never>;
    /** Return the next queued durable OOBI record, if any. */
    private nextQueued;
    /** Return one multi-OOBI parent whose child URLs have all settled. */
    private nextReadyMoobi;
    /**
     * Resolve one queued OOBI record through fetch -> parse -> route -> persist.
     *
     * Stores touched:
     * - `oobis.` / `woobi.` as the durable queued worklists
     * - `coobi.` while a fetched response is being processed
     * - `eoobi.` on HTTP failure
     * - `roobi.` after parser/routing success
     */
    private processJob;
    private resolveCesrOobiResponse;
    /** Handle schema data-OOBIs before generic JSON reply handling. */
    private processSchemaOobiResponse;
    /** Handle JSON OOBI responses that carry reply bodies instead of CESR streams. */
    private processJsonOobiResponse;
    /** Fan one multi-OOBI reply out into child `oobis.` jobs and a parent `moobi.` record. */
    private processMultiOobiReply;
    /** Finalize one parent multi-OOBI after its child URLs all reach terminal state. */
    private completeMultiOobi;
    /** Mark one fetched OOBI as terminal failure and clear its in-flight state. */
    private failFetchedOobi;
    /** Persist one queued record into the selected durable queue. */
    private pinQueueStore;
    /** Remove one queued record from the selected durable queue. */
    private remQueueStore;
    /** Normalize and persist one new queued OOBI record into the default queue. */
    private pinQueuedRecord;
    /**
     * Process one `/introduce` reply and enqueue the introduced OOBI into the
     * ordinary durable resolver path.
     */
    processReply(args: {
        serder: SerderKERI;
        diger: Diger;
        route: string;
        cigars?: Cigar[];
        tsgs?: TransIdxSigGroup[];
    }): ReplyProcessDecision;
}
export declare function loadOobiHandlers(hby: Habery, exchanger: Exchanger, notifier?: Notifier | null): void;
/**
 * Peer-to-peer OOBI request handler for `/oobis` exchange messages.
 *
 * KERIpy correspondence:
 * - this is the local analogue of `keri.app.oobiing.OobiRequestHandler`
 * - the Python handler does two things only: accept an EXN carrying an OOBI
 *   URL, and convert that request into local controller-visible state
 * - specifically, it pins an `oobis.` record so the resolver can fetch it
 *   later, and it emits a notifier entry so operator-facing surfaces can show
 *   that someone asked us to resolve or inspect an OOBI
 *
 * Local `keri-ts` adaptation:
 * - verification stays lightweight and route-local: we only require a string
 *   `oobi` payload with an `http:` or `https:` scheme
 * - durable follow-on work still belongs to `Oobiery` itself; this handler is
 *   just the exchange ingress seam that translates an EXN into queued resolver
 *   state
 * - unlike KERIpy's DoDoer-centric runtime, the queued record is later
 *   advanced by the shared `AgentRuntime` turn that owns OOBI processing
 */
export declare class OobiRequestHandler implements ExchangeRouteHandler {
    static readonly resource = "/oobis";
    readonly resource = "/oobis";
    readonly hby: Habery;
    readonly notifier: Notifier | null;
    constructor(hby: Habery, notifier?: Notifier | null);
    verify(args: {
        serder: SerderKERI;
    }): boolean;
    handle(args: {
        serder: SerderKERI;
    }): void;
}
export declare function oobiRequestExn(hab: Hab, dest: string, oobi: string): SerderKERI;
/**
 * Parse one OOBI URL into its role/cid/eid metadata projection.
 *
 * Current scope:
 * - `/.well-known/keri/oobi/{cid}` -> controller role
 * - `/oobi/{cid}/{role}/{eid?}`
 *
 * The parser is intentionally permissive about unknown roles because the
 * runtime persists what it sees even before the broader ecosystem role matrix
 * is complete.
 */
export declare function parseOobiUrl(url: string, alias?: string): OobiJob;
/** Return true when one OOBI URL uses the well-known discovery path. */
export declare function isWellKnownOobiUrl(url: string): boolean;
export { OOBI_MAILBOX_TOPIC };
//# sourceMappingURL=oobiery.d.ts.map