CraysYakBak
YakBak is a focused Nostr client for short spoken posts. Its interesting part is not the microphone button; it is the way a browser recording becomes a blob on a Blossom server, a signed event on relays, a reply tree, a reaction target and a zap target.
Voice notes change the pace
YakBak is easy to underestimate because the first screen is so plain. The live app at yakbak.app loads as a PWA with the title "YakBak - Voice Messages on Nostr", a YakBak wordmark, a login button and a Global feed control. Its public meta description promises a simple decentralized voice messaging app for recording and sharing voice messages with friends and followers on Nostr. NostrApps reduces the pitch even further: voice notes, record and publish, follow people, view feeds, view relay-specific feeds and publish nested replies.
That plainness is useful. YakBak does not try to replace a full social client. It answers one question: what if the unit of a Nostr feed was not a paragraph, an image, a live stream or a long-form article, but a short spoken note? For some people that is a gimmick. For others it is the difference between participating and staying silent. Spoken updates carry tone, hesitation, emphasis and place in a way text often strips out. They also cost more attention. A voice feed asks the listener to spend real time.
The product therefore sits in a narrow but serious lane. It is not a podcast app; the recording cap in the code is sixty seconds. It is not real-time chat; an open issue explicitly asks for real-time voice chat "similar to Mumble" and a mobile client, which means those are future wishes, not current claims. It is not a private messenger; the default behavior is public posting to relays and public audio URLs. YakBak is closer to a public walkie-talkie feed for Nostr identities, built with browser media APIs, Nostrify, Blossom and Lightning.
The most important design choice is that YakBak keeps the app small enough for inspection. The repository is public under `derekross/yakbak`. The GitHub API describes it as a modern social platform built on the Nostr protocol that lets users share and interact with voice messages. The code is TypeScript, React 18 and Vite, with Nostrify for relay work, TanStack Query for data fetching, shadcn/radix components for the interface and Alby SDK for wallet actions. As of the June 7 2026 research pass, the repository had 10 stars, 2 forks, 4 open issues, no license object in the GitHub API, and its latest push was May 22 2025. That is not a huge app ecosystem. It is a small product with a readable trail.
That matters because audio has a different trust shape from text. A note can be skimmed, searched, quoted and translated. A voice clip is heavier. It can contain background details, accidental personal information, someone else's voice, a room sound, an address, a name, a child, a business conversation or a private joke that becomes public context. YakBak's usefulness and risk are therefore the same thing: it makes speaking into Nostr easy.
What YakBak publishes
The key event in YakBak is `kind 1222`. The recording button creates an audio blob in the browser, uploads that blob, then publishes a Nostr event whose content is the audio URL. Hashtags become `t` tags. Replies add `e` tags for root and reply context and a `p` tag for the parent author. The reply publisher also stores a `duration` tag. The event is signed through the current Nostr login signer and pushed through the app's configured relays.
This looks simple, but it is doing a lot of work. A Nostr relay is not carrying the whole file. It carries a signed pointer and metadata. The heavy object lives on an HTTP blob server. In one sense that is exactly right: relays should not become arbitrary media hosting services. In another sense it means the permanence and portability of a YakBak post depends on two layers, not one. If the event remains but the blob disappears, a client can still prove that a note existed, who signed it and what URL was used, but it cannot play the audio.
The voice-message draft in the NIPs repository is NIP-A0. It defines `kind 1222` for root voice messages and `kind 1244` for voice replies, with short messages typically up to sixty seconds. YakBak's code uses `kind 1222` for root posts and also for voice replies, distinguishing reply context with tags. That is a concrete interoperability detail, not a philosophical one. A client that expects NIP-A0's split may miss YakBak replies if it only searches `kind 1244`. A client that treats `kind 1222` plus reply tags as enough may show them correctly. This is the kind of drift that happens around draft standards while real apps are already in people's hands.
A June 7 2026 spot check against YakBak's default relay set also showed why article claims should stay precise. A `COUNT` query for `{kinds:[1222]}` returned 3 on `wss://relay.damus.io` and 308 on `wss://nos.lol`; `wss://relay.primal.net` replied that `COUNT` was an unknown command, and `wss://relay.nostr.band` timed out. Those numbers are not "YakBak usage". They are a rough measurement of one voice-event kind on selected relays. A sample event from `nos.lol` pointed at a Blossom URL and included `imeta`, duration and waveform data. A sample from `relay.damus.io` named Ditto as the client. The useful conclusion is that YakBak is joining a wider open voice-message convention rather than building a sealed format.
That is the healthiest reading of the app. YakBak does not need to own the voice network. It needs to publish events that other Nostr clients can reason about. The closer it stays to the draft and to common metadata practices, the more likely a listener can find a post outside YakBak later. The more it uses app-specific assumptions, the more likely the post becomes portable only in theory.
Recording and Blossom storage
The recording flow starts with normal browser permissions. The floating voice-message button requests `navigator.mediaDevices.getUserMedia({ audio: true })`, uses `MediaRecorder`, enforces `MAX_RECORDING_TIME = 60`, and holds the audio as a browser blob. The app lets the user play, pause, trash and tag the recording before publishing. Hashtags are limited to three and are parsed from whitespace or commas. That limit is a small but good product choice. Audio feeds can become messy quickly; a handful of tags keeps discovery useful without turning every clip into a keyword dump.
The upload layer is Blossom. YakBak asks for the user's Blossom servers by querying `kind 10063` events and reading `server` tags. If it does not find a user preference, it falls back to `https://blossom.band`. The upload function calculates a SHA-256 hash, builds a Nostr authorization event, signs it, base64-encodes it into an `Authorization: Nostr ...` header, and sends the file to the server's `/upload` endpoint. The Blossom helper uses `kind 24242` for the authorization event and includes tags such as the verb, expiration and file hash.
That is exactly the kind of detail a user should care about. You are not just giving YakBak a file. You are authorizing a storage server to accept a blob tied to your Nostr identity. Blossom is built for this separation: relays handle signed events, Blossom servers handle media. BUD-01 describes media blob storage; related Blossom documents describe authorization and server behavior. The benefit is modularity. The risk is that you must understand which server receives the audio and what deletion means there.
YakBak verifies that the upload response hash matches the calculated blob hash. That is a meaningful integrity check. It does not solve moderation, availability, jurisdiction or retention. A file can be valid and still be something you regret publishing. A storage server can be honest and still be down tomorrow. A public audio URL can be copied by anyone before you delete it. This is not a YakBak-specific accusation; it is the nature of public media on an open network.
There is also a small implementation quirk worth naming because it affects cross-client expectations. The recorder creates an `audio/webm` blob, while the upload wrapper comments about the correct MIME type for the Blossom server and wraps the blob with `video/webm`. On playback, the post component renders an audio element with `source type="audio/webm"`. Browsers are forgiving, but media type mismatches can become annoying when files move between clients, mobile browsers and storage gateways. A mature voice ecosystem will need predictable MIME, duration, waveform and metadata behavior.
Feeds, replies and routes
YakBak's default relay list is visible in `src/App.tsx`: `wss://relay.primal.net`, `wss://relay.nostr.band`, `wss://relay.damus.io` and `wss://nos.lol`. The same file contains a pointed comment that using just one relay currently offers the best performance. That comment says a lot about the real product problem. Voice posts are not hard only because audio files are heavier. They are hard because every feed needs a tolerable mix of freshness, completeness, relay latency and duplicate handling.
The `NostrProvider` uses Nostrify's `NPool` and `NRelay1`. Its request router sends filters to all configured relays, and its event router publishes to all configured relays. The feed component uses TanStack infinite queries with a page size of 10. Global feed queries ask for `kind 1222`. The following feed first fetches the logged-in user's `kind 3` contact list, extracts `p` tags, then queries voice messages by those authors. A polling loop checks for new events roughly every five seconds. Pagination uses the last event's `created_at - 1` as the next `until` boundary.
This is a very Nostr-shaped feed. It is simple, client-side and inspectable. It also carries the usual Nostr feed tradeoffs: if your follows are stale, the following feed is stale; if relays are slow, the feed is slow; if one relay has a post and another does not, the experience changes depending on where you are connected. YakBak's issue tracker records that reality. Issue #2 describes a feed refresh bug where a following feed can reset to global or report no follows. Issue #3 says replies did not show in the feed after posting until a full refresh. These are exactly the bugs a small client hits when optimistic UI, caches and relay confirmation have to line up.
Replies are treated as voice posts with thread tags. The reply flow records audio, uploads it through Blossom, then publishes `kind 1222` with an `e` tag for the root, an `e` tag for the immediate parent marked `reply`, a `p` tag for the parent author and a duration tag. The single-message route decodes `nevent`, fetches the target message, fetches replies that reference it, and, if the message itself is a reply, fetches the root message so the reader can see context. That is the right shape for a tiny audio thread. It turns a clip from a loose object into a conversation object.
YakBak also includes routes for `/profile/:npub`, `/message/:nevent`, `/hashtag/:hashtag`, `/settings` and `/about`. That route set tells you what the maintainer thinks the product is: identity, a shareable message URL, topic discovery, wallet settings and a short explanation page. It is not yet a broad social dashboard. It is a set of surfaces around one action: speak, publish, respond.
Zaps and wallet boundaries
Audio changes zaps. A text note can be rewarded for an idea. A voice note can be rewarded for presence: the quick answer, the field report, the thought someone did not want to type, the joke, the song sketch, the support message. YakBak's post component therefore includes three social actions that matter: reactions, zaps and deletion requests.
Reactions use `kind 7`, with `+` as the content and tags for the event and author. If the current user has already reacted, the app removes that reaction locally by publishing a `kind 5` deletion request tagged to the prior reaction. Deleting one's own voice message also publishes `kind 5`, tags the original event id and removes the message from local caches. That language matters: it is a deletion request, not guaranteed erasure. NIP-09 explicitly frames deletion as a request relays may honor. Other relays, clients, archives, screenshots and copied audio URLs can outlive it.
Zaps combine NIP-57 and wallet plumbing. YakBak queries zap request and receipt kinds `9734` and `9735`, looks up author metadata, checks for a Lightning address, builds a zap request event with `p`, `e`, amount and relay tags, then pays through `useNWC`. The wallet hook stores settings under `yakbak-nwc-settings`, uses Alby's SDK, accepts a Nostr Wallet Connect connection string and treats a non-BOLT11 recipient as a Lightning address by fetching the recipient's LNURL pay endpoint. The settings page exposes Nostr Wallet Connect and points users to Alby's NWC page.
This is convenient, but it is a bright boundary. A user can listen without giving the app wallet power. The moment NWC is configured, YakBak has a route to payment actions through the user's wallet connection. NIP-47 exists so apps do not need custody of funds, but the user still needs to understand spending limits, connection strings, local storage and the difference between signing a social event and authorizing a wallet action. The safest mental model is simple: your signer proves identity; your Blossom server stores media; your wallet connection moves sats. Do not blur those three just because they sit behind one interface.
Builder, codebase and maturity
The public maintainer trail points to Derek Ross. The GitHub repository owner is `derekross`, and the open issues are partly filed by that same account. The repository was created on May 13 2025 and pushed most recently on May 22 2025, while its GitHub metadata was updated in March 2026. The package file still uses the name `mkstack` and version `0.3.2`, which suggests YakBak grew from a starter stack rather than a long-running product codebase with its own polished package identity.
That is not a criticism by itself. Many useful Nostr clients start as focused experiments. The important question is whether the experiment is legible. YakBak is. The README explains voice recording, playback, threaded voice conversations, Lightning zaps, reactions, Nostr integration, shadcn UI and real-time updates. The About page says messages are stored on preferred Nostr relays and Blossom servers, and that YakBak does not store user data on its own servers. The source files make the publish, upload and wallet flows easy to trace.
The codebase also shows places where a production audit would slow down. The README says "MIT License", but the GitHub API returned `license: null` and a license file was not visible in the quick repository tree used for this article. That mismatch matters for reuse. The settings types and wallet settings deserve a second look before anyone treats the app as a payment-heavy tool. The open issue list is short but revealing: muting is not yet done, following-feed refresh has been buggy, replies have been buggy, and real-time/mobile is still an idea. Those are not fatal. They are maturity markers.
In a larger company, these details might be buried under a roadmap page. Here they are in the open. That makes YakBak easier to trust in one way and easier to question in another. You can see the rough edges. You can also decide whether they are acceptable for your use. For a public voice-note toy, maybe yes. For a newsroom, school, venue, business, support community or creator fan club, the unanswered moderation, deletion, storage and wallet questions need a deliberate policy before use.
Where YakBak can go wrong
The first risk is discoverability without enough filtering. Voice notes are harder to scan than text, so a noisy global feed becomes exhausting quickly. YakBak has a following feed and hashtags, but issue #1 asks for mute support. Until muting is implemented and reliable, users have fewer tools to remove people or topics from the listening experience. Audio feeds need mute controls sooner than text feeds because the cost of checking bad content is higher.
The second risk is accidental permanence. A YakBak message is a public signed event plus a public media URL. A `kind 5` deletion request can ask relays to stop serving the event, and Blossom servers may support deletion behavior, but the clip can be copied. This is especially important for voice because audio leaks more context than the speaker expects. The privacy rule is not complicated: if you would not want the raw clip replayed later by someone outside the intended audience, do not publish it as a public voice note.
The third risk is signer and wallet confusion. YakBak's social publishing needs a Nostr signer. Zaps need wallet configuration. Blossom upload authorization needs signed Nostr authorization. These are three different classes of consent. A careful client should keep them visually distinct, and a careful user should pause when the browser asks for microphone access, when a signer asks to sign, when a storage server receives a file and when a wallet connection is added.
The fourth risk is standard drift. The NIP-A0 draft says root voice messages use `kind 1222` and replies use `kind 1244`. YakBak currently uses `kind 1222` for both root posts and replies. That may be survivable if clients look at tags; it may be painful if clients use kind filters narrowly. In a small network this kind of detail can decide whether a post appears to have vanished when opened in another app.
The fifth risk is reliance on a sparse maintainer surface. YakBak is open-source and inspectable, but it is also small. With 10 stars and four open issues at the time of this research pass, it should be treated as a promising niche client, not infrastructure. That is a perfectly respectable place to be. It simply means teams should test before adopting it for anything where archives, moderation, user safety or payments matter.
How to test it
Start without a wallet. Open yakbak.app, confirm the app loads, read the About page and inspect which login methods your signer offers. Do not grant microphone permission until you actually intend to record. When you do record, make a throwaway public test clip with no private background information. Publish it, copy the message URL, and then look for the event through another Nostr tool that can query `kind 1222`. The point is not to make a nice first post. The point is to prove you understand where the event and the audio land.
Next, test the storage path. Check whether your preferred Blossom server is being used or whether YakBak falls back to `blossom.band`. If you have set a `kind 10063` Blossom server list elsewhere, confirm that YakBak respects it. Then test a deletion request and see what disappears from YakBak, from the relay you queried and from the raw audio URL. Treat any remaining copy as the normal behavior of public media, not as a surprise.
Only after that should you test zaps. Add a low-limit NWC connection, set a tiny default zap amount, and send a small payment to a test note from an author with a valid Lightning address. Watch which prompt belongs to the signer and which action belongs to the wallet. If those prompts feel confusing, remove the wallet connection and use YakBak as a listening and posting client only.
The best audience for YakBak right now is a Nostr user who understands that public audio is public, likes fast spoken updates and is comfortable testing small open-source clients. The worst audience is someone looking for private voice chat, enterprise moderation, guaranteed deletion or a polished mobile app. YakBak may grow toward some of that, but the current evidence says its best job is narrower: make short Nostr voice notes easy enough that the network can find out whether it wants them.
Sources worth opening
These are the pages and source files used for this pass. Start with the live app, then read the repository files that govern recording, relays, Blossom uploads, wallet actions and open issues.
- YakBak live app
- YakBak web app manifest
- NostrApps YakBak listing
- derekross/yakbak repository
- GitHub API metadata for derekross/yakbak
- YakBak README
- YakBak package.json
- YakBak app providers and default relays
- YakBak NostrProvider
- YakBak voice recording component
- YakBak voice message feed
- YakBak voice message post component
- YakBak Blossom upload helper
- YakBak Nostr publishing hook
- YakBak Nostr Wallet Connect hook
- YakBak About page source
- YakBak Settings page source
- YakBak single message route
- YakBak hashtag route
- YakBak router
- YakBak issue #1: mute support
- YakBak issue #2: feed refresh bug
- YakBak issue #3: replies
- YakBak issue #6: real-time voice chat and mobile
- NIP-A0 voice messages draft
- NIP-01 basic protocol flow
- NIP-02 contact lists
- NIP-09 event deletion requests
- NIP-10 threaded notes and replies
- NIP-19 bech32 identifiers
- NIP-25 reactions
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning zaps
- NIP-94 file metadata
- NIP-96 HTTP file storage integration
- Blossom specification repository
- Blossom BUD-01 media blob storage
- Blossom BUD-02 authorization
- Blossom BUD-03 user server list
- Nostrify package
- Nostrify React package
- Alby JavaScript SDK
- Nostr Wallet Connect documentation
