NIP-C0: Code Snippets
Code needs syntax, license and origin metadata
Developers can paste code into any text note, but the result is poor for search, rendering and reuse. A code snippet needs language metadata, filename, extension, runtime, dependencies, license and sometimes a repository origin.
NIP-C0 defines kind 1337 for that object. The code itself lives in content. Tags describe the programming language, file name, extension, short description, runtime, SPDX license, dependencies and repository reference.
The result is not full Git collaboration. NIP-34 handles richer Git-adjacent workflows. NIP-C0 is the small shareable code object: paste a function, make it readable, make its context portable.
Kind 1337 with developer-facing tags
The l tag names the programming language in lowercase. name can be a filename, extension the file extension, description a short explanation and runtime the environment. license needs to use a standard SPDX short identifier. dep tags can repeat for dependencies.
The repo tag can point to a normal URL or to a NIP-34 Git repository announcement in the form 30617:<pubkey>:<d-tag>, with a relay hint.
A client that supports C0 needs to preserve whitespace, syntax-highlight based on language, offer copy and download actions and show licensing clearly.
Code snippets moved from NIP-95 history into C0
Christian Chiarulli added NIP-C0 Code snippets in March 2025 through PR #1852, and fiatjaf renamed the earlier 95 slot to C0 the same day. Valentino Giudice improved the file in November 2025, and mattn and Vincenzo Imperati fixed typos and links in December.
A December 2025 issue asks whether the extension tag repeats information already present in a filename and whether extension values needs to be lowercase. That is the kind of small detail that matters for search and client consistency.
The NIP is therefore practical and still young: useful enough to build, but not as mature as the core event and relay specs.
A code client needs to protect formatting and licensing
Whitespace is content in code. A client needs to avoid smart typography, wrapped indentation or hidden truncation that changes meaning. Copy needs to copy the exact snippet.
License display matters because snippets can be reused. If a user publishes code without a license, the UI must not imply it is automatically free to copy into commercial projects.
Runtime and dependencies can turn a pretty snippet into something executable. When clients offer run buttons, they need sandboxing and clear trust boundaries.
Runnable code is a security surface
A snippet can be malicious, wrong, outdated or context-dependent. Rendering code is low risk; executing it is not. Run features need isolation and user warnings.
Searchable code snippets can also leak secrets if clients make publishing too easy. Compose flows needs to make users review what they are signing.
Read NIP-C0 in the wild
NIP-C0 gives code snippets a portable event shape. It can make small examples, patches and teaching fragments visible in Nostr clients.
Code has supply-chain risk even when it is short. Show language, author, date, license, dependencies and links to a repository when available.
What changes when you actually use it
For you, NIP-C0: Code Snippets is felt when a post becomes a durable object: article, file, image, video, audio, bookmark, wiki entry or source reference. The question is whether the work still makes sense after one app, host or relay disappears. The concrete pieces kind 1, kind 1337, draft, kind:1, kind:1337, .content decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-C0: Code Snippets is context preservation. Store enough title, tag, author, hash, URL, media, preview and reference material that another interface can rebuild the object. If your feature depends on a private database to make sense, the NIP is not doing the portability work yet.
What the official file makes concrete
The official file is organized around Abstract, Event Kind, Optional Tags, Format, Client Behavior. Inspect kind 1, kind 1337, draft, kind:1, kind:1337, .content, name, runtime because these are the pieces most likely to surface as product behavior. Read it beside NIP-34 before treating it as isolated.
NIP-C0: Code Snippets protects context. Titles, media, hashes, source links, timestamps and references decide whether work survives beyond one app.
Where it breaks
The failure mode in NIP-C0: Code Snippets is link rot with a nice interface. Media disappears, metadata lies, source URLs change, hashes are missing or an article loses its addressable identity. The page needs to make durability part of the feature, not an afterthought.
Where this appears outside the markdown
In the ecosystem, NIP-C0: Code Snippets is part of the creator and archive layer. It decides whether writing, media, files, bookmarks, wiki material or source references remain understandable after the first app disappears. That is why media standards need to talk about storage, provenance and recovery, not only presentation.
The nearby-standard trap
The nearby-standard trap in NIP-C0: Code Snippets is flattening every creative object into a note with a link. Articles, videos, files, torrents, highlights, images, wiki entries and bookmarks carry different metadata and storage pressure. Read NIP-34 so the product does not throw away the part that made the object portable.
Language that keeps the feature honest
Good product copy for NIP-C0: Code Snippets names the object and the storage. It says article, file, image, video, bookmark, wiki page, torrent, highlight or podcast episode, then tells you where the signed metadata ends and where external hosting begins.
What this page does not promise
NIP-C0: Code Snippets does not guarantee that published work survives forever. It can carry richer metadata, hashes, references or addressability, but files still need hosts, relays still need retention, and clients still need to render the object faithfully. Treat the NIP as the signed map of the work, then check where the actual bytes, previews and source links live.
Read it as a field test
Start NIP-C0: Code Snippets with the object you want to keep: article, file, media, bookmark, repository, torrent, wiki entry or podcast episode. Then trace which parts are signed, which parts are hosted, and which parts another client can reconstruct from kind 1, kind 1337, draft, kind:1, kind:1337, .content. That is the difference between portable publishing and a pretty link preview.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-C0, Extension tag issue #2148, NIP-34 git stuff, SPDX license list. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-C0 source is the anchor for exact wording, and NIP-C0 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-C0, Extension tag issue #2148, NIP-34 git stuff. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-C0: Code Snippets: first the human promise, then kind 1, kind 1337, draft, kind:1, kind:1337, .content, then the implementation record, then the real-world failure case. That order keeps NIP-C0 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Where do the signed metadata and the actual media or file bytes part ways?
- Can the object still be identified by hash, address, title, author and source if the first URL breaks?
- Does a second client know enough from
kind 1,kind 1337,draft,kind:1to render the work without private context?
What to verify before you rely on it
- Find
kind 1,kind 1337,draft,kind:1,kind:1337in the official file and check where the UI exposes the same concept. - Read NIP-34 as context before treating NIP-C0 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-C0: Code Snippets in that order: Official NIP-C0 source for the current wording; NIP-C0 commit history for the change record; nips.nostr.com NIP-C0, Extension tag issue #2148, NIP-34 git stuff for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
