Oddbean new post about login | logout I asked to have the supporters count back, never got a reply.
I should have added an /s, I am not *actually* surprised. I have had my own concerns go ignored or be passively dismissed by them over the past couple years.
I got a sense of it at Slavelake 🤣🤣🤣 Do you mind sharing the concerns? Were they communicated on nostr in the open?
I got to them in Telegram before they ever had a nostr presence. And before they had messages auto-delete in Telegram 😅 I have 3 main concerns: 1) They build out RSS feeds for their artists in order to distribute their music to other Podcasting 2.0 apps, but they do not surface non-Wavlake music feeds in their own music player app. Walled-garden content approach. So self-hosted albums like ours are not surfaced in Wavlake. 2) The RSS feeds they build include a value tag that points 100% of the boosted sats to Wavlake's node. They then do all their "splits" in their black box behind the scenes with 0 transparency. 3) Because of this implementation, they can rugpull artists who are from the "wrong" countries. Early on a Russian music teacher had taught his students about Wavlake and had them upload some songs. These songs received sats from Wavlake users. When they went to go withdraw the sats they earned, Wavlake said "sorry buddy you are Russian, we are keeping your sats." This is antithetical to Bitcoin and frankly the most offensive of all the things I've seen from then so far. As a result the Russian teacher assumed this was a failure of Bitcoin itself and not just of Wavlake's poor/selfish implementation.
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!