Variable: STREAMS

const STREAMS: object

Defined in: packages/contracts/src/permissions/table.ts:471

JetStream streams. The JetStream API permissions are derived from here, and are deliberately the narrowest each side needs. The consumer's host reads the stream's and its consumer's configuration, pulls and acknowledges. STREAM_DECLARER's host creates and updates the stream and creates the consumer, and reads no message. Each stream's bounds live with its JetStream configuration in @oktoid/messaging.

Type Declaration

AUDIT

readonly AUDIT: object

AUDIT.captures

readonly captures: readonly ["event.*.*.audit.recorded.v1"]

AUDIT.consumers

readonly consumers: readonly [{ module: "audit"; name: "audit-writer"; }]

GOVERNANCE

readonly GOVERNANCE: object

An accreditation's decisions, which trust must act on exactly once each and in order: one consumer for both subjects, so publication-approved is never handled before the admitted it follows. governance publishes from its outbox, which marks a row sent only on this stream's acknowledgement.

GOVERNANCE.captures

readonly captures: readonly ["event.*.governance.accreditation.admitted.v1", "event.*.governance.accreditation.publication-approved.v1"]

GOVERNANCE.consumers

readonly consumers: readonly [{ module: "trust"; name: "trust-accreditation"; }]

ISSUANCE

readonly ISSUANCE: object

Identifiers issuance has published. No reader in slice 3, as TRUST had none in slice 2: the stream is what the outbox relay's acknowledgement comes from, and it keeps a bounded history for trust, which names the issuer's identifier in the entity configuration from slice 4 (16 D7).

ISSUANCE.captures

readonly captures: readonly ["event.*.issuance.identifier.published.v1"]

ISSUANCE.consumers

readonly consumers: readonly [] = []

PLACEMENT

readonly PLACEMENT: object

The answer half: provisioning publishes placement.changed from its own outbox and issuance reads it. Its only publisher, by the generated broker file, is provisioning, so nothing credential can do fills it, and an answer is never refused because of how many questions were asked. The placement survives credential being down, which a request could not promise.

The consumer keeps the name it had on PROVISIONING, and still states its one subject in reads although the stream captures nothing else: issuance refuses to start unless the table says its consumer reads that key alone, and the stated filter is what keeps that true if this stream ever captures a second subject.

Work-queue retention here too (the same ruling): an answer issuance has recorded has no second reader and no reason to stay. The answer is not lost with it, because provisioning answers a repeated request for a placed subject with the same answer again.

PLACEMENT.captures

readonly captures: readonly ["event.*.provisioning.placement.changed.v1"]

PLACEMENT.consumers

readonly consumers: readonly [{ module: "issuance"; name: "issuance-placement"; reads: readonly ["event.*.provisioning.placement.changed.v1"]; }]

PLACEMENT.retention

readonly retention: "work-queue" = 'work-queue'

PROVISIONING

readonly PROVISIONING: object

The question half of the exchange that places a subject on an agent (D3.6, D3.16): issuance asks with identifier.requested from its outbox, and provisioning reads it here and writes the placement. The answer travels on STREAMS.PLACEMENT.

The two halves were one stream until the review of the consumed event (slice-3 plan 3a, "Rulings before 3.11b and 3.12", item 2). A full stream refuses the next publish, and credential may publish here, so on a shared stream a flood of requests would have refused provisioning's answers too. Alone on this stream, with a low message cap (STREAM_BOUNDS in @oktoid/messaging), a flood refuses only the flooder's own next request, which issuance's outbox keeps and sends again.

Work-queue retention (ruling 5 of the wave 3 hand-out) is what makes that cap a cap on the backlog. A request leaves the stream when provisioning acknowledges it, so the stream holds only what is still waiting for a placement. Under limits retention the same cap also counted every request already answered in the last thirty days, and a busy month of legitimate requests would have refused the next one.

The broker refuses two streams that capture one subject, so on a broker that still has the old two-subject PROVISIONING this stream has to give placement.changed up before PLACEMENT can take it. The setup runner sees to that itself (declareStreams updates every existing stream before it creates a missing one), so the order of the entries here carries no meaning.

PROVISIONING.captures

readonly captures: readonly ["event.*.issuance.identifier.requested.v1"]

PROVISIONING.consumers

readonly consumers: readonly [{ module: "provisioning"; name: "provisioning-placement"; reads: readonly ["event.*.issuance.identifier.requested.v1"]; }]

PROVISIONING.retention

readonly retention: "work-queue" = 'work-queue'

TRUST

readonly TRUST: object

Statements trust has published. No reader in slice 2; the stream exists because an outbox relay needs a stream's acknowledgement to mark an event sent, and it keeps a bounded history for the first consumer (the governance console's view).

TRUST.captures

readonly captures: readonly ["event.*.trust.entity-statement.published.v1"]

TRUST.consumers

readonly consumers: readonly [] = []