The identity grammar (common.ts, IDENTITY_RE = /^[a-z0-9]([a-z0-9.-]*[a-z0-9])?$/) allows only [a-z0-9.-]. Dotted ids (a.b.c, enabled by #1/#4) let us encode a delegation hierarchy as nested segments. We'd like one more within-segment separator so a single path segment can carry a role and an instance name distinctly — e.g.:
org.cos@cos.project-manager@vista-refactor.worker@feature-a
where . separates hierarchy levels and @ separates <role>@<instance> within a level (worker@feature-a = a worker on "feature-a"). @ is currently rejected:
$ COORD_IDENTITY=org.worker@feature-a coord status org.worker@feature-a
coord: invalid identity: org.worker@feature-a
Request: allow @ in the identity grammar. It's filename-safe and rsync/sync-safe (it already appears in plenty of real filenames), so it shouldn't affect the folder/transport model. This lets downstreams build self-describing, role-typed hierarchical ids without overloading . (which would turn the role into a phantom member level) or - (ambiguous when role/instance names themselves contain hyphens, e.g. project-manager).
If a broader "structured segment" direction is preferred over a single new char, that works too — the core ask is a reserved within-segment separator distinct from ..
(Filed from a downstream multi-host deployment building a role-typed actor hierarchy on top of the folder substrate.)
The identity grammar (
common.ts,IDENTITY_RE = /^[a-z0-9]([a-z0-9.-]*[a-z0-9])?$/) allows only[a-z0-9.-]. Dotted ids (a.b.c, enabled by #1/#4) let us encode a delegation hierarchy as nested segments. We'd like one more within-segment separator so a single path segment can carry a role and an instance name distinctly — e.g.:where
.separates hierarchy levels and@separates<role>@<instance>within a level (worker@feature-a= a worker on "feature-a").@is currently rejected:Request: allow
@in the identity grammar. It's filename-safe and rsync/sync-safe (it already appears in plenty of real filenames), so it shouldn't affect the folder/transport model. This lets downstreams build self-describing, role-typed hierarchical ids without overloading.(which would turn the role into a phantom member level) or-(ambiguous when role/instance names themselves contain hyphens, e.g.project-manager).If a broader "structured segment" direction is preferred over a single new char, that works too — the core ask is a reserved within-segment separator distinct from
..(Filed from a downstream multi-host deployment building a role-typed actor hierarchy on top of the folder substrate.)