CraysZapddit
Zapddit is useful when you want Nostr to feel less like a follower graph and more like a place where topics, communities and paid signals shape what rises to the surface.
A Nostr client built around topics first
Zapddit is one of the clearest attempts to make Nostr feel like a topic board rather than another short-post timeline. The README describes it as a Reddit-style client, and the comparison is not just decorative. In Reddit, readers search for subreddits and build a home feed around those spaces. In Zapddit, readers search for hashtags such as coffeechain, foodstr, asknostr or bitcoin, follow them, and receive recent notes that mention those tags. The result is a Nostr feed that begins with subjects rather than a list of personalities.
That difference changes the first question a reader asks. A normal Nostr social client usually starts with who to follow. Zapddit asks what you want to read. The onboarding wizard makes that explicit. It suggests topics for daily Nostr reading, memes, news, questions, Bitcoin, food, welcoming new users and client talk, and it can also seed a mute list for topics the reader would rather avoid. The product has a point of view: public Nostr can be navigated by tags and rooms, not only by social proximity.
This makes Zapddit especially interesting for readers who arrive from forums, subreddits, message boards or topical communities. It does not remove the Nostr identity model. You still have an npub, signatures, relays, replies, follows and zaps. But the reading surface is less dependent on already knowing the right people. You can begin with a subject, watch the stream of public notes around it, follow or mute the topic, and only later decide which authors belong in your personal contact graph.
The Reddit comparison is literal in the product
The README's table is unusually useful because it names the translation layer directly. Subreddits become hashtags. A subscribed subreddit feed becomes a reverse-chronological stream of notes mentioning followed hashtags. Upvotes become upzaps. Downvotes become downzaps. A vote tally becomes a tally of sats attached to upzaps and downzaps. That gives the product a sharper identity than a generic microblogging client with a search box.
Zapddit does not simply copy Reddit into Nostr. Reddit's ranking and moderation depend on a platform database, centralized accounts and subreddit governance. Zapddit has to work with signed events scattered across relays. That means it cannot assume one canonical source of truth for every topic, every vote or every community. Its feed is a view assembled by a client, over relays, from event kinds and tags. The result is more open, but also less tidy than the platform model people know from Reddit.
The most important practical consequence is that a Zapddit topic is only as good as the notes your relays return. If a hashtag is popular but your relay set is thin, the feed can look quiet. If a topic is noisy, the mute list becomes important. If a community uses moderation approvals, the client has to decide whether to show all unapproved posts or only moderator-approved posts. Zapddit gives the reader tools for these situations, but the network remains visible underneath.
Upzaps and downzaps make voting economic
Zapddit's most distinctive social primitive is the pair of upzaps and downzaps. A normal upvote is an attention signal. A Nostr reaction can be the same thing: a kind 7 event with a plus or minus sign. Zapddit supports those non-zap reactions, but the README and UI give stronger emphasis to paid reactions. An upzap sends sats to the author of the note. A downzap sends sats to a downzap recipient chosen by the reader in preferences.
That second half is the unusual part. Downzaps are not framed as a punishment payment to the author. In the code, the reader sets a downzap recipient npub, and the downzap flow builds a zap request to that recipient while still attaching the zapped event reference. The event card then separates zap receipts by inspecting the zap description and counting requests with a minus comment as downzap totals. It is a rough but concrete experiment in disagreeing with a post while sending money somewhere else.
The design has consequences a reader should think through. An upzap rewards the author of the note. A downzap rewards the recipient the reader configured. If that recipient is a charity, a developer, a moderator, a friend or the reader's own alternate account, the social meaning changes. Zapddit exposes this choice through preferences instead of pretending a downvote is neutral. It turns voting into a money path, which is powerful, funny and risky in equal measure.
Bitcoin Connect turns zaps into a web-wallet flow
Zapddit originally listed Lightning wallet connect as an unchecked item in the README, but the current code has moved farther than that old checklist. The package uses Alby's Bitcoin Connect library, and the preferences page embeds a Bitcoin Connect button with the app name set to Zapddit. The label is plain: connect to upzap and downzap with minimal effort. That places Zapddit in the group of Nostr web apps trying to make Lightning payments feel native inside a browser or PWA.
The zap dialog supports several paths. If WebLN is already connected, it can request an invoice and ask the wallet to send payment. If not, it can generate a QR code for a Lightning wallet. Upzaps call the normal event zap flow. Downzaps use a custom path copied from NDK behavior so the payment can go to a non-author recipient. The code reads a Lightning address or LNURL, builds a NIP-57 zap request, signs it, sends it to the LNURL callback and receives a BOLT11 invoice.
There is also a creator-support layer. Zapddit has a zap split configuration with a default developer entry and translator entries based on the current language. When WebLN is available, the zap dialog can split a small percentage of a zap toward developers or translators. That is not a standard social-client feature. It shows how Zapddit mixes three ideas that usually live apart: public discussion, voting signals and recurring support for the people who build or translate the tool.
Login modes change the risk profile
The login page recommends a NIP-07 browser extension for secure login. That is the safest default for a web Nostr client because the app can request signatures without directly holding the user's secret key. Zapddit waits for window.nostr, uses NDK's NIP-07 signer and then initializes the client with the public key returned by the signer. For a reader using Alby, nos2x, Flamingo, Amber's web bridge or another compatible signer, this is the mode to test first.
Zapddit also supports alternate login with an nsec or npub. An npub is read-only. It lets the reader browse as a public identity, but not write notes, publish settings, zap or follow from that key. An nsec gives read and write capability. The code stores the private key as a hex value in localStorage after validation. The LoginUtil file refuses private-key login when the browser lacks secure crypto support, and its own error message tells the reader to use a Nostr key manager extension on insecure connections.
The app also supports a no-account browsing mode. In that path, Zapddit uses a local lurker session, keeps followed topics and muted topics in browser storage, and clears those settings on logout. This is good for evaluation because a reader can explore topic feeds without committing an identity. It is not a substitute for understanding key custody. If you use Zapddit with a valuable Nostr identity, extension signing is the calmer path. If you paste an nsec, you are trusting the web app and the local browser environment with that account.
Your preferences become Nostr data
Zapddit has two preference layers. One is browser-local state: localStorage keys such as followedTopics, mutedTopics, followedCommunities, downzapRecipients, defaultSatsForZaps, subscribedRelays and media settings. The other is Nostr-published state. The app writes its own application-specific data event as kind 30078 with a d tag of zapddit.com, and it also reads the older zappedit.com tag for continuity with the project's earlier name.
The newer interoperable path is kind 30001 lists. The topic service publishes followed hashtags as t tags under d equals hashtags, muted hashtags under d equals mutehashtags, joined communities as a tags under d equals communities and downzap recipients as p tags under d equals downzaprecipients. When Zapddit refreshes app data, it merges the app-specific kind 30078 state with the more interoperable 30001 list state. That is important because a reader's topic and community choices are not only private UI state; some of them can become signed public Nostr events.
This is useful and worth respecting. A signed topic list can survive a browser reset and can be understood by other clients that support the same list pattern. It can also disclose what you follow, mute or use as a downzap recipient. Zapddit does not hide that it is a Nostr app; it publishes settings through Nostr when the reader can write. If you care about privacy, test with a smaller account first and inspect the events before treating any preference as invisible.
Communities are more than hashtags
Zapddit began with hashtags, but the current app has a serious community layer. The routing file exposes community discovery, joined communities, communities created by the user, communities moderated by the user, recently active communities and individual n/community-name routes. A reader can create or edit a community with a display name, slug, image, description, rules and moderator npubs. Community cards show creator identity, follower counts, descriptions and join or leave actions.
Under the hood this follows the NIP-72-style model. Community definitions are replaceable kind 34550 events. A community can have a d tag for its identifier, a name, description, image, rules and p tags for moderators. Posts can be shown from approval events of kind 4550, where moderators approve a post for a community. Zapddit also queries unmoderated community posts of kinds 1, 4549 and 1111 when the reader chooses to see all posts. The latest commit title mentions new kind 1111 support, and the send-note code switches to kind 1111 when posting into a community.
This makes Zapddit a useful window into one of Nostr's hardest product questions: how do public groups work without one platform owning the database? Moderation is not a hidden admin panel. It is a set of signed events. A moderator approves a post by publishing an approval event. A client decides which approvals count. A reader can choose whether to show unmoderated posts. That is less comfortable than Reddit, but it is also more transparent about where authority lives.
The feed is simple on purpose
Zapddit does not try to be an algorithmic ranking engine. The topic feed fetches kind 1 notes by hashtag and shows them in reverse chronological order. The home feed fetches notes for all followed topics. The community feed fetches approval events or unmoderated community posts depending on settings. Results go through a local event buffer, are sorted by created_at and are filtered against the reader's muted topics before display.
That is not the same as Reddit hot ranking. Zapddit does show upzap, downzap, upvote and downvote counts, but the primary feed behavior remains chronological. This has a benefit: the reader can understand why something is appearing. It also has a cost: busy tags can become noisy, quiet tags can feel empty, and there is no central score to rescue an old but useful post. The product trades platform ranking for client-side legibility.
A reader who wants Reddit's front-page gravity may find this too raw. A reader who wants a browsable Nostr topic reader may appreciate the restraint. Zapddit is closer to a topical browser with social and payment actions than a full reputation engine. Its strongest use is not finding the most viral post in all of Nostr. Its strongest use is following a subject across relays and then deciding which people, communities or tags deserve more attention.
Media and moderation stay close to the reader
Zapddit includes image display, video display, note mentions, replies, quoted notes and linkified hashtags. The event card extracts image URLs, video URLs and YouTube, Vimeo or Dailymotion links from note content. It also renders mentions and note references into client components. The UI offers share links, Snort profile and event links, copying note IDs and copying event JSON for readers who want to inspect the raw Nostr object.
The media setting is particularly practical. Zapddit can blur media from people the reader does not follow, or blur all media in unauthenticated mode. The event card checks whether the author is in the local peopleIFollow Dexie table and hides media until the reader clicks to reveal it. That small design choice matters in open public feeds, where a topic tag can include media from strangers and not every relay has the same moderation norms.
Moderation is similarly visible. A community post can appear as unapproved when the community mode requires moderator approvals. Moderators can approve a note from the card. Readers can choose an unmoderated feed. The app can show approvers and uses the community's moderator list to decide whose approvals to honor. Zapddit therefore treats moderation as something the client can display and act on, not as a remote platform rule that simply appears as a finished outcome.
The stack is a web app, not a native client
Zapddit is built as an Angular application with TypeScript, HTML and SCSS. The package file shows Angular 16, Angular service worker support, Clarity UI components, NDK, NDK Dexie caching, nostr-tools, bech32 utilities, noble cryptography packages, linkify hashtag handling, QR code rendering, ngx-translate and Bitcoin Connect. It is a real browser app with a PWA shape rather than a native iOS or Android application.
The data layer reflects that choice. Dexie backs the local IndexedDB store for people the reader follows, muted people and subscribed relays. NDK cache Dexie supports event caching. localStorage holds a large amount of user state. The app routes to feeds, login, profile, preferences, people followed, single posts and community pages. A service worker configuration and web manifest give it the installable web-app direction.
This is good news for openness and fast iteration, but it changes the trust model. A native app update and a web app update do not feel the same when private-key login is available. The running JavaScript matters. The domain matters. The browser profile matters. That is another reason the NIP-07 recommendation should be taken seriously. Zapddit is strongest when the web app can ask a signer to act, rather than becoming the permanent home of the user's secret.
Ampyard's product page explains the project history
Zapddit is not an anonymous weekend toy, even though it started with that energy. Ampyard's product page lists Zapddit as an active open-source Nostr social-media product and says it began as a casual personal weekend project by one of the company's founders before becoming the first Ampyard product with wide adoption. It also says Zapddit won the Empowering Communities category at Nostrasia 2023.
That background fits what the code shows. The repo was created in May 2023, carries an MIT license and has hundreds of commits. GitHub metadata shows a modest but real open-source footprint, with contributors beyond the original maintainer and a public issue tracker. The Hacker News launch on June 14, 2023 introduced it as a Reddit-style open-source client for Nostr where one follows topics instead of people. The earliest pitch and the current code still line up.
The product also evolved from a simpler hashtag reader into a broader community client. The code contains compatibility with zappedit.com, which points to its earlier naming history. It now includes Crowdin translation setup, community creation, moderator approval, Bitcoin Connect, zap splits and newer community post kinds. The thing to appreciate is not only that Zapddit exists, but that it has kept one coherent question alive: what happens when public topic discussion is rebuilt on portable Nostr identity?
What to test before depending on Zapddit
Start by testing without an account. Follow a few topics, mute a few others, browse the feed and search communities. Check whether your relays return enough notes for the subjects you care about. Then try NIP-07 login with a low-risk account and confirm that publishing notes, replies, follows and topic lists behaves as expected. Only after that should you consider private-key login, and even then it is better to understand exactly what the browser stores.
Next, test the money paths with tiny amounts. Set a downzap recipient deliberately. Connect Bitcoin Connect or WebLN, make an upzap, make a downzap and inspect who receives the invoice. Check whether zap split settings are enabled and whether you want them enabled. If you use Zapddit as a serious discussion client, remember that zaps are public payment signals unless the underlying zap flow and wallet path give you the privacy properties you expect.
Finally, test communities as communities, not just as tags. Create or join a small one, inspect the kind 34550 definition, add a moderator, post into it, approve a note and compare the moderated and unmoderated feed settings. That exercise teaches more about Zapddit than a quick scroll through the home feed. The app is most valuable when you use the parts that make it different: topics, communities, visible moderation and zap-based voting.
Sources worth opening
Open the README first, then compare it with the live login surface, Ampyard's product page, the NDK provider, topic service, community service, event card, zap dialog and the relevant NIPs.
- Zapddit live app
- Zapddit login page
- Zapddit GitHub repository
- Zapddit README
- Zapddit package.json
- Zapddit web manifest
- Zapddit NIP-05 nostr.json
- Zapddit app routes
- Zapddit NDK provider service
- Zapddit topic service
- Zapddit community service
- Zapddit event feed component
- Zapddit event card component
- Zapddit event card template
- Zapddit zap dialog
- Zapddit preferences template
- Zapddit preferences component
- Zapddit login page template
- Zapddit onboarding wizard
- Zapddit relay service
- Zapddit Dexie database service
- Zapddit login utility
- Zapddit constants
- Zapddit zap split utility
- Zapddit English interface strings
- Zapddit Crowdin config
- Zapddit Crowdin project
- Ampyard products page for Zapddit
- Show HN launch for Zapddit
- Zapddit latest community-kind commit
- Zapddit issues
- NIP-07 browser extension signing
- NIP-57 Lightning zaps
- NIP-51 lists
- NIP-65 relay list metadata
- NIP-72 moderated communities
- NIP-22 comments and kind 1111 context
- NDK repository
- NDK package
- Bitcoin Connect repository
- Alby Bitcoin Connect announcement
- Dexie documentation
- Angular service worker overview
- Clarity design system
- nostr-tools repository
