ZapStore

Apps23 min readsigned Android releases over Nostr

ZapStore

ZapStore, styled by the project as Zapstore, is what happens when an app store stops being only a company database and starts being a set of signed Nostr events, relay catalogs, APK hashes, social recommendations and direct developer payments.

The store is the social graph

ZapStore sounds simple until you slow down and ask what an app store normally does. A store is a catalog, a search engine, a review surface, a payment path, a trust badge, a takedown authority, an update channel and a habit. Google Play and Apple's App Store combine those jobs inside one corporate system. F-Droid separates some of them into a free software repository. Obtainium lets power users follow upstream releases. ZapStore tries a different split: the developer signs the software trail, relays carry the app metadata, users bring their Nostr identity, communities curate catalogs, and Bitcoin zaps give the payment path a social shape.

The project's own front page says the quiet part loudly: you should not need permission to use apps. That is the hook, but the better sentence is lower on the page: apps are published by developers and curated by communities. That is not just anti-platform rhetoric. It is a claim about where authority moves. The developer becomes visible as a Nostr pubkey. The release becomes an event. The store catalog becomes something a relay can serve and another relay can replace. The recommendation layer can come from people you follow, not only from paid placement or editorial ranking. The user still has to make trust decisions, but those decisions are made in a system where the evidence can travel.

For a normal Android user, the product promise is concrete. You install ZapStore on an Android 10+ arm64 device, browse a catalog, search by app name or repository URL, tap an app and install. You do not need a Nostr account just to look around. If you connect a Nostr identity, the store becomes more social: you can see what people you follow use or recommend, leave comments and send zaps to developers. NostrApps summarizes the user-facing pitch as a permissionless app store with many apps, a cleaner feel than Google Play and a broader catalog than F-Droid. The official ZapStore site now claims 3,000+ apps and highlights releases, comments, labels and zaps as first-class app-store signals.

The deeper point is that ZapStore is not only a place to get Nostr apps. It is a Nostr app for getting apps. That difference matters. Olas, Citrine, Flotilla, Nostrudel, White Noise, Relay Tools and other Android-adjacent projects can use it as a distribution rail, but the underlying idea is bigger than Nostr-native social clients. A project can publish an Android build, attach source and metadata, let the app be discovered through people and catalogs, and receive value directly. If ZapStore works, Nostr is not only a feed protocol or a login method. It becomes a public coordination layer for software distribution.

What a release becomes

ZapStore's technical center is the release record. In the old mental model, an app page lives in a store database and the APK is the thing you download. In ZapStore's model, the app page, the release and the binary asset are separate pieces of signed public evidence. The ZapStore event trail and the Nostr kind registry describe a software application event at kind 32267. It can contain the app id, name, icon, images, tags, website, repository, license, supported platform and pointers to the latest release. ZapStore's own app id, dev.zapstore.app, is tied to the project repository and the android-arm64-v8a platform.

The publishing tool, zsp, makes that more explicit. Its README says it publishes three Nostr event types: kind 32267 for application metadata, kind 30063 for the software release, and kind 3063 for the software asset. In plain English: one event describes the app, one event describes the version, and one event describes the file. The asset event can include the SHA-256 hash, file size, download URL, MIME type, version code, Android platform identifiers and APK certificate hash. That separation is why ZapStore can talk about a verifiable chain instead of just a prettier download button.

This is where the Nostr pieces become less abstract. NIP-34 matters because repositories can be announced or referenced as Nostr-addressable code projects. NIP-51 matters because release artifact sets already live in the Nostr vocabulary. ZapStore's app spec calls its application kind part of the NIP-82 draft trail, but it also leans on existing event patterns, including addressable events and release sets. NIP-09 matters because deletion events can remove catalog entries or stale records. NIP-46 and NIP-07 matter because a developer should not be forced to paste a private key into a command line forever; zsp can sign through a remote bunker or a browser extension. NIP-57 matters because the store can route zaps to builders through their Nostr profiles.

The file layer points beyond relays. ZapStore and zsp use Blossom-style storage for icons, screenshots and APKs, with cdn.zapstore.dev as the default content endpoint in the CLI docs. That is a useful design boundary. Relays are good at events. They are not meant to be heavy binary warehouses. The event says what the file should be; the content address and hash give the client something to verify. If a GitHub asset changes under the same release tag, ZapStore's Android code even has a CDN-by-hash retry path, which tells you the system is built around the hash as a real source of truth, not an afterthought.

