Oddbean

The second point sounds bad on its face, but I can see why it would look like a "black box" if creators on their platform use a custodial wallet on wavlake. There's no "split" to be made if it's all just one node.

The flow of all capital through the one node regardless of splits or lack thereof and regardless of use of wavlake custodied wallets or the recently added "bring your own" lightning address means that they become in full, custodial, non-transparent control of every single sat that flows to art on the platform and cuts against most of the basic best-practice principles Bitcoiners are usually quite passionate about.

Not arguing for it, just offering an explanation. I think it's reasonable that they take a small cut if they on-boarded the artist. If they do have "byo LN address" and it indeed doesn't transparently split, I agree that's pretty bad.

Yeah I don't personally have a problem with the amount they take at all. Just the way they do it is a bit gross 😅 The market will decide what reasonable hosting fees will be, anyone can charge whatever they want. But the RSS Podcasting 2.0 spec has a way to openly set splits and they have consistently shown an aversion to building in the spirit of that free and open system (and I mean free as in freedom, not as in money)

I haven't built anything following the podcasting 2.0 spec, so I don't know how hard/easy it is to build something to zap. What I do know is that I spent the afternoon picking up the little crumbs of info from wavlake's blog and digging through wavman's code to figure out how to programmatically search for music on nostr and zap it. Surprisingly kinda a pain in the ass, but would have been simple if they documented the process somewhere. Would love to know how it compares to the RSS model, but it's naturally different since music is discovered via relays as opposed to subscriptions. Overall, a pain in the ass. But I'm also not a web dev by choice (though I find myself doing it a lot lately), so take that for what you will.

A great reference for any and all relevant Podcasting 2.0 tags is available on the Project's Github: https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md Everything is built in the open and explained with relevant examples. If you would like a music-centered version of that, I have made a sample music RSS template here that has comments explaining how each tag is used and what values you need for them: https://github.com/de-mu/demu-feed-template/blob/master/feed-with-comments.xml Always happy to answer any questions you might run into or help troubleshoot! I think my favorite aspect of the RSS approach is that you don't really need a lot of coding background to sit down and familiarize yourself with the tags. It's a very accessible spec to build some sort of "my first coding project" in!