The Nostr protocol has a new tool in its belt, and it’s one that nobody was loud about. On October 21, 2026, a specification called NIP-CD was merged into the NIPs repository under the title “Commands.” Six days later, it was retitled “Slash Commands” when an optional installed-command list was added through PR #2525. The change landed without a single viral thread, without a developer spat, and without the kind of drama that usually accompanies protocol-level shifts. That silence is exactly why it deserves attention.

What NIP-CD Actually Does

Here’s the short version. A service publishes a command using a kind 31992 event. That event carries a trigger word (without the slash), a title, and a usage description. The command can declare positional arguments (pubkeys, event IDs, relays, numbers, enums, or text) and scope itself to specific event kinds, relays, authors, or tags. An invocation is plain text that starts at index zero of any Nostr event’s content, like /ban followed by arguments. No tags required. No special client support required.

The optional part, the installed-command list, uses a kind 10992 event that follows NIP-51. It lets a user keep a personal list of commands they want surfaced for autocomplete or rendered chips. Crucially, this list is a display preference, not an authorization mechanism. Plain-text invocation works with or without it.

In my experience, the most interesting protocol changes are the ones that look boring on paper. This is one of those.

Why This Is a Bigger Deal Than It Looks

Nostr’s core design has always been about events and filters. Relays store events, clients fetch them, and interactions happen through signed notes. NIP-CD adds a layer that turns any event into a potential command surface. A relay operator could publish a /mute command. A bot could offer /tip. A community group could define /ban and /invite scoped to its own event kinds.

I think the real significance here is discoverability. Until now, bots and automated services on Nostr had no standardized way to advertise what they could do. They relied on out-of-band documentation, pinned notes, or client-specific integrations. NIP-CD gives them a machine-readable catalog. That’s a quiet shift toward a more composable protocol, one where services can announce their interfaces without asking permission from a client developer.

The Risks Nobody’s Talking About

Every new invocation surface is also a new attack surface. NIP-CD says that without a qualifier, every command whose trigger matches and whose scope includes the event can act on a single message. One /ping could trigger five different services if five executors have published that command with overlapping scopes. That’s elegant in theory. In practice, it’s a spam and noise vector that relay operators will have to police.

The spec also leaves client behavior largely undefined. Clients may offer autocomplete, argument pickers, and rendered chips, but they must not require their own support before sending an invocation. They must send text that fails to parse as ordinary content. That’s a sensible fallback, but it means the user experience will vary wildly from client to client until patterns settle. I’ve seen enough protocol rollouts to know that “optional” often means “fragmented” for the first six months.

What to Watch Next

The Nostr Compass page on NIP-CD notes that the merge does not show which clients have implemented the installed-command list. That’s the metric to track. If a major client like Amethyst or Damus ships a command picker in the next few weeks, NIP-CD becomes real infrastructure. If nobody builds the UI layer, it stays a spec that only relay operators and bot developers care about.

In my experience, the protocols that win are the ones that get implemented quietly by one or two serious teams before anyone writes a think piece. NIP-CD has that profile. It’s not flashy. It’s not controversial. It’s just a small, well-scoped addition that makes Nostr a little more programmable. And that, more than any drama, is what actually moves a protocol forward.

Summary

NIP-CD (Slash Commands) was merged into the Nostr NIPs repository in late October 2026 with minimal fanfare. It defines a standard way for services to publish commands that any user can invoke as plain text in any event, and it adds an optional list for users to track commands they want surfaced in their clients. The spec is well-scoped and technically clean, but it introduces new questions around multi-executor triggering, client fragmentation, and spam mitigation. The key signal to watch is client implementation of the installed-command list; if that ships in a major client, NIP-CD becomes real infrastructure. If it doesn’t, it remains a useful but dormant piece of the protocol’s long tail.