The Android app is not a web shortcut

The main ZapStore client is a Flutter app, not a thin web wrapper. The GitHub repository says the mobile app is written in Dart, uses Flutter 3.38.6, is MIT licensed and builds APKs from source. The current public repository version is 1.0.6+1006, and GitHub lists release 1.0.6 as the latest stable APK published on April 11, 2026. The release asset is zapstore-1.0.6.apk. On the same week, the changelog says 1.0.6 fixed a signature mismatch issue by blocking only on actual mismatch, while 1.0.5 improved certificate verification error messages and catalog deletion behavior.

The dependencies tell a lot about the product. purplebase appears in the app as the local Nostr storage layer. models carries the Nostr data model. amber_signer connects ZapStore to Amber, the Android signer used across the Nostr ecosystem. background_downloader, workmanager, flutter_local_notifications, permission_handler and device_info_plus show that installs and updates are not just web requests; they are Android lifecycle work. flutter_secure_storage is used for local settings, including Nostr Wallet Connect strings, custom app catalog relays, seen timestamps and whether installed-app backups are enabled.

The main app code sets the default catalog relay to wss://relay.zapstore.dev and loads custom catalog relays before storage initialization. That order matters. A user can configure the relay set even while signed out, and the app can seed a local database on first launch so a fresh install is not an empty screen. The same code automatically signs a user out if Amber is removed while the user is signed in, which is an ordinary but important safety behavior: if your signer disappears, the app should not pretend the account is still usable.

The package-manager code reads like a product that has fought real Android edge cases. The install status enum includes started, verifying, pendingUserAction, installing, systemProcessing, success, failed and cancelled. The Android package manager code contains a user-facing error for APK signing certificate mismatch: the file may have been tampered with. It tracks signature hashes from installed packages, handles pending system install dialogs and preserves cancellation state instead of letting native retries overwrite a user's refusal. That is the part you want in an app store: boring defensive handling around the moment a binary crosses into a phone.

There is also an update story. The 1.0.0 milestone covered by Nostr Compass described a new updates screen, polling and batch tracking, download watchdog changes, dynamic concurrent download limits, installed-package syncing and better version comparison. Later ZapStore changelog entries added backup and restore for app collections, better latest-release fetching, catalog seeding changes and more certificate verification fixes. That is why the article should not freeze ZapStore as a 2024 experiment. By June 7, 2026, it has a stable 1.0 line, an active repository, a current website, a public relay and a shipping app with real install logic.

Publishing is a developer workflow

ZapStore is also a developer product. The developer page is blunt: what if your app could not be deleted by Google, shipped the moment you signed it, did not lose a cut to a middleman and answered to you? That is marketing, but the workflow underneath is concrete. The current publishing path is zsp, a Go CLI created by the ZapStore team. Its docs describe a wizard, zsp publish --wizard, that can choose sources, gather metadata, sign events and publish to relays. It can fetch APKs from GitHub, GitLab, Codeberg, Gitea/Forgejo, F-Droid, IzzyOnDroid, direct URLs or local files.

The zapstore.yaml file is the small anchor between a code repository and a Nostr identity. ZapStore's own repository has one: repository URL, local release source path, changelog file and MIT license. The publishing docs say a new developer's first publish creates or uses a zapstore.yaml containing the repository and pubkey. The default relay fetches that file, checks whether the pubkey matches the signing key and then whitelists future publishes. That is a clever compromise. It does not require every new builder to ask a person for approval, but it also does not let any random key immediately impersonate a project with no evidence. The same first-publish path can link an APK signing certificate to the Nostr identity through ZapStore's NIP-C1 cryptographic identity proof work.

The CLI is practical about messy release channels. It can enrich metadata from GitHub, GitLab, F-Droid or Google Play. It can select APKs from release assets and prefer arm64-v8a. It supports variants, release channels, commit hashes for reproducible-build context, a check mode, an offline mode and CI/CD use. Its environment defaults are wss://relay.zapstore.dev for relays and https://cdn.zapstore.dev for Blossom uploads. For signing, it supports nsec, hex private keys, unsigned npub output, NIP-46 bunkers and NIP-07 browser signing. The docs specifically warn that putting an nsec in an environment variable can leak through shell history or process environment, and recommend a bunker or browser signing for production.

