NIP-96: HTTP File Storage Integration
Nostr needed upload servers without making relays host blobs
Relays are good at signed events. They are not designed to host every image, video, audio file or document users attach. NIP-96 separated the problem: clients can upload files to HTTP storage servers, then reference the resulting URLs from Nostr events.
A NIP-96 server advertises itself at /.well-known/nostr/nip96.json. The document points to an API URL, optional download URL, terms, content types, plans, expiration ranges and whether NIP-98 auth is required.
That architecture made sense for a period of Nostr media growth. It gave clients a standard way to discover upload capabilities without inventing a new per-client file API.
A REST upload API with Nostr authentication hooks
NIP-96 covers server discovery, upload, list, delete, plan metadata, download delegation and relay hints. Uploads can be authenticated with NIP-98, which signs the HTTP method, URL and optional payload hash through a kind 27235 event.
The server can publish supported content types, max byte sizes, expiration ranges and media transformations. That lets a client know whether it can upload a video, whether resizing happens and whether files might expire.
The top-line status is now the most important fact: the file is marked unrecommended, with a warning that it is deprecated in favor of NIP-B7.
A useful bridge standard overtaken by Blossom
arthurfranca added the HTTP file storage work in January 2024. Kieran updated list responses in May 2024, and several typo and format cleanups followed. On September 9, 2025, Vitor Pamplona deprecated NIP-96 through PR #2047. On May 31, 2026, fiatjaf added the unrecommended warning to NIP bodies.
The ecosystem still has traces. Route96 describes itself as a Blossom/NIP-96 server. The awesome-blossom list includes Nostrcheck-server as supporting NIP-96, NIP-05 and other sovereign tools. Rust libraries also expose NIP-96 clients.
That means builders may still encounter it, but new design needs to check Blossom/NIP-B7 first.
Treat NIP-96 as compatibility, not the future path
A client that supports existing NIP-96 servers needs to read the well-known document carefully, respect content types and plan limits, sign uploads with NIP-98 where required and store returned URLs with NIP-92 or NIP-94 metadata.
For new storage infrastructure, the page needs to send people to Blossom and NIP-B7. Blossom's content-addressed approach and server lists better match the direction of Nostr media storage.
The honest UX is to support old upload flows where users need them while explaining why newer clients may prefer Blossom.
File expiration and trust can surprise users
NIP-96 plans may include expiration ranges. A user may think a file is permanent because the Nostr event is permanent, while the media host is temporary. Clients need to make expiration visible.
Upload servers can also transform, moderate or delete files. NIP-94 hashes and fallbacks reduce the pain, but storage policy remains outside the signed event.
Read NIP-96 in the wild
NIP-96 describes HTTP file storage integration. It gives clients a way to upload media to storage services while keeping Nostr events separate from large binary hosting.
The upload server becomes a trust and policy actor. Auth, deletion, quotas, content rules, URLs and hash verification all need to be visible.
What changes when you actually use it
For you, NIP-96: HTTP File Storage Integration 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 10096, unrecommended, draft, Authorization, payload, multipart/form-data decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-96: HTTP File Storage Integration 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 Introduction, Server Adaptation, Relay Hints, List of Supporting File Storage Servers, Auth, Upload, Response codes, Delayed Processing. Inspect kind 10096, unrecommended, draft, Authorization, payload, multipart/form-data, file, expiration because these are the pieces most likely to surface as product behavior. Read it beside NIP-B7, NIP-98, NIP-94 before treating it as isolated.
NIP-96: HTTP File Storage Integration 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-96: HTTP File Storage Integration 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-96: HTTP File Storage Integration 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-96: HTTP File Storage Integration 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-B7, NIP-98, NIP-94 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-96: HTTP File Storage Integration 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-96: HTTP File Storage Integration 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-96: HTTP File Storage Integration 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 10096, unrecommended, draft, Authorization, payload, multipart/form-data. 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: Deprecates NIP-96 PR #2047, Route96, awesome-blossom, NIP-B7 Blossom media. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-96 source is the anchor for exact wording, and NIP-96 commit history shows how that wording moved over time. The strongest secondary clues here are Deprecates NIP-96 PR #2047, Route96, awesome-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-96: HTTP File Storage Integration: first the human promise, then kind 10096, unrecommended, draft, Authorization, payload, multipart/form-data, then the implementation record, then the real-world failure case. That order keeps NIP-96 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 10096,unrecommended,draft,Authorizationto render the work without private context?
What to verify before you rely on it
- Find
kind 10096,unrecommended,draft,Authorization,payloadin the official file and check where the UI exposes the same concept. - Read NIP-B7, NIP-98, NIP-94 as context before treating NIP-96 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-96: HTTP File Storage Integration in that order: Official NIP-96 source for the current wording; NIP-96 commit history for the change record; Deprecates NIP-96 PR #2047, Route96, awesome-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.
