NIP-5A: Static Websites (nsites)
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 user-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 needs to show the site title, pubkey, named-site identifier, manifest version, source link where present and the Blossom servers being used. People needs to 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 needs to display the pubkey and source lineage clearly so people know what authority they are trusting.
Read NIP-5A in the wild
NIP-5A points at static websites on Nostr. The interesting idea is that a site can become a signed, portable publication object rather than only a folder on one host.
The product challenge is web trust. Names, routes, assets, updates and authorship need to remain understandable, or a portable static site becomes another place where people cannot tell who controls the page.
What changes when you actually use it
For you, NIP-5A: Static Websites (nsites) is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms draft, d, pubkeyB36, a, A, title are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-5A: Static Websites (nsites) needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
The official file is organized around Site Manifests, Named Sites, Manifest Snapshots, Aggregate Hash, Upstream App Descriptors, Copying nsites, Host server implementation, Examples. Inspect draft, d, pubkeyB36, a, A, title, source, created_at because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-34, NIP-89 before treating it as isolated.
NIP-5A: Static Websites (nsites) earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-5A: Static Websites (nsites) is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-5A: Static Websites (nsites) is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-5A: Static Websites (nsites) is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-01, NIP-34, NIP-89 to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-5A: Static Websites (nsites) names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-5A: Static Websites (nsites) does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-01, NIP-34, NIP-89 and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-5A: Static Websites (nsites) with interoperability. If draft, d, pubkeyB36, a, A, title cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-01, NIP-34, NIP-89 and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: Awesome nsite, Nostr Compass: NIP-5A, Blossom, NIP-34 Git stuff. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-5A source is the anchor for exact wording, and NIP-5A commit history shows how that wording moved over time. The strongest secondary clues here are Awesome nsite, Nostr Compass: NIP-5A, Blossom. 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-5A: Static Websites (nsites): first the human promise, then draft, d, pubkeyB36, a, A, title, then the implementation record, then the real-world failure case. That order keeps NIP-5A useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
draft,d,pubkeyB36,a, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
draft,d,pubkeyB36,a,Ain the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-34, NIP-89 as context before treating NIP-5A 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-5A: Static Websites (nsites) in that order: Official NIP-5A source for the current wording; NIP-5A commit history for the change record; Awesome nsite, Nostr Compass: NIP-5A, Blossom 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.
