The case
rust-faf-mcp resolves under two ownership namespaces for the same underlying package, and they have drifted out of sync as a direct result:
one.faf/rust-faf-mcp → v0.4.2 (current, matches crates.io's newest_version)
io.github.Wolfe-Jam/rust-faf-mcp → v0.3.1 (stale, several releases behind)
Publishing either namespace requires a token scoped to that specific namespace; there is no way to hold both simultaneously, and no path to link the two identities as the same publisher. In practice that friction is enough that the io.github.* entry simply stopped being republished — a client resolving via that namespace sees months-old information while the domain namespace reflects reality.
What the code does
Publish auth is a single-token check against the full namespace/name string:
internal/api/handlers/v0/publish.go:53 — jwtManager.HasPermission(input.Body.Name, auth.PermissionActionPublish, claims.Permissions)
internal/auth/jwt.go:156-173 — HasPermission/isResourceMatch: exact/prefix match against the token's own fixed permission list, no cross-token logic
internal/api/handlers/v0/auth/github_at.go:295-310 — GitHub OAuth grants io.github.{username}/* and io.github.{org}/* only
internal/api/handlers/v0/auth/common.go:228,235 — DNS/HTTP verification grants {reverseDomain}/* and {reverseDomain}.* only, with no reference to any GitHub identity
Neither grant path is aware of the other. There's no explicit branch that accepts or rejects a publisher claiming two namespaces — the permission model has no field or concept representing "these two identities are the same publisher." Two namespace strings for one package are just two unrelated resources, each free to drift independently — as they now have.
What's already documented / filed
Scale
Full walk of GET /v0.1/servers?version=latest just now: 23,438 total registrations, 16,342 (69.7%) io.github.*, 7,096 (30.3%) custom-domain namespaces. Anyone holding both an io.github.* history and a verified domain for the same package hits this — and, per the drift above, it doesn't just cause friction, it produces stale published data.
Question
Is a publisher meant to hold only one namespace identity per package, with no supported way to link a second one — or is cross-namespace publisher identity intended to be supported eventually? Either answer is fine; right now the behavior isn't documented either way, and the two auth paths are structurally unaware of each other in the code.
The case
rust-faf-mcpresolves under two ownership namespaces for the same underlying package, and they have drifted out of sync as a direct result:one.faf/rust-faf-mcp→ v0.4.2 (current, matches crates.io'snewest_version)io.github.Wolfe-Jam/rust-faf-mcp→ v0.3.1 (stale, several releases behind)Publishing either namespace requires a token scoped to that specific namespace; there is no way to hold both simultaneously, and no path to link the two identities as the same publisher. In practice that friction is enough that the
io.github.*entry simply stopped being republished — a client resolving via that namespace sees months-old information while the domain namespace reflects reality.What the code does
Publish auth is a single-token check against the full
namespace/namestring:internal/api/handlers/v0/publish.go:53—jwtManager.HasPermission(input.Body.Name, auth.PermissionActionPublish, claims.Permissions)internal/auth/jwt.go:156-173—HasPermission/isResourceMatch: exact/prefix match against the token's own fixed permission list, no cross-token logicinternal/api/handlers/v0/auth/github_at.go:295-310— GitHub OAuth grantsio.github.{username}/*andio.github.{org}/*onlyinternal/api/handlers/v0/auth/common.go:228,235— DNS/HTTP verification grants{reverseDomain}/*and{reverseDomain}.*only, with no reference to any GitHub identityNeither grant path is aware of the other. There's no explicit branch that accepts or rejects a publisher claiming two namespaces — the permission model has no field or concept representing "these two identities are the same publisher." Two namespace strings for one package are just two unrelated resources, each free to drift independently — as they now have.
What's already documented / filed
docs/reference/api/official-registry-api.mdanddocs/reference/cli/commands.mddocument the two auth methods per namespace type, but nothing about linking identities across them or migrating a server between namespace types.io.github.*to a domain namespace, blocked by an unrelated immutable-version URL collision (redirected to Exclude deleted and deprecated servers while validating remote urls. #1193). Different mechanism: one-way abandonment blocked by a validation bug, not simultaneous dual-namespace publishing.Scale
Full walk of
GET /v0.1/servers?version=latestjust now: 23,438 total registrations, 16,342 (69.7%)io.github.*, 7,096 (30.3%) custom-domain namespaces. Anyone holding both anio.github.*history and a verified domain for the same package hits this — and, per the drift above, it doesn't just cause friction, it produces stale published data.Question
Is a publisher meant to hold only one namespace identity per package, with no supported way to link a second one — or is cross-namespace publisher identity intended to be supported eventually? Either answer is fine; right now the behavior isn't documented either way, and the two auth paths are structurally unaware of each other in the code.