protocol_droid/application/session/id_source.rs
1//! Where a session's identity comes from.
2//!
3//! # Why a session needs an id at all
4//!
5//! Two things need to say which session they are talking about: the event log,
6//! which interleaves the history of every open session, and the redaction rule
7//! that says a session id is never logged in full. Neither is possible without
8//! one, and both are why it is a value rather than an `Arc<Self>` a task can
9//! reach through.
10//!
11//! # What this does not promise
12//!
13//! Uniqueness *within a process*. A session id correlates one process's work
14//! with itself; it is not a capability, not a secret, and not something a peer
15//! is ever asked to trust — the vendored revisions never say otherwise, and
16//! 2026-07-28 removes the header outright (SEP-2567).
17//!
18//! A deployment that does want ids a peer cannot enumerate from one it has seen
19//! should use `adapters::secondary::id_source::RandomIds`, behind the
20//! `random-ids` feature. A path rather than an intra-doc link, because that
21//! module is optional and this one is not. It is not the default because a
22//! single-process embedding is better served by a reproducible counter, and this
23//! is a port precisely so it can have one.
24
25use crate::domain::session::SessionId;
26
27/// Mints session identities.
28///
29/// Declared by the engine, its only consumer, and consumed through
30/// `impl IdSource`. One method, because a source that also answered "how long
31/// is this session" would be two responsibilities in one adapter.
32pub trait IdSource {
33 /// A fresh identity.
34 ///
35 /// Must not repeat an id this source has already returned, for as long as
36 /// either session can still appear in the event log.
37 fn next_session_id(&self) -> SessionId;
38}