NIP-5A: Static Websites (nsites)
NIP-5A turns a Nostr key into a static website publisher: signed site manifests map URL paths to Blossom content hashes, while named sites, snapshots and aggregate hashes make the site portable.
A static site can be signed by a person, not only hosted by a domain
NIP-5A is about publishing websites without making DNS and a single web host the only source of truth. The actual files live as Blossom assets. The Nostr event is the signed manifest that says which file hash belongs at which path.
That is a subtle but important shift. A site becomes something a pubkey announces. A client, gateway or host can resolve the manifest, fetch the blobs and serve the same site. If one host disappears, the site identity can survive as long as the manifest and blobs are still discoverable.
The standard fits the larger Nostr pattern: signed identity, replaceable state and content-addressed storage. It is not trying to make relays serve web pages. It lets relays carry the site map and lets Blossom servers carry the files.
Root sites, named sites, path hashes and snapshots
A root site uses kind 15128 and must not include a d tag. It is the one root site for a pubkey. Named sites use kind 35128 and must include a short d tag. Because the canonical name has to fit beside a base36 pubkey inside DNS-label limits, the named-site identifier is limited to 1 to 13 lowercase letters, numbers or hyphens.
The heart of the manifest is the path tag: absolute path, sha256 hash. A manifest can also carry an aggregate x hash, Blossom server hints, title, description and source links. Copied sites use a and A tags to preserve immediate parent and origin lineage.
Manifest snapshots use kind 5128. That gives tools a way to capture a specific site state rather than only the latest replaceable manifest. The June 2026 aggregate-hash and snapshot work is what makes nsites feel more like versioned publishing instead of only a pointer list.
A very new NIP shaped by Blossom and nsite tooling
NIP-5A is young. hzrd149 added the static websites work in March 2026, and the file was renamed for clarity in April. In June 2026, PR #2287 added aggregate hashes and site snapshots, giving the format a stronger versioning story.
The short history is not a weakness. It is a warning label. nsites are promising and already have tooling interest, but the ecosystem is still early compared with notes, relays or zaps.
The awesome-nsite repository is useful because it maps the surrounding tools and specs: the NIP-5A spec, Blossom, nsite versions and host tooling. Nostr Compass also gives a reader-facing explanation of signed manifests and Blossom storage.
The gateway has to verify the manifest, not merely serve files
A correct nsite host or gateway needs to fetch the user's manifest, verify the event signature, resolve the requested path, fetch the blob with the matching sha256 hash and serve it with the right content behavior. If it skips hash verification, the whole integrity story collapses.
The nsite tooling world sits close to Blossom. That means operators have to understand both event resolution and blob availability. A beautiful manifest is not enough if the referenced blobs vanish from every server.
A good product UI should show the site title, pubkey, named-site identifier, manifest version, source link where present and the Blossom servers being used. Readers should be able to tell whether they are seeing a current root site, a named site or a fixed snapshot.
Publishing gets portable, but availability remains physical
NIP-5A can make a site's identity portable, but it cannot force Blossom servers to keep every file forever. Authors still need redundancy, source archives and monitoring.
There is also a phishing risk. A signed pubkey site is not the same thing as a familiar DNS brand. Clients and gateways should display the pubkey and source lineage clearly so readers know what authority they are trusting.
Direct sources
The links below are part of the article, not decoration. Start with the official NIP, then read the file history, implementation references and adjacent standards before treating the page as product guidance.
