One of the persistent differences between RubyGems.org and most of its peer registries is the flat namespace. npm has scoped packages, Maven Central has reversed-domain prefixes, NuGet supports prefix reservations, PyPI has had ongoing discussions about namespaces. RubyGems.org has remained flat since its inception, with gem names taken on a first-come, first-served basis. This has real consequences for organizations that want to publish gems under a branded prefix and prevent anyone else from squatting on variants. The situation has evolved gradually, with several policy updates over 2023 and 2024 addressing the most common enterprise pain points without moving to a full scoped-namespace model. This post walks through what is currently supported, what is not, and how organizations should approach namespace management given the tools available.
The underlying tension has not changed. Ruby Central, which operates RubyGems.org, wants to keep the registry simple and backward-compatible. Large organizations want branded namespaces and prefix protection. The compromise has been an expanded reservation-and-dispute process that provides something close to prefix protection in practice, even without formal namespace support.
What does the current reservation process look like?
An organization that wants to protect a prefix on RubyGems.org, say acme- as a prefix for all gems published by Acme Corporation, can submit a namespace-claim request through the RubyGems.org support channel. The request needs to include the organization's identity (trademark documentation, domain ownership proof, or similar), the prefix being claimed, and a description of the planned publishing activity.
If the request is approved, the prefix is added to a reserved-prefix list that the registry uses to gate new gem registrations. Attempting to register acme-something by anyone not associated with the Acme organization returns a registration error directing the registrant to contact the claimed owner or to dispute the reservation if they believe they have a legitimate reason for the name.
The process was formalized in early 2024 and has been in use by a growing set of organizations since. As of December 2024, the reserved-prefix list contains approximately 180 prefixes, up from about 110 at the start of the year. The growth rate suggests the process is usable but not heavily trafficked, which matches expectations; most Ruby-publishing organizations have not historically worried about prefix protection and do not start until they hit a specific incident.
What qualifies for a prefix reservation?
The published criteria are that the organization must demonstrate a legitimate identity tied to the prefix, through a registered trademark, a matching primary domain name, or a well-established open-source project identity. The word "legitimate" is doing a lot of work in that sentence, and in practice the RubyGems.org team uses judgment informed by how established the organization is and how plausible the prefix claim is.
A clear case: a public company with a registered trademark matching the prefix and existing gems published under that prefix. This gets approved quickly, typically within 10 business days. A marginal case: an individual open-source maintainer who has published a few gems under a name and wants to reserve that name as a prefix for future work. This gets approved but may take longer and may involve some back-and-forth on what exactly is being reserved.
A rejected case: a request for a generic prefix like auth- or http- that corresponds to no specific identity. The criteria explicitly block prefix reservations that would monopolize a common word, because doing so would create friction for every other Ruby developer who might reasonably want to publish a gem with that prefix. This reflects a conscious policy choice to keep the namespace open for organic use and to scope reservations to identity-bound prefixes.
How is enforcement handled?
When a prefix is reserved, the registry blocks new registrations that match the prefix from accounts not associated with the reserving organization. The association is tracked through the organization feature on RubyGems.org; organization members get the protected prefix by default, and non-members get the block.
The block is on registration, not on existing gems. If someone had already published acme-something before the Acme reservation went into effect, the existing gem stays under its original ownership. Resolving that situation moves into the standard trademark-dispute process, which is slower and more expensive. For this reason, organizations that anticipate needing a prefix should file early rather than waiting for an incident.
The block is also not retroactive across the dispute window. An organization that files a reservation for acme- on January 1 and has it approved on January 15 does not get protection against a gem that was registered on January 10. This has been a source of friction in a few public cases, most notably when a corporate organization discovered that a name variant had been registered the day before their reservation went through. The policy currently handles these cases through the regular dispute process rather than through automatic retroactive blocking, which Ruby Central has explained is a bright-line rule to keep the reservation system predictable.
What about the SCM-coupled namespace model?
A related feature, distinct from prefix reservations, is the SCM-coupled namespace model that launched in late 2024. An organization can link its RubyGems.org organization to a GitHub organization or GitLab group, and any gem published under the RubyGems.org org is required to have a source-code-uri in its gemspec pointing to a repository inside the linked SCM organization. This does not reserve a prefix, but it creates a verifiable chain between published gems and the SCM source of truth.
The value is less about namespace and more about provenance. When a consumer looks at a gem claiming to be published by Acme Corporation, the SCM-coupled model lets them verify that the gem's source actually lives in Acme's GitHub organization, rather than in some random repository the attacker controls. Combined with trusted publishing and the eventual Sigstore integration, this creates a reasonable provenance story even without formal scoped namespaces.
About 40 RubyGems.org organizations have adopted the SCM-coupled model as of December 2024, which is modest adoption but covers several of the most popular gem publishers including basecamp, shopify, and some of the Rails-core-affiliated groups. The adoption is mostly concentrated among organizations that already use the RubyGems.org organization feature and have a clear SCM pairing; smaller publishers often skip it.
What are the limits?
The current reservation system does not cover a few cases that enterprise organizations frequently ask about. First, homograph protection: a reservation of acme- does not block asme- or similarly visually confusable prefixes. An attacker who wants to squat on an Acme-adjacent name can still use near-miss variants. The solution would be Unicode-aware edit-distance checks on new registrations, which has been discussed but not yet implemented.
Second, downstream dispute against pre-existing gems: as noted above, an existing gem at the time of reservation is not covered by the automatic block. This is particularly painful for organizations that discover the reservation process late, after an incident has already occurred.
Third, internal-only prefixes: some organizations want to reserve a prefix for exclusive internal use without ever publishing to the public registry. The current policy requires actual publishing activity or credible plans thereof, to avoid the prefix system being used for defensive-only claims that take up namespace without contributing anything. This is reasonable policy but means organizations with purely internal Ruby development do not benefit from the public reservation system and have to handle namespace hygiene on their internal gem servers.
Fourth, the policy is not legally binding in the way that a trademark is. A dispute that escalates to actual litigation is handled through the trademark system, not through RubyGems.org. The registry's reservation is an administrative convenience that operates within the legal framework of trademark law, not a substitute for it.
What should organizations actually do?
The pragmatic playbook is: file a reservation for your primary brand prefix early, well before you have a business reason to care, so that the policy is in place when you need it. Pair the reservation with the organization feature and, if you use GitHub or GitLab, enable the SCM-coupled namespace model. Publish all of your gems through the organization rather than through individual accounts, which makes ownership clear and succession-planning easier.
For visual-variant protection, supplement the reservation with active monitoring of new gem registrations on RubyGems.org. Several tooling options exist, including the rubygems-monitor gem and commercial supply-chain monitoring services. When a close variant of your prefix appears, file a dispute early rather than waiting for the gem to be actually malicious. This is a labor-intensive practice that is worth the effort only for organizations with meaningful exposure to brand-adjacent namespace attacks.
For internal Ruby, maintain your own gem server (Gemstash, Bundler's internal gem server features, or a commercial artifact manager) and handle namespace through the organization controls of that internal server. The public RubyGems.org reservation system is primarily a defense against external actors, and the internal namespace is a separate problem with separate tools.
How Safeguard Helps
Safeguard monitors RubyGems.org for new gem registrations that match prefix patterns you have reserved or care about, alerting when a potential namespace conflict appears. We surface your organization's full reservation portfolio alongside related signals, SCM-coupled organization status, trusted-publishing coverage, typosquat-adjacency alerts, so your namespace posture is legible in one place. When a dispute-worthy registration appears, we give your team the information needed to open a RubyGems.org dispute quickly rather than discovering the issue weeks later through an incident. Namespace policy is a defensive discipline, and Safeguard keeps it active rather than dormant.