NIP-68: Picture-first feeds
A photo feed must not be a text note with a picture attached
Nostr can already carry images in ordinary notes, but an Instagram-like feed needs the image to be the center of the object. NIP-68 creates kind 20 for picture-first posts, where clients can expect rich image metadata instead of scraping a caption for media URLs.
That matters for clients built around photography, memes, art, travel, screenshots and image collections. A picture-first client wants dimensions, alt text, hashes, fallback URLs, thumbnails, sensitive-content warnings, locations and tagged people. Those are not decoration; they decide whether the post can be rendered well, searched, moderated and preserved.
The NIP also draws a boundary with NIP-71. Picture events can sit in the same visual feed as short video, but they are not the same object.
Kind 20 and self-contained imeta image records
A picture event uses kind 20. The content field is the description and a title tag names the post. One or more imeta tags describe images with URL, media type, thumbhash or blurhash, dimensions, alt text, sha256 hash, fallback URLs and optional user annotations.
The image list is meant to be self-contained. A client needs to not need to guess what image belongs to the post or which fallback to try. Hash tags make images queryable. Language tags help when text is embedded in the image. Location and geohash tags make photo discovery possible without inventing a separate map format.
Only specific image MIME types are accepted. That constraint keeps clients from treating arbitrary file links as picture-feed media.
Vitor Pamplona pushed the Instagram-feed shape into the NIP set
The visible NIP-68 history starts in October 2024 with Vitor Pamplona's Instagram feeds work. The same cluster of commits added media-type enforcement, language tags for text in images, location metadata, sha256 indexing through x tags and simplifications.
In January 2025, related video-event changes clarified the relationship with NIP-71. In April 2026, fiatjaf mentioned optional thumbhash alongside blurhash. The history is a good example of an app-shaped NIP: product needs led to an event kind, then the metadata got stricter.
A picture feed without alt text, hashes and dimensions becomes a pile of pretty links. NIP-68 tries to avoid that.
The useful client is an image viewer, not a link previewer
Olas-style and picture-first clients need to render grids, carousels, alt text, sensitive-content controls, user annotations and fallback selection. They needs to also verify hashes where possible, because external image hosting can mutate or disappear.
Accessibility is a real implementation concern. The alt metadata and language tags are how a picture feed becomes readable beyond the visual surface.
A good NIP-68 post survives across clients: one app publishes it, another displays the right image sizes, a third indexes the hashes, and a fourth can still show a meaningful fallback.
Image feeds carry moderation and permanence problems
Images are harder to moderate and easier to miscontextualize than text. NIP-68 includes content-warning, alt and hash tools, but communities still need policy and clients still need safe defaults.
External hosting also remains a weak point. A signed event can point at an image, but if every host removes the file the post becomes a memory of metadata.
Read NIP-68 in the wild
NIP-68 supports picture-first feeds. It lets photo-heavy posts become structured objects instead of generic notes with media links scraped from text.
Images carry hidden complexity: storage, hashes, thumbnails, captions, copyright, location metadata and takedowns. A beautiful feed still needs a recoverable media trail.
What changes when you actually use it
For you, NIP-68: Picture-first feeds 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 draft, imeta, title, .content, image/webp decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-68: Picture-first feeds 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 Picture Events. Inspect draft, imeta, title, .content, image/webp because these are the pieces most likely to surface as product behavior. Read it beside NIP-71 before treating it as isolated.
NIP-68: Picture-first feeds 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-68: Picture-first feeds 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-68: Picture-first feeds 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-68: Picture-first feeds 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-71 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-68: Picture-first feeds 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-68: Picture-first feeds 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-68: Picture-first feeds 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 draft, imeta, title, .content, image/webp. 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: NIP-92 Media Attachments, NIP-94 File Metadata, NIP-71 Video Events. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-68 source is the anchor for exact wording, and NIP-68 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-92 Media Attachments, NIP-94 File Metadata, NIP-71 Video Events. 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-68: Picture-first feeds: first the human promise, then draft, imeta, title, .content, image/webp, then the implementation record, then the real-world failure case. That order keeps NIP-68 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
draft,imeta,title,.contentto render the work without private context?
What to verify before you rely on it
- Find
draft,imeta,title,.content,image/webpin the official file and check where the UI exposes the same concept. - Read NIP-71 as context before treating NIP-68 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-68: Picture-first feeds in that order: Official NIP-68 source for the current wording; NIP-68 commit history for the change record; NIP-92 Media Attachments, NIP-94 File Metadata, NIP-71 Video Events 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.
