NIP-92: Media Attachments Metadata
A media link without metadata is a bad cross-client contract
Nostr events often include images, videos or files hosted somewhere else. A bare URL tells a client almost nothing: not the MIME type, not the dimensions, not the hash, not the alt text, not the fallback URL and not whether a preview needs to be shown.
NIP-92 solves that with the variadic imeta tag. The tag needs to match a URL in the event content and carry structured key/value entries about that media. Clients may replace the URL with a rich preview if they trust the metadata.
This is a small NIP with a large visual impact. Picture feeds, video feeds, long-form articles and chat clients all become better when they can share media metadata.
imeta is inline metadata for a specific URL
Each imeta tag must include a url entry and at least one other field. It can use fields defined by NIP-94, such as MIME type, SHA-256 hash, original hash, size, dimensions, magnet link, blurhash, thumbnail, summary, alt text, service and fallback URLs.
The tag is deliberately attached to URLs in content. A client can ignore an imeta tag that does not match a URL in the event, which prevents detached metadata from claiming too much.
NIP-68 picture events and NIP-71 video events rely heavily on this style of media metadata.
imeta moved from scattered media work into its own NIP
Jon Staab added the imeta tag in November 2023. In February 2024, fiatjaf moved imeta to NIP-92 and added the tag to the README. Asai Toshiya later clarified that clients can ignore unmatched imeta tags, and Kieran updated the file in January 2025.
The history crosses NIP-29, images, files and media event work. That tells you what NIP-92 really is: the common vocabulary other media NIPs needed.
It is not a file-hosting standard. It is the metadata layer that lets externally hosted media behave better inside signed Nostr events.
Render previews, but verify what matters
A client needs to use dim for layout, alt for accessibility, blurhash for loading states, m for media handling and fallback when the main host fails. Hashes needs to be verified where possible, especially for files that matter beyond a casual preview.
Upload flows can add imeta after the file is uploaded. Paste flows may download the file and fill metadata before publishing. Both paths needs to avoid surprising users by sending private media to unknown hosts.
NIP-92 is at its best when it makes the same event look polished in several clients without each one scraping the web again.
Metadata can lie if clients never verify it
A malicious event can attach false MIME types, dimensions or descriptions. Clients need to treat imeta as a signed claim, not as ground truth. For high-value files, hashes matter.
The opposite risk is ignoring imeta entirely. That makes Nostr media feel broken, especially for users who rely on alt text or clients with constrained layouts.
Read NIP-92 in the wild
NIP-92 gives media attachments richer metadata. Instead of a naked URL, an event can carry size, type, dimensions, blurhash, hashes and other clues.
This is where user experience and verification meet. A client can show previews and also check that the file is what the author intended, if the metadata is complete.
What changes when you actually use it
For you, NIP-92: Media Attachments Metadata (imeta) 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 imeta decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-92: Media Attachments Metadata (imeta) 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 Example, Recommended client behavior. Inspect imeta because these are the pieces most likely to surface as product behavior.
NIP-92: Media Attachments Metadata (imeta) 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-92: Media Attachments Metadata (imeta) 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-92: Media Attachments Metadata (imeta) 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-92: Media Attachments Metadata (imeta) 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-01 and the adjacent source links 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-92: Media Attachments Metadata (imeta) 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-92: Media Attachments Metadata (imeta) 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-92: Media Attachments Metadata (imeta) 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 imeta. 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-92, Net::Nostr::MediaAttachment, NIP-94 File Metadata. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-92 source is the anchor for exact wording, and NIP-92 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-92, Net::Nostr::MediaAttachment, NIP-94 File Metadata. 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-92: Media Attachments Metadata (imeta): first the human promise, then imeta, then the implementation record, then the real-world failure case. That order keeps NIP-92 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
imetato render the work without private context?
What to verify before you rely on it
- Find
imetain the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-92 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-92: Media Attachments Metadata (imeta) in that order: Official NIP-92 source for the current wording; NIP-92 commit history for the change record; nips.nostr.com NIP-92, Net::Nostr::MediaAttachment, NIP-94 File Metadata 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.
