CraysZappix
Zappix is useful when you want Nostr to behave less like a text timeline and more like a visual feed where pictures, short clips, creators, zaps and portable identity share the same surface.
A visual Nostr client, not another text feed
Zappix is easiest to understand if you begin with what it refuses to make primary. It is not trying to be the broadest Nostr timeline, the strictest microblogging client or a developer console for raw events. Its center of gravity is visual posting. The repository describes it as a social image sharing application for browsing, sharing and zapping visual content. The live title says the same thing: social image sharing on Nostr. That consistency matters because a reader can immediately ask the right question. Zappix is about what happens when the main object in the feed is a picture or short clip, not a paragraph of text.
The app's own language calls image posts Pix and short vertical videos Flix. That is more than branding. The create-post dialog starts with a media type choice. Image posts can contain one or more images. Video posts are treated as short portrait media with explicit limits. The feed, post cards, upload flow, bookmarks, hashtags, reactions, comments and zaps are all arranged around the media object. A reader does not have to infer that from a generic social UI; it is the product's first promise.
That makes Zappix valuable in a Nostr ecosystem where many clients inherit the shape of Twitter, Mastodon or a chat room. Photo-first clients ask different things from the protocol. They need media metadata, upload authorization, preview behavior, content warnings, location tags, image dimensions, hashes, multiple server choices and a better answer to old links that break. Zappix is therefore interesting even if you already use a general Nostr client. It tests whether Nostr can support a visual creator feed without a single platform owning the account, the storage, the payment rail and the social graph.
Pictures are NIP-68 events with real metadata
The core image format in Zappix is NIP-68, published as kind 20 picture events. The README names this directly, and the create-post code confirms it. When the reader uploads images, the app extracts dimensions, computes a blurhash, uploads the file, builds an imeta tag and publishes kind 20 with the text description as content. The imeta tag can contain the URL, MIME type, dimensions, alt information, blurhash and server-returned file data such as a hash and size.
This is a better fit for image software than pretending a photo is only a URL pasted into a text note. Dimensions help the client lay out the post without guessing. MIME type helps the client decide how to render the asset. Hashes let the user and other software reason about file identity. Alt text is limited here because the app uses the file name by default, but the protocol shape is still much richer than a bare link. The feed can treat the event as an image post because the event kind and tags say what it is.
Zappix also supports multiple images per post. The image card parses imeta tags, collects media URLs and can show a carousel when a post has more than one image. That matters because visual social apps often need albums, not just single attachments. In Nostr terms, each post remains a signed event, but the media payload is described through structured tags. The reader sees a gallery. Other clients can inspect the event and decide how much of that gallery they understand.
Flix adds short vertical video to the same surface
Zappix's video work gives the app a second identity: not just a photo feed, but a small short-video experiment. The NIP implementation document says uploaded videos are published as kind 22 short-form portrait video events. The create-post dialog enforces the product direction before the event is signed. It only accepts video files for video posts, supports MP4, WebM and MOV, checks metadata, rejects horizontal videos and rejects files longer than three minutes.
Those restrictions are product choices, not random validation. A general video archive can accept anything. A short vertical video feed needs predictable shape, length and playback behavior. Zappix tries to keep new uploads in that lane while still reading older or broader video formats. The video post component and validators include support for NIP-71-style kind 21 and kind 22 video, legacy vertical kind 34236 events and OpenVine-style kind 32222 display logic. That means the app can publish one preferred format and still be tolerant when browsing the wider network.
The upload path also tries to make large mobile video less painful. If a video is large, the app can compress it before upload when browser support is available, then attach compression metadata to the tags. The reader does not need to memorize the implementation to appreciate the result: a Zappix video post is not merely a link to a file. It is a signed Nostr event that carries title, duration, media metadata, thumbnail hints where possible, hashtags, optional location and content warning data.
Blossom turns media upload into a signed action
Visual Nostr apps live or die by upload behavior. Zappix does not depend on a private, invisible platform bucket. Its upload hook uses Blossom-style media servers. Before a file is sent, the client calculates the file's SHA-256 hash. It then asks the user's signer to create a kind 24242 authorization event with tags for upload, the file hash and an expiration time. The app sends the raw file with an Authorization header that carries the signed Nostr event.
That flow is one of the most important parts of the whole app. It means the media server can require Nostr-signed authorization without holding the user's account key. The server returns a blob descriptor with a URL, SHA-256 hash, file size, type and upload timestamp. Zappix then turns that result into tags for the post. If the server's hash differs from the local hash, the code warns about the mismatch. If one server fails, the upload path tries the next configured server.
The user's own Blossom server list is also part of the product. Zappix reads the user's media-server preferences from Nostr, and when none are available it falls back to servers such as blossom.primal.net, cdn.satellite.earth and nostr.download. This is the practical tradeoff of decentralized media. You can avoid one app-owned storage backend, but you now need to care which media servers you trust, whether they keep files available, what size limits they enforce, how they moderate, and whether other clients can read the same assets.
Login choices range from signers to nsec
Zappix gives the reader several ways to bring a Nostr identity into the app. The login dialog supports a browser extension path, a Nostr Connect QR path, manual bunker or nostrconnect URIs, and direct nsec entry. The Zapstore description also highlights NIP-46 remote signer support. This range is useful because Zappix is available as a web app and has mobile packaging, but each login path has a different risk profile.
The calmest web path is a NIP-07 browser signer. In that mode, Zappix can ask the extension to provide the public key and sign events without the web app directly holding the user's secret key. The remote signer path is similar in spirit but uses NIP-46-style delegation. The code generates a nostrconnect URI, waits on relay.nsec.app for a kind 24133 response tagged to the client pubkey, decrypts it with NIP-44 and then creates an ongoing NConnectSigner session.
The nsec path is powerful but should be treated with care. The README says the project prioritizes signer-based security, yet the current login UI still permits direct secret-key login and the Nostrify login provider stores login state in browser storage. That is not automatically wrong, but it is different from using a dedicated signer. A reader using a valuable identity should test with an extension or remote signer first. If you paste an nsec into any web app, the page, browser profile, device, extensions and future updates all become part of the trust boundary.
Relays shape what the gallery can see
Zappix's default relay configuration includes relay.primal.net, nos.lol, relay.damus.io and relay.divine.video as read and write relays. The broader default relay list also includes Olas, Snort, Purple Pages and Ditto. This mix makes sense for a visual app. Zappix needs enough general Nostr coverage to find profiles and comments, but it also benefits from media-friendly relays and communities where image posts are common.
The codebase contains an outbox-model document and helper logic, but the main provider is intentionally simple: it routes reads to the configured read relays and publishes to configured write relays. Some feed hooks also query a discovery pool to widen media discovery. That detail matters because a reader should not expect one global Zappix feed to be complete. The app is assembling a useful view from the relays it can reach and the filters it sends.
This is where Zappix teaches the same lesson as many other Nostr clients, but in a more visible way. If your image feed looks thin, the problem may not be that nobody is posting. It may be that the relay set is wrong for visual content, that your following list has little media activity, that a hashtag is quiet, or that a media server failed. Zappix gives you relay settings, global and following feeds, hashtag discovery and Blossom settings, but it cannot make the whole network behave like one centralized image database.
The social layer is familiar but portable
Zappix supports the actions a reader expects from a visual social app: reactions, comments, follows, bookmarks, sharing, profile links, notifications and zaps. The important difference is that these actions become Nostr events rather than rows in one company's database. Reactions are kind 7 events. Comments use kind 1111 in the current notification and post code. Follows are kind 3 contact lists. Bookmarks are stored as a replaceable kind 30003 bookmark set.
The bookmark implementation is especially concrete. Zappix creates a NIP-51 bookmark set with d set to nip-68-posts, title set to NIP-68 Image Bookmarks and e tags for the saved events. That is a clean way to keep Zappix's visual bookmarks organized without inventing an opaque local-only format. The implementation document also says only kind 20 image posts are displayed in the bookmark interface, which keeps the feature focused.
Notifications follow the same pattern of ordinary Nostr data made readable by a client. Zappix looks for reactions, comments and zap receipts related to the user's posts, filters out the user's own interactions and tracks read state locally. Nothing about that makes the social layer magical. It simply means the reader's visible app experience is assembled from signed events that other Nostr tools can also inspect if they support the same kinds and tags.
Zaps are built for small creator payments
Zappix is not just a picture browser with a like button. It treats zaps as a first-class action for visual posts. The zap hook reads zap receipts of kind 9735, extracts amounts from amount tags, BOLT11 invoices or zap-request descriptions and totals the sats attached to a post. When sending a zap, it builds a NIP-57 zap request for the target event, signs it with the user's signer and asks the creator's zap endpoint for an invoice.
The payment order is practical. If the user has an active Nostr Wallet Connect connection, Zappix tries that first. If NWC fails or is absent, it tries WebLN. If neither path completes the payment, it shows an invoice for manual payment. The code also verifies that the invoice amount returned by the Lightning service matches the amount the user requested before paying through NWC. That small check matters because a malicious or broken LNURL endpoint should not be able to quietly inflate an invoice.
The settings page is explicit about the NWC trust model. It accepts nostrwalletconnect:// and nostr+walletconnect:// strings, stores connections in local storage and warns that automatic zap payments should use spending limits. That is exactly the sort of warning readers should take seriously. NWC can make zapping feel effortless, but effortless payments are still payments. Test with small amounts, use limited wallet connections and understand which app can ask the wallet to pay.
Discovery is built around feeds, hashtags and location
Zappix has a global feed, a following feed and hashtag discovery. The image feed hook queries kind 20 events, can filter by hashtag, can filter by location tags, validates events before display and filters deleted or muted content. The video feed does the same kind of work for video kinds. Following feeds restrict authors to the people the user follows, while global and hashtag views widen the scan.
Location support is another visual-app detail that makes sense here. The create-post dialog can attach a human location tag and a geohash tag. The post components can parse and show those tags. That does not turn Zappix into a full mapping app, but it lets visual posts carry context that text timelines often ignore. Photography, travel, events, local scenes and creator work all benefit from knowing where a picture or clip belongs.
The discovery experience is still young compared with a mature platform. There is no centralized ranking engine that can guarantee the best images. Relays, hashtags and authors determine what appears. But that is also the point. Zappix is a client-side view over open events. A creator can publish visual posts that are not trapped inside one service, and a reader can discover them through several lenses instead of one opaque platform feed.
The web app is also moving toward mobile
The technology stack explains why Zappix feels like a modern web app instead of a server-rendered archive. It uses React 18, TypeScript, Vite, Tailwind, shadcn UI, Radix components, TanStack Query, React Router, Nostrify, nostr-tools, Alby's SDK, WebLN, QR rendering, Capacitor and PWA tooling. The manifest names Zappix as a social image sharing app on Nostr and provides installable icons. The app provider stores configuration under nostr:app-config, while the Nostr login provider stores login state under nostr:login.
The mobile direction is not only theoretical. The repository includes Capacitor configuration with app id app.zappix and app name Zappix. The Android build file shows version name 2.7.8 and version code 10. The Zapstore file identifies the package as app.zappix, points to the repository and website, lists MIT as the license and describes the product as social image sharing on Nostr with NIP-68 picture events. That gives Zappix a path beyond a browser tab.
For the reader, mobile packaging cuts both ways. A mobile app can make camera, upload, scrolling and signer integration feel more natural. A PWA or Capacitor shell can also blur the line between web code and installed software. The right test is not whether Zappix is web or native. The right test is whether the login mode, upload servers, relay settings, wallet connection and update path are understandable enough for the identity and money you plan to use.
Content warnings and deletions are client-visible promises
Open visual feeds need moderation tools that ordinary text clients can sometimes postpone. Zappix includes content-warning support at post creation and display. If a post is marked with a content-warning tag, the card can blur or gate the media until the reader chooses to reveal it. The app also supports muted users and filters deletion requests so deleted events do not remain visible in the normal feed.
These tools are useful, but they should not be misunderstood. A content warning does not remove the media from the network. A deletion event asks clients to hide or remove an event, but relays and other clients may have already copied it. A mute list changes what the current reader sees. Media server retention depends on the storage server. In an image app, these differences are not academic. A photo can spread farther and feel more permanent than a text note.
Zappix's advantage is that the relevant signals are visible in event data. Content warnings are tags. Deletions are events. Muting and filtering are client behavior. That is more transparent than a platform where moderation state is hidden behind an internal policy database. It also asks more from the reader. Before posting sensitive media, assume public Nostr events and public media URLs can be copied, indexed and preserved by parties outside Zappix.
What to test before using Zappix seriously
Start with a low-risk identity. Open the live app, connect with a NIP-07 signer or NIP-46 remote signer, and publish a small test image. Inspect the event in another Nostr client if possible. Confirm that the image appears, that the imeta tags look sane, that the media URL loads and that the same post is discoverable from at least one relay outside Zappix. Then test a bookmark, a reaction and a comment so you understand which actions become public events.
Next, test upload and storage. Change Blossom settings, upload a file, compare the returned media URL, and see what happens if a server is slow or unavailable. If you post video, check the vertical and duration rules before you rely on the flow. Try a small Flix upload, verify that the post is kind 22, and confirm whether another client can display it. Visual interoperability is still uneven across Nostr, so one successful post inside Zappix is only the first half of the test.
Finally, test money with tiny amounts. Add an NWC connection only if it has spending limits you are comfortable with. Make a one-sat or low-sat zap, confirm invoice amount behavior, then disconnect or lower limits if you are only experimenting. Zappix is strongest when it is treated as a real Nostr media client with real keys, real files and real payments. That is why the boring checks matter: signer choice, relay coverage, server retention, wallet limits and public event visibility are the difference between a fun photo feed and an accidental trust mistake.
Sources worth opening
Start with the live app, README and Zapstore file, then compare the upload, login, zap, relay, bookmark, notification and media components against the relevant NIPs.
- Zappix live app
- Zappix login page
- Zappix explore page
- Zappix GitHub repository
- Zappix README
- Zappix custom Nostr implementation notes
- Zappix package.json
- Zappix Zapstore metadata
- Zappix web manifest
- Zappix Capacitor config
- Zappix Android build file
- Zappix app provider and default relays
- Zappix app routes
- Zappix Nostr provider
- Zappix create post dialog
- Zappix upload hook
- Zappix Blossom server hook
- Zappix image feed hook
- Zappix video feed hook
- Zappix all-video hook
- Zappix image post component
- Zappix video post component
- Zappix zap hook
- Zappix zap settings
- Zappix NWC hook
- Zappix login dialog
- Zappix login actions
- Zappix bookmark hook
- Zappix following hook
- Zappix notification hook
- Zappix event validators
- Zappix media utilities
- Zappix video compression utility
- Zappix outbox model notes
- Zappix GitHub releases
- Zappix GitHub issues
- NIP-68 picture-first feeds
- NIP-71 video events
- NIP-57 Lightning zaps
- NIP-25 reactions
- NIP-22 comments
- NIP-51 lists
- NIP-65 relay list metadata
- NIP-46 remote signing
- NIP-07 browser extension signing
- NIP-09 event deletion
- Blossom project
- Nostrify repository
- Alby SDK repository
- Capacitor documentation
