| ConfigurationStreamStore | The stream store of a closed deployment: the stream set is the operator's file rather than something receivers create over the network. Right where the receivers are the operator's own products - known in advance, changed by editing configuration. |
| ConfiguredStream | One stream as a closed deployment declares it: the shape a first-party transmitter binds from configuration when its receivers are its own products, known at deploy time and provisioned by the same operator on both sides. The members are deliberately binder-friendly - strings, arrays, a URL - so the whole stream set can live in the host's configuration. |
| DistributedCacheEventOutbox | The outbox over the host's Microsoft.Extensions.Caching.Distributed.IDistributedCache: one entry per stream holding the queue, so pending events survive a process restart when the store behind the cache does. A stream here is the receiver and the identifier together, as everywhere else. The tier is deliberate, and it is our decision rather than a permission the specification grants: SSF 1.0 Section 8.1.2.1 lets a transmitter drop events held while a stream is PAUSED, and requires transmission for an enabled one. Treating the whole queue as cache-tier follows the delivery protocols' own tolerance for loss over a broken transport, and is why it belongs in the cache tier rather than beside data that earns backups. |
| EventDispatcher | Fans one security event out to the streams it belongs on: for every stream it checks the status, the delivered event types, the subject coverage (SSF 1.0 Section 8.1.3.1) and - last - the sharing policy (Section 9.2), then mints a per-stream SET and hands it to the stream's outbox. Delivery itself is someone else's clock: a sender drains the outbox for enabled streams, and a paused stream's events simply wait. |
| InMemoryEventOutbox | The process-local outbox: right for a single-instance transmitter and for tests. Undelivered events die with the process - a transmitter that owes durability registers a durable implementation of IEventOutbox instead. |
| InMemoryStreamStore | The process-local stream store: right for a single-instance transmitter and for tests. A scaled-out or restart-surviving transmitter registers a durable implementation of IStreamStore instead - stream state is the contract between two parties, and this store forgets it with the process. |
| ManagementResult<TBody> | What one management operation earned: the status code the specification assigns the outcome (SSF 1.0 Section 8.1's error tables), the body a successful read or update carries, and - for the operator's logs, never the wire, since the management API defines no error body - why a refusal refused. |
| OutboxItem | One SET waiting in a stream's outbox: minted, signed, addressed - everything but delivered. |
| PollEndpointHandler | The transmitter's half of one poll exchange (RFC 8936, carried by SSF 1.0 Section 6.1.2): release what the receiver acknowledged, then answer with what waits. A host adapter owns routing, authentication and any long-poll waiting; this type answers from the queue as it is. |
| PollEndpointLocator | Where this transmitter serves a stream's poll queue - the "endpoint_url value is supplied by the Transmitter" of SSF 1.0 Section 8.1.1.1, and therefore the one thing a stream cannot be created with poll delivery without. |
| ProcessLocalDeliveryLease | The lease inside one process, which is the whole of its reach: it excludes the threads of this instance from each other and nothing else. A second instance of the application holds its own dictionary and sees none of these claims, so every instance believes it holds every lease. |
| PushDeliveryPassOutcome | What one push delivery pass achieved. |
| PushDeliveryScheduler | Drains every push stream's queue on a timer. |
| PushDeliverySender | One delivery pass of a stream's outbox over push (RFC 8935, carried by SSF 1.0 Section 6.1.1): each pending SET is POSTed to the receiver's endpoint in enqueue order, an accepted one is acknowledged out of the queue, and the pass stops at the first transient failure so order survives into the next pass - which is also where retry lives: the caller's schedule IS the backoff, and this type stays a single honest attempt. |
| PushDeliveryTransport | The HTTP transport pushed security event tokens travel on, to the endpoint a receiver configured for its stream. |
| ReceiverAddressPolicy | Decides whether the transmitter may deliver to the address a receiver put in its stream configuration. |
| ReceiverAddressValidatingHandler | Puts ReceiverAddressPolicy on every push delivery request, redirects and rebinding included. |
| SecurityEventDescriptor | One security event as the transmitter's application states it, before any stream is chosen: what happened, to whom, and when. The dispatcher turns it into per-stream SETs - each stream gets its own token with its own audience and identifier, per the one-receiver-per-SET guidance of SSF 1.0 Section 4.1.8. |
| SharedSignalsTransmitterOptions | What a transmitter deployment decides once: its identity, its event vocabulary, and the policies SSF 1.0 leaves to the implementation - how many streams a receiver may hold (Section 8.1.1.1), what a new stream covers by default (Section 7.1), and how often verification may be asked for (Section 8.1.1). |
| StreamManagementService | The transmitter's half of the Event Stream Management API (SSF 1.0 Section 8.1): every operation from an authenticated receiver identity and a typed request to the ManagementResult<TBody> a host adapter renders. The store persists, the adapter transports and authenticates - the SSF semantics live here, once. |
| StreamState | Everything the transmitter holds about one stream: the configuration document the receiver sees (SSF 1.0 Section 8.1.1), the status (Section 8.1.2), and the subject bookkeeping the receiver drives through the subject endpoints (Section 8.1.3). An immutable snapshot - the store replaces whole states, so a half-applied update is unrepresentable. |
| StreamSubject | A subject the receiver added to a stream, with the verification statement it made about it (SSF 1.0 Section 8.1.3.2): an omitted "verified" is assumed true, so the flag here is what the request MEANT, resolved by the management layer before storing. |
| SubjectMatcher | The subject matching of SSF 1.0 Section 8.1.3.1: the rule by which a transmitter decides whether an event's subject falls under a subject the receiver added to its stream. Simple subjects match when exactly identical; complex subjects match when EVERY field is undefined on either side or identical on both - which is what makes an absent field a wildcard, so a receiver adding just a tenant hears about every user of that tenant, and one adding user plus device still hears an event that names only the user. |