Relationships
#447 CLI telemetry forwards non-personally-resolvable identity for collective auth; distinct_id is per-machine, not per-repo
Opened by keeb · 5/26/2026
Summary
When the CLI is authenticated with a collective/org token (swamp_org_…),
the telemetry flush sends that token as x-api-key, but it is not resolvable to
a username server-side — so the invocation is recorded without an identity and
the user is mis-bucketed as anonymous. Additionally, the telemetry distinct_id
is the per-machine ~/.config/swamp/identity.json id (not the .swamp.yaml
id), so ephemeral/CI environments mint a fresh unclaimed id on every run.
Impact
- Authenticated CLI operators who use collective auth never get linked to their account in telemetry.
- CI/ephemeral runs generate a brand-new unattributed distinct_id each time, inflating "anonymous heavy user" counts.
Details (CLI side)
- Telemetry sends the stored key as
x-api-keyon/ingest—src/infrastructure/telemetry/http_telemetry_sender.ts:53. authTokenis loaded fromAuthRepositoryanddistinct_idis the user-level identity id —src/cli/mod.ts:984andsrc/cli/mod.ts:976(distinctId: telemetryCtx.userId ?? telemetryCtx.repoId); the.swamp.yamlrepoId is sent only as the$repo_idproperty.extension pushsupports publishing under a collective —src/libswamp/extensions/push.ts(whoami/fetchCollectives). In that mode the token sent to telemetry is aswamp_org_…key, which the ingest's personal-key resolver cannot turn into a username.
Reproduction
- Authenticate the CLI with a collective token (
swamp_org_…). - Run
swamp extension pushfor a@collective/*extension (succeeds). - The publishing distinct_id never appears in any
identity_mapentry.
Suggested fix (CLI side)
- For collective auth, forward an identity the server can attribute (e.g. include
the acting member's username in event properties when known from
whoami, or send a personally-resolvable credential alongside). - Consider distinct_id stability for CI/ephemeral environments so repeated runs don't each create a new unclaimed id.
Related
Sibling server-side defect: swamp.club Lab #446 (ingest only resolves personal API keys, never the collective resolver).
Closed
No activity in this phase yet.
keeb commented 5/26/2026, 4:32:36 AM
Disposition: closing — fix belongs server-side (#446)
After triage and adversarial review, this is not a CLI defect and the suggested CLI-side fix should not be implemented.
The suggested fix is spoofable. Forwarding the acting member's username in the telemetry event properties means the identity travels in the attacker-controllable JSON body. Any client could post auth_username: "<someone-else>" and poison another account's attribution. Identity must be derived from a validated credential, never self-asserted by the client.
The server is — and must be — authoritative. The CLI already forwards the only trustworthy identity signal: the validated x-api-key bearer credential (src/infrastructure/telemetry/http_telemetry_sender.ts:53), sent on every authenticated flush. The actual gap is that the ingest's resolver only maps personal API keys to a username and cannot resolve collective swamp_org_… keys. That resolution is server-side work, tracked as the sibling defect #446.
distinct_id is a separate, lesser concern. The per-machine identity.json UUID churns in CI/ephemeral environments, but for authenticated runs the server can alias whatever distinct_id arrives to the account it resolves from the api-key — so no client change is needed for attribution. (Stabilizing the anonymous bucket for unauthenticated ephemeral runs is a minor, independent idea, not part of this issue.)
Action: No CLI code change. Attribution for collective auth is resolved by #446 (server-side resolver). Closing here and routing to #446.
Sign in to post a ripple.