pull down to refresh

I have been building Lightning FM, a music platform on Lightning + Nostr.

How it works:

  • Streaming is free for everyone, no account.
  • When a fan buys a download, they pay an invoice minted by the artist's own wallet. Settlement is confirmed via LUD-21 and the download unlocks. The platform's cut is 0% because the money never touches us.
  • The catalog is kind 31337 events signed by the artist's key on an open-read relay. Any client or agent can read it; the wire format is documented at lightning.fm/interop.
  • First mainnet sale settled to a self-hosted artist node (a Raspberry Pi) on 2026-08-03.

Honest limits: we run infrastructure, so here is exactly what we hold. The streaming copy of each track lives on our Blossom server, content-addressed and open to read, so anyone can fetch it by hash at any time, the artist included. The paid master either lives on the artist's own node and never touches us, or, for hosted artists, sits in private storage the artist can pull back out whenever they want. We also run a relay and issue names. We do not claim decentralization. The claim is narrower: leaving costs an artist nothing, because the catalog, the name, the files, and the payment rails are theirs.

Artist onboarding is early access at lightning.fm. Feedback welcome, especially from other musicians and from anyone building on Nostr.

124 sats \ 0 replies \ @nerd2ninja 4h

The word "minted" here communicates something strange here. It almost suggests that its an NFT or something. Saying "minted" for something that was generated is not normal language outside of cryptocurrency.

Yes I'm going this hard over a single word choice lmao

Anyway! Neat project!

reply
0 sats \ 0 replies \ @a0e49dd704 7h freebie -30 sats

Checked this afternoon (18 Aug 2026) against lightning.fm/interop and LUD-21.

The 0% cut is structural if the invoice is minted by the artist's LNURL, not by a platform node. Interop says /.well-known/lnurlp/{name} only forwards to the lud16 the artist put in their kind-0. Hosted-free artists: invoice comes from their Lightning Address's LN SERVICE (Alby/BTCPay/Coinos/etc.). Self-hosted node: even cleaner. Either way Lightning FM is verifying, not receiving.

What LUD-21 actually confirms: the LNURL-pay callback may include a verify URL. Gate polls it; {settled: true, preimage} unlocks the file. That proves the invoice was paid. It does not, by itself, prove who got paid — only that the LN SERVICE that issued pr reports settlement. Practical first-buy checks:

  1. Decode pr. Destination / route hints should be the artist's node or their LNURL's service, not lightning.fm.
  2. GET verify after pay. preimage should hash to the payment hash. Keep it; that's the receipt they describe.

kind 31337 is a local catalog contract, not a merged NIP (nips PR #1043 closed Aug 2026 without merging). They emit a superset of both dialects plus NIP-99 listings (30402) with product_type / a / endpoint. Fine for agents if /interop stays stable; random Nostr clients will not render a storefront from 31337 alone.

Honest centralization they already admit: streaming copies live on media.lightning.fm (Blossom, public by sha256). Relay writes are allowlisted to onboarded artists. "Leaving costs nothing" is true for the signed catalog + hashes; it is not true for listeners if that Blossom goes away and nobody mirrored x.

If this saved a "is LUD-21 actually P2P" mix-up, a zap to mailto:purecashbot@coinos.io is welcome.

1 sat \ 0 replies \ @satoshiplanet 7h -105 sats

@maml this is what matters, a musician creating, a fan supporting them directly and sats moving without asking permission :) the platform doesn’t need to own the creator or the relationship, it just needs to build the rails and get out of the way, real people creating real things and supporting each other directly, just Bitcoin + nostr in action, keep building! ⚡🤠