This matters because the product is not only aimed at people who already know Nostr. A normal Android developer may understand APK signing, GitHub releases and app metadata, but not Nostr relays or addressable events. zsp gives that developer a bridge. It parses the APK, extracts package id, version, certificate fingerprint, icon and permissions, builds the events, uploads files to Blossom and publishes. The developer still needs to care about key custody, release hygiene and support, but the workflow is recognizable enough to be used.

Trust is layered, not magical

ZapStore's best sentence is not "permissionless." It is "trust comes from cryptographic signatures, social context and reputation." That sentence admits the hard part. A permissionless app store cannot promise the same kind of safety as a heavily moderated corporate store, and a corporate store cannot promise the same kind of user agency as an open catalog. ZapStore chooses a layered model and then asks the user to read the layers.

The default relay does not accept every publish blindly. The trust model page says first-time publishers are checked through an explicit allow list, repository verification through zapstore.yaml, Vertex reputation, or rejection. It also says pubkeys can be blocked for malware, spyware, impersonation or Terms violations, and that blocked keys cannot publish new events to the default relay. At install time, ZapStore verifies that the release event is signed by the developer's Nostr key, that the APK hash matches the downloaded file and that a linked APK signing certificate matches when certificate linking is present.

That is stronger than "trust us," but it is not magic. A developer can publish a malicious app under their real key. A user can follow careless people. A community catalog can have bad standards. A relay can remove a pubkey for reasons you disagree with. A Nostr key can be compromised. An APK can request permissions that are legitimate for one app and suspicious for another. ZapStore reduces some platform risks, especially opaque gatekeeping and unverifiable binaries, but it shifts more judgment onto visible identity, public evidence, social trust and client behavior.

The key design choice is that a moderation decision on the default relay is not supposed to be the end of the road. The trust model says relay.zapstore.dev is the default catalog, not the only catalog. Users can configure ZapStore to read from other relays, and developers can publish to other relays with different rules. The enterprise page extends that idea: organizations can run private branded catalogs, self-host catalog relays, set policy and ship a white-label client for users on de-Googled hardware, managed devices or regions where mainstream stores do not fit. That is not pure anarchy. It is pluralism with cryptographic evidence.

The people and the moment

The public project trail identifies ZapStore's official Nostr profile as npub10r8xl2njyepcw2zwv3a6dyufj4e4ajx86hz6v4ehu4gnpupxxp7stjt2p8, backed by the hex key 78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d. The project's NIP-05 file maps _@zapstore.dev to that key and also maps fran@zapstore.dev to Franzap's key. The official site lists Franzap as founder, And Other Stuff as incubation support, Freedom Tech Co., OpenSats and HRF as donors, Pip on backend, Niel on design, Francis Mars on growth and Elsat on support.

Franzap's public Nostr profile says he is building ZapStore and identifies Buenos Aires. The GitHub release page for ZapStore 1.0.6 shows franzaps as the release author. OpenSats lists ZapStore as a Nostr grant project and says it supports Tor, local-first usage and account-less flows; it also describes recent work around ZapStore 1.0 for Android, a redesigned package manager, custom app-catalog relays, curated app stacks, background update checks, website and indexing improvements, and an iOS client in development. And Other Stuff's own project page places ZapStore among a wider freedom-tech foundry that also includes projects like Shakespeare, Ditto, Divine, White Noise, Flotilla, Cashu, Marmot and ngit.

The timing is important. Nostr Compass reported the 1.0.0 Android release milestone in February 2026 after release candidates, and the project's public site now marks Android App 1.0 and App Stacks as completed while listing web social features, decentralized catalogs, developer analytics, ZapStore Studio and an iOS release as roadmap items. That is a real maturity signal and also a warning not to overstate. The Android app is here. The web app exists and is being expanded. Organization catalogs are advertised. iOS is promised for Q3 2026, not delivered today.

Where to be careful

The first risk is ordinary Android sideloading risk. Installing an APK outside the mainstream store means Android will ask you to allow installs from that source. ZapStore can verify hashes and certificate links against signed release metadata, but it cannot make a bad app good. You still need to inspect the developer, repository, permissions, update history, comments, zaps and social signals. A signed malicious release is still malicious; it is just attributable.

