Session keys are namespaced per channel, so the same underlying user reaching a service through two channels gets two unrelated sessions with no shared history.
That namespacing is deliberate and should stay: the design rules out automatic cross-channel identity linking as a non-goal, because inferring that a Slack user and an HTTP caller are the same person is exactly the kind of guess that goes wrong quietly. What it explicitly allows is the escape hatch — "continuity across channels is only ever an explicit alias" — and the alias is not implemented (no alias anywhere in the service code).
So the shape is narrow by construction: a definition-level, operator-declared mapping stating that key A on channel X and key B on channel Y are the same conversation. Never inferred, never automatic.
Worth deciding whether an alias merges into one session or forwards one key to another's session, and what happens when both sides already have live sessions with divergent history.
Session keys are namespaced per channel, so the same underlying user reaching a service through two channels gets two unrelated sessions with no shared history.
That namespacing is deliberate and should stay: the design rules out automatic cross-channel identity linking as a non-goal, because inferring that a Slack user and an HTTP caller are the same person is exactly the kind of guess that goes wrong quietly. What it explicitly allows is the escape hatch — "continuity across channels is only ever an explicit alias" — and the alias is not implemented (no
aliasanywhere in the service code).So the shape is narrow by construction: a definition-level, operator-declared mapping stating that key A on channel X and key B on channel Y are the same conversation. Never inferred, never automatic.
Worth deciding whether an alias merges into one session or forwards one key to another's session, and what happens when both sides already have live sessions with divergent history.