CraysDamus
Damus is the Nostr client that made the protocol feel native on iPhone: an Apple-platform app with relays, encrypted DMs, zaps, Nostr Wallet Connect, Purple, NostrDB and a public App Store fight over Lightning tips.
The iPhone client that made Nostr visible
Damus matters because it made Nostr feel like a real iPhone app at a moment when the protocol was still strange to most people. The official README calls it a Twitter-like Nostr client for iPhone, iPad and macOS. The official website describes it as a social network the user controls and points visitors toward the Apple app, Purple, Notedeck, Android work, the store and contribution paths.
That Apple-platform focus is the key. A web client can be opened by anyone with a browser, but a native App Store client changes how ordinary users discover a protocol. Damus put Nostr beside the other social apps people already understood, while still keeping the Nostr model of keys, relays, signed events and portable identity. That combination made the app both familiar and politically uncomfortable.
The current store reality is concrete. Apple's lookup API reported Damus version 1.17, released on June 3, 2026, with iOS 16.0 as the minimum operating system, Social Networking as the category and Damus Nostr, Inc as seller. The store listing describes a social network controlled by the user, with no phone number or email required, decentralized relays, encrypted messaging and Lightning tips.
The current public project
The public repository is `damus-io/damus`. GitHub described it on June 11, 2026 as an iOS Nostr client, written mainly in Swift, licensed under GPL-3.0 and organized under the `damus-io` account. The repository was created on April 3, 2022 and remained active in June 2026. Its topics include Bitcoin, freedom, Lightning Network and Nostr, which says a lot about the project's self-image.
The codebase is not a thin wrapper around a website. It contains SwiftUI application code, Apple entitlements, notification handling, relay models, Nostr event types, encrypted messaging code, wallet and zap features, Purple subscription code, storage statistics, Keychain storage, NostrDB bindings, tests and UI tests. The app is a native Apple client that has absorbed several years of Nostr product work.
Damus is also part of William Casarin's wider Nostr work. OpenSats lists Damus as a funded project and notes support for work across Damus, Notedeck, NostrDB and Notecrumbs. A separate OpenSats long-term support announcement for William Casarin highlights Damus, NostrDB, Notedeck and Notecrumbs together. That is the right frame: Damus is the iOS product surface of a broader Nostr engineering stack.
What the app does for a normal user
A Damus user reads and posts notes, follows people, edits a profile, replies, reposts, reacts, receives notifications, opens global or personal feeds, sends DMs, manages relays and interacts with Lightning features. The README's getting-started material explains pubkeys, secret keys, personal feed, global feed, notes, encrypted DMs, notifications, profile editing and requesting sats. It is practical onboarding, not only developer documentation.
The App Store description says users can begin without a phone number, email or name. That is central to the Nostr experience. Damus creates or imports key-based identity rather than asking a central company to issue an account. The private key becomes the sensitive object. The public key becomes the address other people can find, tag and follow across clients.
The familiar timeline hides a different trust model. A post is a signed Nostr event sent to relays, not a row in one company's database. A follow is part of the user's portable social graph. A DM is encrypted content with visible metadata limits. A zap is Lightning money tied to a social interaction. Damus gives those ideas a native iOS interface.
Keys and Keychain storage
Damus is built around key ownership. The README repeatedly warns users not to share the secret key and to save keys somewhere safe. The Swift app code loads a saved keypair at launch, clears it on logout and disconnects relays after logout so old authenticated relay connections do not remain attached to the wrong user. That is a small code detail with real security meaning.
The codebase includes `KeychainStorage.swift` and keychain access group entitlements. On Apple platforms, Keychain storage is the expected place for sensitive app secrets, but it does not remove the need for user discipline. An iPhone backup, device compromise, screenshot, clipboard leak or accidental nsec paste can still defeat the best app-level intentions.
For a reader, the key lesson is simple: Damus can make Nostr identity feel easy, but it cannot make the private key disposable. A Damus account is not reset by calling platform support. If the key is lost, the identity is lost. If the key is copied by someone else, the identity is shared with them. The App Store polish should not make the key feel like a password.
Relays are visible enough to matter
The README tells users that relays can be added in settings and that the global feed is drawn from the relays the user has added. The codebase has a dedicated relays feature area with user relay views, relay configuration, relay detail pages, relay status, relay toggles, relay filters and signal views. Damus is not pretending that relay choice is a developer-only subject.
Damus also documents ephemeral relays. The `docs/ephemeral-relays.txt` file explains that ephemeral relays exist in the relay pool but not in the published relay set on a user's profile, and that they can be used for NWC relay communication and note relay hints. This is one of those Nostr details a normal user may never name, yet it affects whether the app can find notes or talk to wallet services.
The app's relay model matters because iOS users often expect an app to simply work. In Nostr, missing data can mean the wrong relay, an offline relay, a relay policy issue, a hint problem or a contact relay mismatch. Damus tries to make relay management available without turning every feed load into a manual server exercise.
The protocol surface is larger than the README list
The README lists support for NIP-01 basic protocol flow, NIP-04 encrypted direct messages, NIP-08 mentions, NIP-10 reply conventions, NIP-12 generic tag queries, NIP-19 bech32 entities, NIP-21 Nostr URIs, NIP-25 reactions, NIP-42 relay authentication and NIP-56 reporting. That list is useful, but it is not the whole current code picture.
The repository also contains explicit code for NIP-44 versioned encryption, NIP-65 relay lists and NIP-98 HTTP auth, along with tests for NIP-44 encryption, wallet connections, relay hints, relay pools, zaps, NostrDB compaction and keychain storage. The App Store release notes for version 1.17 mention client tags, storage compaction, NostrDB storage statistics and fixes around using another NWC wallet in parallel.
This is a common pattern in active Nostr clients. The documentation states a stable public baseline, while code and release notes move ahead with newer pieces. Readers should therefore treat Damus as a living client rather than a frozen NIP checklist. If a feature matters for serious use, check the current release notes and the exact app version.
Direct messages are useful but not invisible
Damus supports encrypted direct messages and has dedicated DM models and views. The README says users can begin a DM from a profile and warns that it is public information which profiles are exchanging DMs, even though the content is encrypted. That warning is important because users often confuse encrypted content with private social metadata.
The older NIP-04 DM model is listed in the README, and the codebase also includes NIP-44 versioned encryption work. NIP-44 improves the encryption scheme, but it does not make relay-level delivery metadata disappear. Relays can still observe timing, authorship patterns and the fact that certain events are being requested or delivered, depending on the flow.
For a sensitive conversation, a Damus user should assume message text and message metadata are different risks. The text can be encrypted. The relationship between accounts can still be visible. Device notifications can expose context. Media previews can leak network information. Damus is a social client with DMs, not a dedicated anonymity system.
Zaps made Damus culturally important
Damus became culturally important because it helped make zaps feel native on mobile. A zap is a Lightning payment attached to a Nostr social action, and Damus put that idea inside an iPhone interface. The README says users can send or receive zaps without asking permission, and the codebase has dedicated zap models, views, request creation, notification handling and tests.
The technical side is visible in files such as `MakeZapRequest.swift`, zap views, zap models and wallet settings. The social side is bigger: a like costs nothing, a repost costs reputation and a zap costs money. Damus arrived at a moment when Nostr users were experimenting with value-for-value social signals, and the app made that experiment feel like a real mobile product.
That does not mean every zap flow is safe or simple. A zap touches a wallet, a Lightning invoice, a Nostr event, relays and sometimes a client-specific UI rule. A user should know whether the zap is public, private, profile-level, note-level, wallet-connected or merely represented by a receipt. Damus helped popularize the pattern, but the wallet boundary still deserves care.
Nostr Wallet Connect changed the money path
Damus has wallet features and Nostr Wallet Connect code. The source includes wallet views, NWC settings, wallet scanner views, wallet models, wallet connect request and response models, and tests for wallet connections. The App Store 1.17 release notes specifically mention a fix where the app could show an error when another NWC wallet was used in parallel.
NWC matters because Damus does not need to be the wallet. A user can connect a wallet and let Damus request wallet actions for zaps or payment flows. This is safer than putting money logic directly into every social client, but it is only safer when the wallet connection is permissioned and scoped. The social app should not silently inherit broad spending authority.
The right user habit is to treat wallet setup as a security decision. Connect a small wallet first. Check permissions. Understand relay choice. Test one zap. Confirm whether the wallet shows budget, expiry and transaction history. Damus can make the zap button feel effortless, but the authority comes from the wallet connection.
The App Store zaps dispute
Damus is also a public case study in the collision between open payments and App Store rules. In June 2023, Apple threatened to remove Damus over Bitcoin Lightning zaps on posts, arguing that the feature implicated in-app purchase rules when tied to content. Damus, Bitcoin users and outside observers argued that tips did not unlock content and were peer-to-peer payments.
The standoff ended with a compromise. Reporting from CoinDesk and Decrypt described Damus staying in the App Store after removing post-level zaps, while profile-level zaps could remain. CoinDesk later covered Zapple Pay as a third-party workaround that used emoji reactions to trigger zaps outside the app's direct post-zap button.
For readers, the lesson is not only historical drama. It shows why routing matters. A Nostr app can be open-source and relay-based, while still depending on Apple's distribution rules if it wants mainstream iPhone reach. A zap can be a peer-to-peer Lightning payment, while still being treated by a platform gatekeeper as monetization tied to digital content. Damus sits exactly at that fault line.
Purple is funding and product strategy
Damus is free and open source, but it also has Damus Purple. The README describes Purple as a paid subscription with early benefits such as a subscriber number, subscriber badge and auto-translate powered by DeepL. The repository includes `Purple.storekit`, Purple views, StoreKit manager code, Purple account views, translation setup and subscription state handling.
The StoreKit file shows monthly and yearly Purple subscriptions configured in Apple's subscription system. That is a different monetization path from zaps. Zaps are peer-to-peer social money. Purple is an app subscription that supports development and gives account-level benefits through the Apple ecosystem. Both can coexist, but they are not the same thing.
Purple also illustrates the compromise every serious open-source app faces. Users want software without ads, tracking and centralized control. Developers still need funding. Damus uses grants, donations, zaps and Purple rather than a normal ad business. A reader deciding whether to subscribe should treat Purple as support for ongoing work plus specific product benefits, not as a requirement for having a Nostr identity.
NostrDB is the performance story
NostrDB has become central to Damus's technical direction. OpenSats describes NostrDB as an LMDB-backed database with zero-copy access to note fields for embeddable Nostr query support. The Damus repository includes a `nostrdb` directory with C source, Swift bindings, tests and compaction code. Damus 1.17 release notes emphasize storage optimization, compaction, storage statistics and database leak fixes.
This matters because a Nostr client is not only a network client. It is also a local event database. A busy account may collect profiles, notes, replies, zaps, relay metadata, media references and notifications. If the local store grows without control, the app becomes slow or wasteful. If storage is too thin, offline context and performance suffer.
Damus's recent storage work tells users what kind of app it is becoming: not just a pretty feed, but a client trying to keep a serious Nostr event archive usable on a phone. The storage settings and compact database work are not glamorous, but they are the plumbing that makes an active social client sustainable.
Media, GIFs and diagnostics
Damus handles media as part of the timeline experience. The App Store release notes for version 1.17 mention a redesigned media blur overlay, GIF keyboard support for Purple users, detailed diagnostics for GIF keyboard errors and changes to cache clearing. The codebase includes shared media areas for GIF and video handling and Kingfisher cache configuration in the app startup path.
Media features are easy to underestimate. A Nostr app may be text-first at the protocol level, but users expect images, videos, GIFs, profile pictures, link cards and blurred sensitive content. Every media load involves storage, network requests, caching, privacy and performance. A broken image can feel like a broken app even if the underlying relay event loaded correctly.
The addition of Sentry error and diagnostics reporting in version 1.17 also shows a product maturity tradeoff. Diagnostics can improve quality, but they introduce privacy questions. Users who want the strictest privacy should inspect settings and release notes. Users who want reliability should understand that crash and diagnostic tooling is often how complex mobile apps get better.
Notifications and communication entitlements
Damus includes notification handling at the native app level. The entitlements include communication notifications, push notification environment, associated domains, app sandboxing, application groups, camera, microphone, network client access, photo library access and keychain access groups. The app delegate registers notification categories and handles foreground and received notifications.
Those permissions tell a lot about the product. Damus is not only reading relays while open. It wants to behave like a real iOS social app with notifications, media capture, photo library access, shared caches, associated web links and secure storage. That makes the experience more natural, but it also means users should inspect permissions the same way they would for any social app.
The Nostr model reduces some central-platform risks, but it does not eliminate device-level privacy choices. An iPhone app can still request media access, use push notifications, cache images, open links and receive diagnostic events. Damus's native integration is one of its strengths, and it is also why the app deserves normal mobile-permission scrutiny.
Funding and public support
Damus has received public support from both users and grant organizations. The README mentions donations or grants from Damus users, OpenSats and the Human Rights Foundation. OpenSats lists Damus as a funded project, with first funding through the Nostr Fund in July 2023, renewals later, and related support for Notedeck and William Casarin's broader work.
The Human Rights Foundation's Bitcoin Development Fund announced support for William Casarin's Nostr work, including the popular Damus iPhone client. A later HRF grant page also described Damus Android as a communications application using Nostr, intended to help people in difficult political environments communicate and receive Bitcoin through zapping.
This public funding context matters because Damus is not only a product-market story. It is part of freedom-tech infrastructure: open-source clients, relay-based speech, Lightning-native payments and mobile distribution. Grants do not make the app perfect, but they explain why people outside ordinary consumer app markets care about its survival.
What to test before relying on Damus
A careful Damus test starts with identity. Create a small test account or import a low-risk key. Save the key properly. Log out and back in. Confirm whether the app restores the right profile and disconnects relays on logout. Then add a few relays, publish a note, reply from another client and check whether the event is visible where expected.
The second test should cover DMs and media. Send an encrypted message to a trusted account, verify whether the other client can read it, and remember that metadata can remain visible. Try loading media in personal and global feeds, inspect cache and storage behavior, and look at the storage settings after the app has been used for a while.
Money should be tested last. Connect a wallet with a tiny NWC budget, send a small zap if the current app flow permits it, verify wallet-side history and understand whether the zap is profile-level, note-level, public or private. Purple should be evaluated separately as an App Store subscription. A zap moves sats. Purple supports the app. They are different decisions.
Who Damus fits best
Damus fits iPhone and iPad users who want a native Nostr client with App Store distribution, familiar mobile navigation, key-based identity, relays, profile editing, DMs, notifications, zaps and wallet connection paths. It is especially important for users who want to introduce Nostr to people who will not install a developer build or live inside a web client.
It is less suited to someone who wants full independence from platform gatekeepers. Damus is open-source and Nostr-based, but App Store distribution still matters for the official iOS path. The 2023 zaps dispute proved that a decentralized protocol can still meet centralized app-review power at the point of distribution. Users who need maximum independence should also learn web, TestFlight, source-build or alternative client options.
For builders, Damus remains worth studying because it is a native client that has wrestled with the hard parts: relay management, storage, zaps, NWC, encryption, notifications, subscriptions and App Store policy. It is not merely a symbol. It is a large Swift codebase that shows what happens when Nostr is forced into a polished mobile product.
The reader takeaway
Damus is one of Nostr's defining apps because it brought the protocol into a native iPhone experience and then exposed the boundary between open social payments and closed platform distribution. That story is not separate from the product. It is part of why Damus matters: the app lives where Nostr meets ordinary users, wallet integrations, App Store policy and mobile expectations.
The current version should be judged by concrete surfaces: App Store version 1.17, Swift and GPL-3.0 source, relay settings, encrypted messaging, NWC wallet code, zap models, Purple subscription infrastructure, NostrDB storage work and public funding support. Those details make Damus more than an early Nostr mascot.
Used carefully, Damus gives Apple users a serious Nostr entry point. The key must be protected, relays must be understood, DMs should not be mistaken for anonymity, wallet connections should stay limited and App Store constraints should be remembered. With that mental model, Damus is still one of the most important ways to experience Nostr on iOS.
Sources worth opening
Useful primary sources are the official site, Apple App Store data, public repository, README, App Store release notes, Swift source files, NostrDB code, Purple StoreKit configuration, OpenSats and HRF funding notes, and reporting on the 2023 Apple zaps dispute.
- Damus official website
- Damus on the Apple App Store
- Apple Lookup data for Damus
- Damus Purple page
- Damus GitHub repository
- Damus README
- Damus GPL-3.0 license
- Damus security policy
- Damus ephemeral relay notes
- Damus app entry point
- Damus entitlements
- Damus AppIcon asset catalog
- Damus Purple StoreKit configuration
- Damus Purple StoreKit manager
- Damus Purple account view
- Damus MakeZapRequest source
- Damus zaps model
- Damus note zap button
- Damus wallet view
- Damus NWC settings
- Damus WalletConnect model
- Damus WalletConnect tests
- Damus NIP-44 implementation
- Damus NIP-65 implementation
- Damus NIP-98 auth implementation
- Damus RelayPool source
- Damus relay config view
- Damus direct messages model
- Damus DM chat view
- Damus Keychain storage
- Damus storage stats manager
- Damus NostrDB source directory
- Damus Ndb compaction source
- Damus Ndb compaction tests
- OpenSats Damus project page
- OpenSats long-term support for William Casarin
- Human Rights Foundation Bitcoin Development Fund grant including Damus
- Human Rights Foundation Damus Android grant
- CoinDesk on Damus staying in the App Store after zaps dispute
- CoinDesk on expected Damus App Store deplatforming
- CoinDesk on Zapple Pay workaround
- Decrypt on Damus remaining in the App Store with zaps removed
- Decrypt on Damus App Store removal threat
- Nostr NIP-01 basic protocol flow
- Nostr NIP-04 encrypted direct messages
- Nostr NIP-10 reply conventions
- Nostr NIP-19 bech32 entities
- Nostr NIP-21 URI scheme
- Nostr NIP-25 reactions
- Nostr NIP-42 relay authentication
- Nostr NIP-44 versioned encryption
- Nostr NIP-47 Nostr Wallet Connect
- Nostr NIP-56 reporting
- Nostr NIP-57 Lightning zaps
- Nostr NIP-65 relay list metadata
- Nostr NIP-98 HTTP auth