The second risk is key custody. Developers need a Nostr key to publish. If they sign with an nsec in a sloppy CI environment, they can compromise the identity that users trust. ZapStore's own CLI docs call this out and point developers toward NIP-46 bunkers or browser signing. Users also need to understand what signing in means. If ZapStore uses Amber, and Amber is removed, the app signs the user out. That is good behavior, but it also reminds you that the store experience depends on the health of the signer stack around it.

The third risk is catalog politics. ZapStore says anyone can run a catalog relay, but the default catalog still matters because it is where most users will begin. Its allow list, Vertex fallback, blocklist and Terms enforcement are real governance decisions. They are probably necessary for malware defense, but they also create power. The difference from a closed store is that a blocked developer can publish elsewhere and a user can change relays. Whether ordinary users will actually do that is a product question, not a protocol proof.

The fourth risk is freshness. App stores are judged by updates. ZapStore's GitHub app repository was active in May 2026, the webapp repository was active in early June 2026, and the official site is current, but each app listing inside the catalog has its own maintenance reality. A store can verify that a file matches a release event. It cannot guarantee that the upstream project is alive, audited, compatible with your Android version or safe for your threat model. ZapStore gives you better evidence. You still have to read it.

Why this matters for Nostr

ZapStore is one of the clearest examples of "other stuff" in Nostr. It is not a microblogging client, and it is not only a wallet feature. It uses Nostr identity, relays, events, follows, comments, zaps and repository references to coordinate software distribution. That makes the protocol feel less like a social media clone and more like a public message bus for permissionless infrastructure.

If ZapStore succeeds, the effect is not just that Nostr people have another way to install Android apps. The effect is that a release can be discovered through a social graph, verified through signed metadata, paid for through Lightning, discussed in public, mirrored across catalogs and installed without asking one company for shelf space. That model will not replace mainstream stores for everyone. It is rougher, more demanding and easier to misunderstand. But it gives developers and users a pattern that closed stores cannot offer: distribution as a portable public record.

That is why ZapStore belongs in the wallets section as much as the apps section. The product is about software, but its deepest claim is about value and permission. Developers can receive zaps without a platform cut. Communities can curate what they trust. Organizations can host their own catalogs. Users can carry identity, recommendations and payment relationships across the app surface. The store becomes a place where code, reputation and money touch each other directly.

Read ZapStore with both eyes open. It is a promising app store, an active Android client, a developer publishing suite and a live experiment in Nostr-native trust. It is also a system that asks more from users and builders than a centralized store does. That trade is the point. ZapStore is not trying to hide the trust problem behind a logo. It is trying to put enough of the trust evidence in public that people can build their own store-shaped communities around it.

Sources worth opening

The useful trail starts with ZapStore's own docs, then GitHub, Nostr profiles, grant coverage, relay metadata and the NIPs behind the event model.

• ZapStore official site
• ZapStore app listing on ZapStore
• ZapStore apps catalog page
• ZapStore documentation index
• ZapStore FAQ
• ZapStore publishing guide
• ZapStore trust model
• Nostr NIPs searchable kind registry
• ZapStore developers page
• ZapStore for organizations
• ZapStore NIP-05 file
• Nostr.watch lookup for relay.zapstore.dev
• ZapStore Nostr profile
• Franzap Nostr profile
• ZapStore on NostrApps
• ZapStore on OpenSats
• And Other Stuff project page
• Nostr Compass on ZapStore 1.0.0
• Nostr Compass on the NIP-82 software applications draft
• zapstore/zapstore GitHub repository
• ZapStore 1.0.6 release
• ZapStore README
• ZapStore changelog
• ZapStore pubspec.yaml
• ZapStore zapstore.yaml
• ZapStore main.dart
• ZapStore package manager service
• ZapStore Android package manager
• ZapStore catalog fetcher
• ZapStore settings service
• ZapStore background update service
• zapstore/zsp GitHub repository
• zsp on Go Packages
• zsp releases
• zsp README
• zsp go.mod
• zsp Nostr event definitions
• zapstore/relay repository
• zapstore/webapp repository
• zapstore/defender repository
• NIP-34 Git stuff
• NIP-51 lists and release artifact sets
• NIP-46 Nostr remote signing
• NIP-57 Lightning zaps
• NIP-09 event deletion
• Blossom BUD-01 media server spec
• Android PackageInstaller reference
• Android APK signing overview