Protorip
---
site: protos.rip
page: docs/concepts/module-urls
---

# Module URLs

## The three-segment shape

A module reference has three parts: `<host>/<scope>/<module>`.
On protos.rip the host is the literal `protos.rip` — the buf CLI uses the host segment to decide which registry to talk to.
The scope is the namespace owning the module — your handle, an org slug, or a curated-mirror slug. See [Scopes](/docs/concepts/scopes).
The module is the slug picked at module-create time, validated against `^[a-z][a-z0-9_-]*$` (start with a lowercase letter, then lowercase letters, digits, hyphens, or underscores).

## Optional pin segment

References support an optional fourth segment after `:` — either a label name or a commit ID.
`protos.rip/<scope>/<module>` resolves to the latest commit on the module’s default label, which starts as `main`.
`protos.rip/<scope>/<module>:v1.0.0` resolves to whatever commit the `v1.0.0` label currently points at.
`protos.rip/<scope>/<module>:01H...` resolves to a specific commit by ID.
The buf CLI records the resolved commit in `buf.lock` regardless of how the reference was pinned in `buf.yaml` — the pin syntax controls future resolution, not the current resolution result.

## Where references appear

Use a module reference in `buf.yaml` under `deps:` for a project consuming the module, and under `name:` for a project publishing it.
On the CLI, pass it as the argument to `buf registry module create`, `buf registry module info`, `buf push`, `buf registry label list`, and other registry subcommands.
On protos.rip’s own URLs, the dashboard module page lives at `/dashboard/modules/<scope>/<name>` and the public module page at `/<scope>/<module>`.

## Why the host is part of the reference

The buf CLI doesn’t have a single registry baked in — every module ref names its registry up front so a `buf.yaml` can mix modules from different registries (subject to the CLI’s federation allowlist; see [buf CLI command coverage](/docs/reference/buf-cli-command-coverage)).
Changing the host segment of an existing module isn’t a rename — it would mean republishing under a different registry, and consumers’ `buf.yaml` would need to update too.
Keeping the host explicit makes module references portable in error messages, README files, and chat — a reader can tell which registry to look at without context.

## See also