This is a design-discussion issue, not a code change request. Filed separately because it has architectural implications that warrant a GitHub Discussion thread before any code lands.
The motivation
A common pattern — especially for users running daimon as "shared identity for my agents" — is wanting the persona and protocols authored once, then read-only visible to all tenants on the same server.
Today the system is single-tenant-per-deployment (with a default tenant UUID baked in for dev) and `agent/persona` is tenant-scoped. Two agents — one in tenant A, one in tenant B, both connected to the same daimon-mcp — cannot share an identity.
The README's headline claim is:
"One persona and one operating discipline across every tool."
…but the single-tenant-per-deployment model is the hidden friction. A shared tenant would make cross-tool identity actually atomic.
Proposed design (open to rework)
-
Add a `tenant_role` per record: `owner` (default) | `shared`. A `shared` record is readable by any tenant on the same server but only writable by its owner.
-
New `daimon persona share ` and `daimon protocol share ` commands mark a record as shared.
-
`SessionStart` recall falls back to shared persona/protocol when the tenant has none of its own.
-
The shared records are surfaced under a synthetic namespace, e.g. `shared://agent/persona`, so they're discoverable via `recall("", namespacePrefix="shared/")`.
Open questions for the maintainer
- Write semantics: should `shared` records be immutable, or should the original owner retain the right to update them in place (Update-mode supersede)?
- Auth model: does this require per-tenant API keys, or is a single `DAIMON_API_KEY` sufficient for v0.3?
- Discovery UX: how should the `browse` MCP tool present shared records vs. tenant-private records? Should there be a `--shared` flag?
- Migration: do existing tenants' persona/protocol records need to be bulk-shared, or is this a fresh-deployment feature?
Why this matters for a second user
Pizo runs daimon (or is about to) and uses 8+ CLIs. The current model forces them to either (a) put up with 8 different personas, (b) run 8 separate daimon-mcp instances, or (c) accept that persona sync is best-effort. A shared tenant is the actual fix for the headline claim.
Acceptance
- A maintainer-weighed-in design (open this as a Discussion thread, or label this issue `design`)
- No code change until the maintainer confirms the direction
- A follow-up issue is filed with the agreed-upon design before any PR is opened
Related
- This complements the cross-CLI parity work in the README's "System layer" section.
- Could potentially be solved at a different layer: a single global "identity namespace" that all tenants read from, without per-record `tenant_role` metadata.
This is a design-discussion issue, not a code change request. Filed separately because it has architectural implications that warrant a GitHub Discussion thread before any code lands.
The motivation
A common pattern — especially for users running daimon as "shared identity for my agents" — is wanting the persona and protocols authored once, then read-only visible to all tenants on the same server.
Today the system is single-tenant-per-deployment (with a default tenant UUID baked in for dev) and `agent/persona` is tenant-scoped. Two agents — one in tenant A, one in tenant B, both connected to the same daimon-mcp — cannot share an identity.
The README's headline claim is:
…but the single-tenant-per-deployment model is the hidden friction. A shared tenant would make cross-tool identity actually atomic.
Proposed design (open to rework)
Add a `tenant_role` per record: `owner` (default) | `shared`. A `shared` record is readable by any tenant on the same server but only writable by its owner.
New `daimon persona share ` and `daimon protocol share ` commands mark a record as shared.
`SessionStart` recall falls back to shared persona/protocol when the tenant has none of its own.
The shared records are surfaced under a synthetic namespace, e.g. `shared://agent/persona`, so they're discoverable via `recall("", namespacePrefix="shared/")`.
Open questions for the maintainer
Why this matters for a second user
Pizo runs daimon (or is about to) and uses 8+ CLIs. The current model forces them to either (a) put up with 8 different personas, (b) run 8 separate daimon-mcp instances, or (c) accept that persona sync is best-effort. A shared tenant is the actual fix for the headline claim.
Acceptance
Related