CraysWavlake
Wavlake is not just a player with a Nostr badge. It is a music publishing, discovery and payment stack where hosted audio, public RSS feeds, Lightning boosts, Nostr comments, NWC wallet control and experimental Cashu-based music credits all meet in one messy, useful place.
Wavlake is easiest to misunderstand if you start with the word "decentralized." A song is not a note. An album is not a short text event. A music platform has heavy files, copyright claims, artwork, feeds, wallets, app-store rules, takedown policies, search, analytics and people who expect playback to work when they press play. Wavlake lives inside all of that. Its interesting move is not pretending those problems disappear. Its interesting move is asking how much of the artist, fan and payment relationship can be pulled toward open protocols while the ugly parts of media hosting still exist.
The public homepage frames the product around streaming anywhere and earning everywhere. That sounds like marketing until you inspect the mechanics. Artists can publish through Wavlake Studio. Listeners can play music on Wavlake, the mobile app or compatible feed readers. Fans can send boosts and messages. Wavlake says uploaded content is hosted on a cloud distribution network it manages, while public RSS feeds are generated for releases and designed to be compatible with Podcasting 2.0 style applications. That is the first honest boundary: Wavlake is not storing MP3 files on Nostr relays. It is using open publishing and payment rails around hosted music.
That boundary makes the app more useful to study, not less. Nostr's strongest consumer examples are often simple social clients, but music asks harder questions. Who owns the artist identity? Can a song be discovered outside one app? Can a boost become public proof of attention? Can a comment on a track be portable? Can listeners pay without being pushed into subscriptions, ads or opaque pool accounting? Can a platform help an artist earn and still avoid becoming another label-shaped gatekeeper? Wavlake is one of the few projects that has been wrestling with those questions in public since 2023.
The short verdict is this: Wavlake is worth trying if you care about music, Bitcoin, Nostr and creator payments, but it should be read as a hybrid. It has open-source clients and public protocol work. It also has company-operated services, managed hosting, app-store distribution, Firebase and Sentry dependencies in the mobile app, an account system, content guidelines and a fee model. If you can hold both facts at the same time, the product becomes clear.
The song is the interface
Most social apps start from the post. Wavlake starts from the track. A listener does not arrive to make a generic note; they arrive to play a song, follow an artist, boost a track, leave a message, share something with another listener or discover what friends are hearing. That changes the shape of the Nostr problem. The key event is not only "Alice said hello." It might be "this artist published this track," "this fan paid this artist," "this listener is now playing this song," or "this service claims a stream happened."
Wavlake's old Wavman experiment made that explicit. In April 2023, Sam Means announced Wavman as an open-source music player built for Nostr. The point was deliberately narrow: plug into a relay, pull a specific event type, parse music metadata and let a user play, zap and comment on a song. The follow-up technical post explained why the team used a small Nostr Open Media, or NOM, document and embedded it in an application-specific parameterized replaceable event, kind `32123`. That event carried fields such as title, creator, duration, link and enclosure. A separate kind `1` note could point back to it, so generic clients could still see and zap a track post even if they did not understand the media object.
That design was practical and a little awkward, which is exactly why it matters. It showed how far you can get with Nostr's existing primitives and where music starts demanding more structure. If metadata can change, a replaceable event is useful. If a track should keep accumulating comments and zaps, a stable social note is useful. If clients need to browse albums, artists, genres and play counts, a single arbitrary JSON blob starts to feel thin. The 2023 Wavman work was not the final architecture. It was a public sketch of the problem.
The newer Wavlake NIP repository moves that sketch toward a fuller music vocabulary. Its draft music metadata proposal defines addressable events for tracks, albums, artist profiles and playlists: kinds `30440`, `30441`, `30442` and `30443`. The streaming receipt draft defines kind `9736` as a public service-signed proof that a stream occurred, without publishing the listener's identity. The listening status draft uses kind `30315`, the NIP-38 user-status family, with `d=music` for now-playing style social discovery. The Wavlake Credits draft describes platform-specific Cashu credits layered over NIP-60 and NIP-61. That is not one feature. It is a proposed music stack.
What Wavlake actually operates
For an artist, Wavlake is first a publishing system. The docs describe Studio as the place where artists and creators upload audio for Wavlake Player and other Podcasting 2.0 compatible apps. The same docs say all content is stored in a Wavlake-managed cloud distribution network, and that anyone with the public content link can access it because those links appear in public RSS feeds. That is an important sentence for artists. Uploading to Wavlake is not the same as putting a private file behind a locked fan club. The base layer is intentionally open.
This has a philosophical reason and a business consequence. Wavlake's docs say the company believes an open base layer for content will benefit artists and listeners over the long run, with bitcoin payments making hard paywalls less necessary. In practice, that means Wavlake is closer to value-for-value publishing than traditional streaming subscription economics. The artist's track can travel. The payment and relationship layer is supposed to follow.
The homepage promises easy publishing, universal distribution and Lightning payments. The useful way to read those claims is operationally. Easy publishing means Wavlake handles hosting and feed syndication. Universal distribution means a release can be exposed through open standards rather than being trapped in one player. Lightning payments mean the artist can receive bitcoin from fans through Wavlake's wallet path and withdraw it. None of that removes Wavlake from the loop. It tells you exactly where Wavlake sits in the loop: hosting, feeds, discovery, wallet UX and platform policy.
The Developer API docs add another layer. The public Swagger spec describes a Wavlake API under `wavlake.com/api/v1`, including content search by artist, album or track title, and LNURL endpoints. That is not the same thing as a fully decentralized catalog, but it is useful for builders. It means Wavlake is exposing machine-readable surfaces around its catalog and payment layer while it experiments with Nostr-native catalog events in parallel.
The NIP-05 document at `wavlake.com/.well-known/nostr.json` is also worth reading because it anchors public Nostr identities to the domain. It maps names such as `_`, `music`, `michael`, `josh`, `tickets` and `means` to hex public keys. The public Wavlake profile on nostr.com matches the project branding and points to the mobile app. That matters because a music platform's protocol credibility depends on identity continuity. If the listener cannot tell which artist, app account or service key is real, zaps and stream receipts become easier to spoof socially even when the cryptography is fine.
Nostr started as a music experiment
Wavlake's Nostr story did not begin as a vague slogan. It began as a concrete music player. Wavman was open source, tiny and intentionally opinionated. The team chose an app-specific event kind because there was no mature, shared way to publish music metadata on Nostr. They chose a NOM document because a song needed a predictable body: title, creator, media URL, duration and version. They published track notes so existing Nostr clients could still see the songs and interact with them. That combination tells you a lot about Wavlake's mentality: build the thing, learn where the protocol bends, then write down the rough edges.
The mobile source still carries pieces of that history. In `utils/nostr.ts`, Wavlake's mobile app defines `wavlakeRelayUri` as `wss://relay.wavlake.com/`, `wavlakeTrackKind` as `32123` and `ticketEventKind` as `31923`. The same file imports `nostr-tools`, uses NIP-57 zap helpers, creates NWC request events, fetches zap receipts of kind `9735`, publishes listening status events of kind `30315`, reads relay list metadata and generates NIP-98 HTTP auth tokens. In other words, the production mobile app is not merely linking to Nostr from a settings screen. Nostr is in its playback, payment, relay and authentication plumbing.
There is also visible evolution. The 2023 Wavman write-up centered kind `32123`. The 2026 Wavlake NIP drafts center kinds `30440` through `30443` for tracks, albums, artists and playlists. The web repository has its own music kinds, including `31337` and `31338`, in an active Nostr community codebase. The web-client debug harness tests kind `30440` discovery and paywall flows. That can look inconsistent if you expect a finished standard. It makes more sense if you see Wavlake as a working lab: old application kinds, current app code and draft public specs are all visible at once.
That is both a strength and a risk. The strength is that the team is not waiting for perfect standards before shipping. The risk is that builders need to check which version of the music model a client actually supports. A generic Nostr client may render the kind `1` track note and ignore the richer music metadata. A newer music client may expect `30440` and miss older `32123` data. A service may publish receipts that only clients who trust that service pubkey should count. Music on Nostr is not one settled lane yet. Wavlake is helping draw the lanes while driving on the road.
The mobile app is the current product
The mobile app shows where Wavlake has moved from experiment to consumer product. The iOS App Store lists Wavlake as "Wavlake - Social Music Player," with a discovery and rewards pitch, 13+ age rating, Music category, Wavlake Inc. as seller and version history through 1.0.7 on November 8, 2025. The visible release notes mention banner updates, signup fixes, adding artists to the library and improved Nostr event handling. Google Play lists the Android app under Wavlake, Inc., with 10K+ downloads, parental guidance and a November 2025 update trail.
The mobile landing page says the app is available for iOS and Android, points to GitHub, offers sideloading for the latest release and mentions TestFlight. The GitHub mobile repository is MIT licensed, built with Expo and React Native, and had public APK releases through `v1.1.8-1`. Its dependencies tell a realistic story: `nostr-tools` for protocol work, Firebase auth, Google and Apple sign-in, Expo Secure Store, React Native Keychain, Sentry, Track Player, QR scanning and wallet code. This is not a pure browser-signer app. It is a native mobile product with normal mobile infrastructure and Nostr inside it.
That design has user consequences. A listener can create or connect identity, listen, zap, comment and optionally publish comments to Nostr. The zap screen validates amounts between 1 and 100,000 sats, shows the wallet balance, lets the user write a comment and warns that if the user is not connected to Nostr, zaps and comments will be limited. If the `publishKind1` setting is on, Wavlake can publish a comment with a Wavlake track URL and a `nostr:nevent` link after the zap receipt arrives. That is a nice product detail: the payment is not only a private invoice event. It can become a social comment trail around the song.
The app also supports Amber login on Android when Amber is installed, and it has Nostr relay-list hooks that fall back to default read and write relay sets when no user relay list is found. That matters for portability. A listener's social experience depends on relay reach. A comment or status that only Wavlake's relay sees is less open than one that follows a user's relay list. Wavlake appears to be moving in the right direction by reading relay metadata and exposing Nostr-specific controls, but the relay model is still a place to test, not assume.
The store privacy signals deserve adult attention. Apple says Wavlake may handle identifiers linked to the user and diagnostics not linked to the user. Google Play says the app may collect personal info, says no data is shared with third parties according to the developer declaration, says data is encrypted in transit and says deletion can be requested. The code includes Firebase and Sentry. None of that makes Wavlake bad. It means the mobile app is a normal operated app with open-protocol features, and privacy-sensitive users should treat it that way.
The money layer is real and constrained
Wavlake's payment story has several layers. The old docs call a Boost a small bitcoin payment to the creator of a track, denominated in sats, and say every Message requires a minimum Boost. The same docs say Wavlake takes 10% from every track boost and message boost, while funding and withdrawal fees are only the Lightning transaction fees. That is clear enough for a first model: fans pay artists directly through the platform's Lightning flow, and Wavlake takes a fee on boosts.
Nostr adds public payment context through NIP-57 style zaps. The mobile code builds zap requests, sends them to `https://www.wavlake.com/api/zap`, watches for zap receipts on `wss://relay.wavlake.com`, parses the original zap request out of the receipt description and can turn a paid comment into a Nostr-published note. The code is careful about failure: it can still complete the payment even if posting the comment fails, and it reports that case differently. That is the correct instinct. Money and social publishing should not fail in the same way.
Nostr Wallet Connect is the convenience layer. Josh Remaley's 2024 Wavlake Zine post explains the idea plainly: instead of leaving the app, opening a Lightning wallet and scanning or pasting an invoice, NWC lets the app send encrypted wallet commands through Nostr. The mobile source matches that. Users can scan or paste an NWC URI, connect the mobile app to a Wavlake wallet, set a weekly budget and set a maximum zap amount. The settings screen requires the maximum zap to be below the weekly budget and above the default zap amount. That is not cosmetic. It is the difference between one-tap zaps and accidental wallet drain.
The Wavlake Credits draft points to a different payment experiment. It defines WLC as non-redeemable Cashu tokens for streaming content, tipping artists and purchasing access, with `1 WLC = 1 USD cent`. It uses NIP-60 and NIP-61 event kinds for wallet info, token events, spending history and nutzaps, while warning that WLC is a platform-specific unit, not sats. The web-client debug harness reinforces the direction: it tests kind `30440` track discovery, Cashu wallet operations, HTTP 402 content access, tokens and signed playback URLs.
This is where the product becomes genuinely interesting and genuinely risky. Lightning boosts are understandable. NWC improves UX but expands permission risk. Cashu credits could make tiny content payments smoother, but a non-redeemable platform unit has a very different trust profile than sats. Public streaming receipts could help artists audit play counts, but only if clients know which service pubkeys to trust and if receipts are not inflated. Wavlake is testing the creator-money surface where payment UX, privacy, incentives and accounting all collide.
The team and code trail
The public company story is unusually visible. Bitcoin Magazine's 2024 profile lists Wavlake as a private company founded in 2022 by Sam Means and Michael Rhee, with headquarters listed across Chicago, New York and Phoenix and three employees. The same article describes Wavlake as using Bitcoin's Lightning Network and Nostr and frames Means as bringing long music-industry experience into a Bitcoin-native music platform. TFTC's January 2023 episode with Sam Means and Michael Rhee says the company was founded to disrupt music using bitcoin, RSS and value-for-value monetization.
The company identity also shows up in app-store records. Apple lists Wavlake Inc. as seller. Google Play lists WAVLAKE, INC., gives a Phoenix address and support email, and points to Wavlake's privacy policy. The NIP-05 document maps `means`, `michael`, `josh`, `music` and other names to public keys. The Wavman announcement credits Josh Remaley for leading development of the Wavman client. That is enough to write about a real team, not a faceless app directory entry.
The GitHub organization is broader than the mobile app. It includes `mobile`, `web`, `web-client`, `NIPs`, `nom-spec`, `wavman`, `developer-docs`, `embed`, `compressor`, `ticketbot`, `nutshell`, `poc-ecash` and other repositories. The mobile app is MIT licensed. Wavman and the NOM spec are public. The newer web app README says Wavlake is adapting a Nostr community platform for artists and fans, with artist communities, direct support, Cashu payments, Nostr posts, community moderation and music-focused features. The web repository also includes music publishing hooks, NIP-98 auth helpers and Cashu/nutzap code.
That trail does not mean every service is open source or every backend is auditable. The hosted CDN, production wallet services, moderation systems, account infrastructure and business operations still require trust in Wavlake. But the public trail is strong enough to evaluate direction. You can read old NOM work, current mobile code, draft NIPs, API docs, store listings and external interviews. For a Nostr app profile, that is a better research surface than most.
Risks artists should read first
The first risk is rights. Wavlake's content guidelines are blunt: users must not upload material they do not have the legal right to distribute, and by uploading content they represent that they have rights to the recordings, compositions and artwork. The guidelines also mention recording and publishing agreements, mechanical licenses for cover songs and master licenses for sampled recordings. This matters because music is legally dense. A Nostr key does not clear a sample. A zap does not replace a publishing license.
The second risk is openness. Wavlake's docs say anyone with the public link can access uploaded content, and those links are in public RSS feeds. That is the business thesis, but it also means a release can be copied, cached, scraped or shared outside the context where fans are encouraged to pay. Artists who want scarcity, exclusive gating or strict territorial release control need to understand that Wavlake is built around open availability and voluntary or lightweight payment flows, not traditional DRM.
The third risk is custody and permissions. Wavlake has a built-in wallet experience, Lightning withdrawals, NWC connections and, in newer work, Cashu-style credits. Each layer has a different trust model. A Wavlake wallet is not the same as a self-custodied node. An NWC secret can authorize payments until revoked. A non-redeemable WLC credit is not bitcoin. A mobile app with a saved key or wallet connection can make zapping easy, but if the device is compromised, the convenience becomes exposure. Wavlake's own NWC article warns that a person with your unlocked phone could abuse a wallet connection.
The fourth risk is standards churn. Wavlake has old `32123` media events, newer `30440` draft metadata, web code using other music kinds, Nostr comments, zaps, listening statuses, NIP-98 HTTP auth, NWC and Cashu experiments. That is vibrant, but it is not settled. If you are an artist building your catalog around Wavlake, export and document your metadata. If you are a developer building a client, test real events instead of assuming one draft describes production perfectly.
The fifth risk is moderation and dependency. Wavlake can remove content or suspend accounts under its guidelines. App stores can reject or constrain mobile behavior. Relays can miss events. The Wavlake relay can be unavailable. A CDN can fail. A payment endpoint can change. None of those facts cancel the open-protocol work. They define the actual product boundary. Wavlake gives artists a more open payment and discovery path than mainstream streaming, but it is still an operated platform.
How to test Wavlake
If you are a listener, start with the mobile app and one low-stakes payment. Install Wavlake, find a track by an artist you actually like, inspect the artist profile, send a small boost, add a message and decide whether you want that comment published to Nostr. If you connect NWC, set a tiny weekly budget and a conservative maximum zap amount first. Then check whether the zap receipt or comment can be found outside the app through a Nostr client or relay-aware tool.
If you are an artist, do not upload your most legally complicated release first. Upload a track where you control the master, composition and artwork. Inspect the public release page, RSS feed, artwork, audio URL and payment behavior. Check what the Wavlake Player shows, what the mobile app shows and whether another Podcasting 2.0 compatible or Nostr-aware surface can find it. Then test a withdrawal. The point is to learn the whole path: upload, distribution, discovery, boost, fee, wallet and export.
If you are a builder, read the code before the pitch. Start with `wavlake/mobile` and its `utils/nostr.ts`, zap flow, NWC settings and comment utilities. Then read `nom-spec`, `wavman`, the Wavlake NIPs repo, the web-client paywall debug README and the developer Swagger spec. Compare `32123`, `30440`, `30315`, `9735`, `9736`, NIP-57, NIP-60, NIP-61 and NIP-98 in real code. The interesting work is not in deciding whether Wavlake is decentralized enough. The interesting work is deciding which parts of music can become portable, verifiable and payable without making artists run infrastructure for a living.
The fair conclusion is that Wavlake is one of the more serious Nostr media projects because it has both product and protocol scar tissue. It has hosted music and company policy. It has app-store apps and open-source code. It has Bitcoin payments and payment UX hazards. It has public track interactions and unsettled music metadata standards. It is not the final answer to music on Nostr. It is a working attempt with enough public surface for artists, fans and builders to learn from.
Useful Nostr context
These pages connect music, creator payments and broader media publishing context.
- Media: The broader media and creator publishing shelf.
- Geyser: A useful funding comparison for creator projects.
- NIP-57 zaps: The zap model behind many creator payment flows.
- Wallets: Wallet context for listeners, artists and payment permissions.
Sources worth opening
Start with Wavlake's own docs and code, then compare the older Wavman/NOM work with the newer Wavlake NIP drafts and mobile app source.
- Wavlake official site
- Wavlake Docs
- Wavlake Content Guidelines
- Wavlake mobile iOS and Android landing page
- Wavlake NIP-05 document
- Wavlake public Nostr profile
- Wavlake on the Apple App Store
- Wavlake on Google Play
- Introducing Wavman
- How we built Wavman
- Frictionless Zaps and Nostr Wallet Connect
- Wavlake GitHub organization
- Wavlake mobile app repository
- Wavlake mobile README
- Wavlake mobile package.json
- Wavlake mobile releases
- Wavlake mobile Nostr utilities
- Wavlake mobile zap screen
- Wavlake mobile zap content hook
- Wavlake mobile NWC settings
- Wavlake mobile auto NWC flow
- Wavlake mobile NWC scanner
- Wavlake mobile Amber login button
- Wavlake mobile user context provider
- Wavlake mobile comment utilities
- Wavlake mobile Amber signer hook
- Wavlake mobile relay list hook
- Wavlake NOM spec repository
- Nostr Open Media spec README
- Wavman repository
- Wavman README
- Wavlake NIPs repository
- Wavlake NIPs overview
- Wavlake music metadata draft
- Wavlake streaming receipts draft
- Wavlake listening status draft
- Wavlake Credits draft
- Wavlake web repository
- Wavlake web README
- Wavlake web Nostr kinds
- Wavlake web music publishing hook
- Wavlake web nutzap hook
- Wavlake web NIP-98 auth helper
- Wavlake paywall debug client repository
- Wavlake paywall debug client README
- Wavlake developer docs repository
- Wavlake Developer API docs
- Wavlake Developer API Swagger spec
- Wavlake embed player repository
- Wavlake compressor repository
- Wavlake ticketbot repository
- Wavlake nutshell repository
- Bitcoin Magazine profile of Wavlake
- TFTC interview with Sam Means and Michael Rhee
- NIP-33 parameterized replaceable events
- NIP-38 user statuses
- NIP-57 Lightning zaps
- NIP-60 Cashu wallets
- NIP-61 Nutzaps
- NIP-98 HTTP auth
