Module oobi 

auths oobi — KERI Out-Of-Band Introduction (discovery).

An OOBI is how KERI controllers discover each other: a URL that says “here is my AID, and here is where to fetch its key event log and endpoints.” It is the bootstrap of every live KERI exchange (witnessing, credential presentation, key-state resolution) — before a peer can talk to an AID it must first discover where that AID lives, out of band. The KEL fetched through an OOBI is still verified by replay, so the URL is only a location hint, never a root of trust.

Two directions, mirroring discovery itself:

• auths oobi resolve — peer → us: parse a peer’s OOBI URL, fetch the bytes it points at, replay the embedded KEL into a verified key-state, and print it. --from-file resolves an already-fetched stream offline.
• auths oobi endpoint — us → peer: from one of our KELs and the URL we host it at, emit the OOBI URL to publish plus the rpy reply stream (/loc/scheme + /end/role/add) a peer fetches when it resolves us.

The wire definitions (URL grammar, reply records, KEL ingest) live in auths-keri::oobi; this is a thin CLI adapter. The HTTP fetch sits behind a port here so the discovery logic never imports a transport.

Structs

EndpointArgs

auths oobi endpoint — serve an AID’s introduction.

OobiCommand

Resolve or serve a KERI OOBI (Out-Of-Band Introduction) for discovery.

ResolveArgs

auths oobi resolve — discover a peer by resolving its OOBI URL.

Enums

OobiAction

The two OOBI directions: resolve a peer’s, or serve our own.