CraysYana
Yana is the kind of Nostr client to open when you want a mobile app that treats relays, keys, wallet connections and distribution channels as first-class parts of the experience.
A mobile client with its nerves showing
Yana is a Nostr client for readers who do not want the relay layer, signer layer and wallet layer hidden behind a single social feed. The README calls it Yet Another Nostr Application, but the project is less casual than that name sounds. It is a Flutter application with Android, iOS, web, desktop and packaging traces in the repository, built around the practical problems that make Nostr hard on phones: relay discovery, feed responsiveness, key custody, background notifications, media loading and zaps.
The motivation in the project README is unusually direct. Yana exists because the maintainer saw mobile clients that were not responsive enough on older phones, not open enough to a broad FOSS contributor base or not really multi-platform. That gives the app a different personality from clients that compete mainly on visual polish. Yana is trying to be a working bench for daily Nostr use, not a locked showroom.
That working-bench feeling is visible in the code and release history. The app has a normal social layer, but it also has settings for relay behavior, NIP-51 lists, wallet connection permissions, notifications, direct-message sessions, media uploads and account switching. Readers who prefer a completely simplified onboarding may find it busy. Readers who want to understand why their feed loads from certain relays, why a zap failed or why an external signer matters will find more of the machinery within reach.
What Yana actually lets you do
At the social level, Yana handles the basic verbs a Nostr client has to get right. It has a home feed, global feed, notifications, profiles, follow and unfollow flows, replies, mentions, reactions, reposts, thread views, image and URL previews, bookmarks, pinned posts, muted lists and event deletion. The README lists these features beside the NIPs they depend on, including NIP-01 for basic events, NIP-02 for follows, NIP-10 for replies, NIP-18 for reposts, NIP-19 for bech32 identifiers and NIP-25 for reactions.
The app also goes beyond a plain note reader. It exposes relay pages through NIP-11 information, supports NIP-05 addresses, shows badges through NIP-58, supports polls through the older NIP-69 style used by the project, works with NIP-65 relay metadata and stores user lists such as mutes, blocked relays and search relays through NIP-51. The search screen looks for notes, reposts, long-form events, file headers, polls, metadata and community definitions, using search relays when the user has configured them.
Yana should therefore be understood as a general social client with a strong power-user streak. You can open it to read and reply, but the more interesting use case is tuning the network around your account. It gives you places to inspect relays, choose read and write lists, manage mutes and blocks, connect a wallet, check zaps and move between accounts. That makes it useful for people who want a mobile client that teaches Nostr by exposing the system instead of pretending the system is one server.
Installation is deliberately outside the usual stores
The installation story is part of Yana's identity. The README tells readers not to expect the project to be constrained to Apple Store or Google Store distribution. It recommends Zapstore for Android, Obtainium with the GitHub repository, or direct downloads from GitHub releases. For iOS, the release notes and README point to sideloading an IPA with Sideloadly rather than a normal App Store path.
That choice fits Nostr culture, but it raises the bar for the reader. Yana is not a tap-once consumer install in the usual mobile-store sense. The release notes repeatedly tell Android users to verify the certificate SHA256 of the APK and compare it with the SHA256 published on the Yana Nostr profile. That is not decorative text. If you install a Nostr client outside a platform store, the signature check is part of the safety model.
The repository contains two Zapstore manifests. The main manifest identifies `yana.nostr` as Yana, summarizes it as a Nostr client focused on performance on slower devices and modular features, and publishes Android architecture-specific APKs. The wallet manifest identifies `yana.nostr.wallet` as Yana Wallet and describes it as a Nostr Connect Wallet interface. Those two manifests explain why readers may see Yana both as a social app and as a wallet-adjacent app in ecosystem maps.
Keys can be local, external or browser-signed
Yana supports several signing paths, and the differences matter. On Android, it can use Amber as an external signer. In the login screen, if Amber is installed, Yana asks Amber for the public key and requests permission for NIP-04 decryption. In the startup path, an account marked as an external signer is loaded through an Amber event signer. This means an Android reader can avoid putting an nsec directly inside Yana for normal signing.
Yana also supports local key storage. The settings provider stores a map of account keys, private/public flags and external-signer flags in Flutter secure storage, using encrypted shared preferences on Android and keychain options on iOS. The login screen can accept a private key, public key, nsec, npub or hex key, and it can generate a new private key. If no key exists and the build is not wallet-only, the app creates a fresh private key on startup so a new reader can enter the app.
On web, Yana can use a browser extension through a NIP-07 style signer. The implementation asks the extension for a public key and signs Schnorr event ids through JavaScript. The same file leaves encryption and decryption methods unimplemented, which is important for expectations: browser signing can be useful for note signing, but direct-message or encryption behavior depends on the available signer path and platform support. A cautious reader should treat key mode as a product choice, not a hidden technical footnote.
The gossip model is one of Yana's defining ideas
Yana ships a dedicated GOSSIP document, and that is one of the best pages to read before judging the app. The document explains the inbox/outbox model in plain terms: read posts from the relays where followed people write, and broadcast replies, likes and reposts toward the relays where involved people read. That idea is important because a Nostr client that only connects to a fixed global relay set can miss posts or make replies invisible to the people who should see them.
In the app code, Yana loads the user's relay list, creates separate inbox and outbox relay sets, then can calculate a feed relay set from the outbox relays of followed contacts. It uses NIP-65 relay metadata when available and falls back to contact-list information when needed. The app also lets the user tune the minimal number of relays per contact. A lower value can reduce data usage; a higher value can increase resilience against a relay that is slow, down or selective.
This is where Yana feels more technical than many clients. A reader may see relay counts, relay connectivity and feed relays as extra clutter until a missing-post problem appears. Then the design starts to make sense. Yana is trying to make the social feed less dependent on a small relay bundle by calculating where your contacts actually publish and by keeping the user's own read and write relays visible enough to manage.
Relay management is not hidden behind defaults
Yana's relay provider can add, remove and update NIP-65 relay markers, reconnect relays, calculate feed relay sets and fetch public relay lists from nostr.watch APIs. Relay screens show connectivity and relay information, and profile statistics can open relay lists for a user. The app recognizes `nrelay` identifiers and can route them to relay information screens. This gives the reader more than a simple text box of websocket URLs.
The app also uses NIP-51 lists in a practical way. During relay initialization, Yana fetches the user's mute list, blocked-relay list and search-relay list. Muted pubkeys, muted hashtags and muted words are then applied by a filter provider; blocked relays become part of the relay state; search relays can be connected with a special search source. Search defaults include relays such as `relay.nostr.band`, `relay.noswhere.com` and `search.nos.today` when the user has not configured a list.
The benefit is control. The cost is responsibility. If a reader blocks relays aggressively, chooses poor search relays or leaves the gossip model badly tuned, Yana can feel worse than simpler clients. If the relay settings are treated as part of the account, Yana becomes a useful diagnostic tool: it helps you see whether the problem is the app, your relay set, a contact's outbox, a blocked relay or a search relay that cannot answer the query you sent.
Wallet support moved from zap helper to real NWC surface
Yana's wallet work has become substantial. Early roadmap items mention Nostr Wallet Connect with balance, URI input, QR scanning, Alby deep linking and `pay_invoice`. Later releases added a fuller wallet layer: send, receive, transaction listing, fiat balance display, NWC subscription notifications and remembering wallet connections. The current code has a dedicated NwcProvider, wallet routes, receive invoice screen, send confirmation screen and a transaction list.
The NWC provider reads a stored connection URI from secure storage, connects through the NDK NWC implementation, checks permissions and exposes balance, make-invoice, pay-invoice and list-transaction capabilities. It refreshes wallet state when payment-received notifications arrive, asks for transaction lists when that permission exists and can disconnect the wallet by clearing the stored URI. The wallet UI then changes according to permissions: receive appears when `make_invoice` is allowed, send appears when `pay_invoice` is allowed, and transaction history appears when `list_transactions` is allowed.
This permission-aware design is exactly what readers should expect from a Nostr Wallet Connect client. A NWC string can represent a small allowance or a broad payment capability, depending on the wallet that created it. Yana tries to inspect what the wallet grants and show only the actions that make sense. Readers should still connect a low-risk wallet first, check spending limits, confirm whether the wallet can revoke the connection and separate testing connections from high-value Lightning funds.
One-click wallet connection and Yana Wallet
Release v0.16.0 added NWC Alby Go one-click connection, and v0.17.0 introduced release flavors including a Yana Wallet app flavor. The Android build file now defines three product flavors: full, wallet and social. The full flavor enables wallet, social, communities, direct messages, search and notifications. The wallet flavor uses a separate application id, enables wallet and direct-message features, and disables the broader social/search/notification set. The social flavor disables wallet while keeping social features.
That flavor split helps explain why Yana appears in NWC ecosystem material. The same codebase can be built as a normal social client or as a wallet-focused interface. The wallet manifest describes Yana Wallet as a Nostr Connect Wallet interface, while the main manifest describes Yana as a client focused on slower-device performance and feature modularity. Readers should therefore check which APK they are installing. The name may be familiar, but the enabled feature set can differ.
The wallet UI also supports Android deep-link flows. The wallet router can launch a `nostrnwc://` intent with app name, app icon and callback information, then handle returned `nostr+walletconnect://` or `yana:` style values. Release v0.17.1 specifically fixed deep-link handling for `lightning:` invoice prefixes. Those details sound small, but they are the difference between NWC being a settings-page curiosity and a payment path that can survive real mobile handoffs.
Zaps work through LNURL, NIP-57 and NWC
Yana treats zaps as both social reactions and wallet actions. The README marks zaps as implemented, including private, public, anonymous and non-zap modes. The UI offers preset zap amounts such as 21, 69, 210, 420, 2100 and 4200 sats on profiles and events, and the event reaction model tracks zap receipts alongside likes, reposts and replies. User statistics can query zap receipts and show zap totals for a profile.
The zap code follows the NIP-57 pattern. It can derive an LNURL-pay endpoint from a `lud16` Lightning address, decode `lud06`, request LNURL metadata, build a zap request event with relay, amount, recipient and event tags, sign that event with the logged-in signer and send the encoded event to the LNURL callback to receive a BOLT11 invoice. If NWC is connected and has `pay_invoice`, Yana can pay the invoice inside the app; otherwise it can generate or hand off the payment in a more traditional way.
This is a good example of Yana's overall style. It does not just paint a lightning icon under a post. It has to know the recipient's Lightning metadata, the relays attached to the zap request, the user's signing path and whether the connected wallet can pay. Readers who care about zap privacy should pay attention to public versus private modes, comments attached to zaps, relay lists included in zap requests and the wallet used for payment.
Media, Blossom and the heavy parts of mobile Nostr
Media is one of the places where mobile Nostr clients become difficult quickly. Yana includes image and URL previews, image picking, multi-image selection, video playback, fullscreen video work, media upload utilities, file picking, NIP-94-style file header handling in search and Blossom-related release notes. Version v0.16.0 specifically lists media upload using Blossom and video-player fullscreen improvements.
The current dependency list tells the same story. Yana uses cached network images, photo manager, video player, image picker, file picker, MIME handling, QR code tools, mobile scanner, markdown rendering, URL launcher and other packages that support a phone client rather than a minimal proof of concept. The v0.17.0 release added Blossom media server management and a new video player, while earlier TODO items show repeated work on video, images, zooming, saving pictures and performance.
Readers should expect Yana to handle media, but not assume every Nostr media edge case is solved. Nostr media is split across event metadata, relay availability, HTTP storage, Blossom servers, NIP-96 servers, preview rendering, app permissions and device performance. Yana's advantage is that it has been working directly on those mobile pain points. The thing to test is whether your preferred image host, Blossom server, video format and phone model behave well in your actual feed.
Direct messages and notifications are useful but platform-shaped
Yana supports direct messages and notifications, but the details depend on platform and feature flavor. The code has a DM provider that loads direct-message events from cache, splits sessions into following, known and unknown groups, tracks read timestamps and subscribes for new events. The app also has notification providers, background-service experiments and settings that let readers include or exclude reactions, reposts and zaps from notification behavior.
The README lists private messages through NIP-04 as implemented. The web NIP-07 signer file, however, leaves encrypt and decrypt methods unimplemented. That does not make DMs useless across the whole app; it means the reader should not assume every signing mode gives the same encryption behavior. Android with Amber, local-key mode and web-extension mode can differ in what they can sign, decrypt and approve.
The safe way to read Yana's DM story is to test it per platform and per account mode. If you care about private messages, confirm whether the app can decrypt old messages, whether your signer prompts for the right permission, whether notifications are appearing as expected and whether the wallet-only flavor you installed is really the one you meant to use. Nostr private messaging is still uneven across clients, and Yana exposes enough of the stack that those differences can become visible.
The codebase is active, but the surface is not polished in the usual way
Yana has the rhythm of an active open-source project rather than a finished corporate app. The GitHub repository was created in August 2023, is MIT licensed and has continued through releases into 2025, with the master branch pushed again in November 2025 for multiple-relay NWC support. Recent release notes mention QR scanner performance, NDK upgrades, new drawer design work, profile editing fixes, pending or failed wallet payments and a followers provider.
The contributor list is small but real. The GitHub API and repository history show contributions from the maintainer under names including Fmar, Fernando Martins and frnandu, plus contributors such as greenart7c3, ZITRON DESIGN, filipegirassol, itstomekk and atrifat. Some changes are clearly community-driven, including Amber support, design work, currency search and video auto-play settings. That matters because the README explicitly says contributors are welcome, especially designers, coders and testers.
The tradeoff is that Yana can feel rough in places. The TODO file is long. It includes completed work, current bugs, wishlist items and future experiments such as better background service behavior, per-account wallet separation, translation, relay improvements, NIP-78 preferences, mnemonic login, F-Droid, live activities and marketplace ideas. That long list is not a weakness by itself; it is a signal that readers should treat Yana as a living FOSS client, not a sealed consumer product.
What to check before using Yana seriously
Start with the release you are installing. Use the GitHub releases page or Zapstore path described by the project, confirm whether you are installing the full, wallet or social flavor and verify the APK signature if you are installing directly. The project homepage configured in GitHub and release manifests is `yana.do`, but readers should be prepared to use the repository and Nostr profile as the more reliable source of truth when the domain is unavailable.
Then choose a key mode deliberately. If you use a local private key, understand that the app stores it in platform secure storage and that anyone with the key controls the account. If you use Amber, read the permission prompt and understand what Amber is being asked to sign or decrypt. If you use web extension signing, test whether the features you need work with that signer. For a high-value identity, begin with a smaller account and confirm export, backup and account switching before depending on it.
Finally, test relays and wallet connections with small stakes. Check whether the feed sees your follows through the gossip model, whether replies reach the people involved, whether blocked relays and mute lists behave the way you expect, whether search relays return useful results and whether NWC send, receive, balance and transactions match the wallet permissions you granted. Yana rewards readers who care about those details. If you want a client that hides them completely, this may not be your first pick.
Sources worth opening
Start with the repository, README, release notes and GOSSIP document, then compare the wallet, relay, signer, settings and release-manifest files that show how the app actually behaves.
- Yana GitHub repository
- Yana README
- Yana GOSSIP model document
- Yana releases
- Yana v0.17.1 release
- Yana v0.17.0 release
- Yana v0.16.0 release
- Yana v0.15.0 release
- Yana v0.14.0 release
- Yana CHANGELOG
- Yana TODO roadmap
- Yana Zapstore manifest
- Yana Wallet Zapstore manifest
- Yana pubspec and dependency list
- Yana Android build flavors
- Yana feature flags
- Yana NWC provider
- Yana wallet router
- Yana wallet send flow
- Yana wallet receive invoice flow
- Yana zap invoice code
- Yana zap action code
- Yana settings and secure storage
- Yana login router
- Yana NIP-07 signer file
- Yana main relay initialization
- Yana relay provider
- Yana filter provider
- Yana search router
- Yana direct-message provider
- Yana Nostr profile on nostr.com
- Yana Nostr profile on njump
- Pull request 115: NWC Alby Go one-click connection
- Pull request 118: Blossom upload work
- Pull request 120: outbox relay-set progress
- Pull request 141: flavors and go_router
- Pull request 144: pending and failed wallet payments
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-51 lists
- NIP-50 search capability
- Amber external signer repository
- Relaystr NDK for Dart
