Repository navigation
Derive dispatch identity server-side — retire the client-built id-segment #12
Description
Client half of the server-derived identity story. As of v1.5.6 (#11) a verified connection publishes governed dispatches on input.kernel.pgCK.id.<sub>.action.<verb>, where the client builds the id.<sub> segment by reading sub from its own token. That puts the client in the token path and makes it an identity constructor.
Proposal
The client publishes the plain input.kernel.pgCK.action.<verb> (no id segment); the substrate derives created_by/by: from the verified connection. The client then constructs no identity, needs no sub, and sends only {verb, kernel_urn, payload} — never-assert becomes structural.
Depends on
pgCK deriving the requester from the admitted connection rather than the subject segment (pgCK project task #20; server-derived identity itself already shipped as styk-tv/pgCK#9/#10). Gated on that — until it lands, #11 stays exactly as shipped.
Done-when
- cklib publishes the plain subject; the seal records the real
created_by; the eventby:is correct. - No token-claim parsing for subject formation remains in
ck-client.js; never-assert is structural. - Docs updated:
SPEC.CK-LIB-JS §2.1,SPEC.CK-OPERATIONS §6.1.
Relates
- Supersedes forward: Publish on the identity-scoped dispatch subject (input.kernel.pgCK.id.<sub>.action.>) so verified dispatch seals real identity #11 (id-scoped dispatch subject, closed v1.5.6) — not a reopen.
- Partner axis: Take cklib out of the token path — tokenProvider / inject-nc; retire login #14 (token path) — together, cklib constructs neither identity nor auth.
- Same server-derived principle as Unified server-derived participant presence — client surface (query + events) #13 (presence).
Activity
styk-tv commentedon Aug 5, 2026
Superseded — recording the state, not closing yet
styk-tv/pgCK#11now carries a## RESOLVED — the segment stays; the Ask's premise does not holdsection, which rules:Both halves of this issue are therefore void:
ck-client.jsbuildsinput.kernel.<K>.id.<sub>.action.<verb>from the connection's own verified claims; the client asserts nothing.Zero client work.
Not closing unilaterally. pgCK#11 states it "Serves #12", so closing this without acknowledgement would strand that issue's stated consumer. Requesting pgCK confirm, then this closes naming pgCK#11's RESOLVED section.
Board
Depends onupdated to reflect the supersession rather than an in-force dependency — the previous value read as "waiting for pgCK#11 to land, then proceed", which is now the opposite of true: when pgCK#11 lands, this becomes impossible rather than unblocked.