Nostr Web Client

What do the artists want?

Artists want to be sure theyre getting paid so auto splits.

They also want the ability to make permissionless changes that auto update. Need to make a change in one place and have it appear updated everywhere.

That’s exactly what nostr accomplishes

Not quite always though. It CAN accomplish this but doesnt always. For example, today's bitfest was super cool but zaps went to the user hosting the livestream and not direct split to artists. We have to "trust" the sats eventually make it to the artist. Nostr didnt fix this, in fact it went backwards. With timevaluesplits, its transparent who is getting what sats. So in the live stream example you cam verify artists are getting x% of your zaps.

What are time value splits?

Gonna have to tag in nostr:nprofile1qqs00y32ptdnlfxa5hhv4f30dalwv9vl0a27pqpkdpkx3cyrstp50zqpg4mhxue69uhnwumjwgmkx6revvm8vmrg0fcxxvngdsmxc7t4denhvmr4da585undwsmnv6mzwv6xkmtev358y7r0v94kkcn3w4skgtnvda3kzmp0qythwumn8ghj7cmgv9jxvtnwdaehgu339e3k7mf0qyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uezz4g8 for better explanation but its just a tag within the rss feeds which show, a any given point in the track, which addresses shld get how many % split.

https://podcasting2.org/docs/podcast-namespace/tags/value-time-split

Its actually Value Time Splits (VTS) but that's more for live streams and podcast episodes. Not really what nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac is doing.

What nostr:npub1zm95kw87nf6gkesg76jedyfejt0u2zgx2fxgxywdxc9ugq3z4w2q4m092t wants is just payment splits for his tracks so that a single zap is split between several people based off of the percentages he enters. Same thing as zap splits on Nostr notes. He also has RSS feeds that already have all of this info in them that other apps are using so entering the same info again is kind of redundant.

The profile thing is basically just a landing page for an artists catalog like any site already has.

Where this all get tricky is that HPM and others are trying to combine Nostr and RSS. RSS for delivery and the tracks metadate and Nostr for the social stuff.

Here's nostr:npub1unmftuzmkpdjxyj4en8r63cm34uuvjn9hnxqz3nz6fls7l5jzzfqtvd0j2's proposal on combining some of this stuff.

https://primal.net/merryoscar/open-podcast-payments-with-bitcoin-and-nostr

Thanks! Nostr can definitely act as a delivery mechanism for tracks without rss. This is what my custom new NIP does. It uses replaceable events which can store any amount of text / metadata you like.

Chadf is my chatgpt.

Its just different ways of doing it and no one has done music hosted on Nostr that I know of so im excited to see what you build. The site does look slick.

I don’t understand how these v4v keysend nodes operate… they are technically unlicensed money transmitters because they custody funds before splits occur. Maybe just ignorance is the primary ingredient? 🤣

The keysend stuff is basically just a lighting nodes pubkey. Some people run their own nodes or Foutain and Alby run large nodes for people so you will also see a custom key and custom value that is just the users account on said node.

For you it doesnt matter that much but you have the problem everyone has that most wallets dont support keysend so you have to basically use Alby as a listener.

Derek found this out with zaptrak.app when he added the PC 2.0 music. The feeds have keysend addresses that most wallets cant pay so he just turned them off.

Podcasting 2.0 chose keysend 5 years ago since its a simpler "push" payment but basically no wallets support it so we are looking at moving to lnaddress but we also have 5 years of tech built on keysend.

You only have to worry about this if your importing RSS feeds like the ones nostr:npub1zm95kw87nf6gkesg76jedyfejt0u2zgx2fxgxywdxc9ugq3z4w2q4m092t has. If you just have people upload on your site then they use a lnaddress and everything will be fine.

I’m happy to import MOST info minus the keysend stuff 😆

Can they just add lightning addresses :)

I don’t understand why lightning doesn’t have a new spec for multi-receiver encoded into the QR… then there’s no need for NWC. What am I missing?

Thats basically what Derek did.

They could switch it over if they wanted. It is their feed.

I can shove a cashu token in a QR why not a few lightning payments?

Yeah you should be able to. Need wallet support though.

Wallet support is the problem. After having been down this lightning rabbit hole for so many years, its become so fragmented and hard to know what works with what. There needs to be some sort of unifying standard or process built in so these different wallet types are interoperable.

5 years of tech 5 years ago is today’s 5 minutes of vibe coding

I think his point here is it works and has been proven reliable over time. Can't vibe code proof of low time preference 😉

Hello everyone, I’m happy to see this conversation. The issue as I see it is that we have two possible new (relative to traditional music) distribution systems. One is rss and one is Nostr and both provide for instant global monetization of music. Ainsley success has come from using all of it but it has not been easy. Most Nostr apps are building in a developer bubble and none have taken the time to understand what artists need. That is not a reflection on the app builders who care about music it’s just a fact that Tunestr, Wavlake and even fountain are just new versions of walled gardens. It’s exhausting, as an artist, trying to navigate it all and deal with the political ideologies of each side. As everyone here know I’ve been trying to solve for a solution that bridges both for 2.5 years now. Bitfest was an amazing conference but my take away is that we are not there and this new way is not working for musicians…. Yet.

I'm only having this convo because nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac made a music site that has RSS import and nostr:npub1zm95kw87nf6gkesg76jedyfejt0u2zgx2fxgxywdxc9ugq3z4w2q4m092t has questions about it since they have RSS music feeds.

nostr:nprofile1qqs00y32ptdnlfxa5hhv4f30dalwv9vl0a27pqpkdpkx3cyrstp50zqprfmhxue69uhhqmmyw3shyern9e3k7mf0wpexjanpw3jsz9nhwden5te0vd5xzerx9ehx7um5wgcjucm0d5x9cqyf I’m happy to see you here explaining the RSS side of things to folks. I’ve tried to explain this for years. Both rss and Nostr have their own uses and opinions. They are both valid and understandable but no one has tried to bridge both. If this conversation can lead to a solution that allows all apps to accept both payment systems and help artists do that easily that would be a huge step in the right direction. As you said last night, accurately, these events are inevitably driven by gatekeepers that at this time are people we know and trust. NME, PPM, Tunestr. But that is not how it should be. The magic behind VTS and the split kit is the instant payments to all involved. During our past events we’ve had to have an RSS feed and a Nostr feed and Nostr has always required post event settlement. We need someone on the development side that is willing to look at both and make publishing to both as easy as Distrokid or CDbay. Upload once and it’s monetizable everywhere Nostr or RSS apps. I’ve never been the one to solve it but I understand the issue better than most. We have RSS developers and Nostr develops and I have not found one who will address both sides of the equation.

This is all open for anyone to build on.

That and this V4V music with lightning stuff is part of the podcasting with lightning stuff that's part of podcasting 2.0 that's part of podcasting. So we have to stick to the specs of RSS. This only matters if you want to be "Podcasting 2.0 complaint" and work across must PC 2.0 apps.

This was also built in the opposite way but its all backwards compatible.

Podcasting -> Podcasting 2.0 -> Podcasting 2.0 with lightning -> Podcasting 2.0 with lightning but for music -> Podcasting 2.0 with lightning but for music with a little nostr sprinkled on top.

Eric P 1mo ago

They're just standard Lightning nodes that use Keysend rather than Lightning Address/LNURL/Invoices to receive payments. Most of them (other than Fountain) are self-hosted and self-custodied rather than being hosted by a custodial wallet.

Both Keysend and LNURL are ways to get around Lighting's requirement that a sender needs to ask the recipient to generate an invoice before they can pay them. There's no way to send a "spontaneous payment" in standard Lightning.

Keysend works by sending the payment with an empty invoice. The recipient's node just receives the sats and ignores the fact that there's no invoice attached. The sender uses the node's public key to send the recipient sats via the Lightning network.

LNURL works by putting a publicly-accessible webserver in front of the recipient's node who's only job is to generate invoices for people who ask for them. The sender uses the recipient's Lightning Address to look up the webserver, sends a request to the LNURL callback, and gets an invoice back. They then can pay that invoice on the Lightning network.

V4V nodes chose keysend because it's simpler and requires no additional lookups or servers in the middle of the payment process. You just send a payment from your node to the recipient's node through the Lightning network and that's it.

Wallet providers, including most of the ones the Nostr folks use, chose LNURL and ignored keysend entirely, which is why many here are unfamiliar with it.

This might be the best technical breakdown of keysend vs lnurl ive seen so far. nostr:nprofile1qqsph3c2q9yt8uckmgelu0yf7glruudvfluesqn7cuftjpwdynm2gygpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsqs7amnwvaz7tmwdaehgu3wd4hk6s75adn im not sure youve got an accurate perception of how keysend is actually being used in this pc2.0 space. As I understand, most are all non custodial private nodes or using fountain's node. I think the keysend setup allows for a custodied sort of setup but the reality is everyone's just running their own node. There was a HUGE node running push by the pc2.0 folks last year.

@haspowermusic thanks for diving deep with the Nostr Devs. Nice to see someone else trying to explain what I’ve been experiencing. 🙏

I have had this concern from very early on.

Nostr could definitely fix this but in a manual sort of way for now… there might be other methods I’m not aware of yet.

I think we'll get there. A centralized option is to have bots thay can read the rss feed and auto split out the incoming zap... but then theres all the obvious centralized bot issues

Splits work great with nwc, you can even “stream” zaps without keysend. At one point I was splitting zap streams every 5 seconds

I like that. Now that you invoked keysend... i have a question for you. Can you make some logic on the back end such that it can pick the correct address type based off the senders wallet and whats listed in the rss? It wont fix everything but will fix a chunk of problems going forward... ill explain.

Right now theres a problem in that the huge rss library is all full of keysend addresses. So paying from a lnaddress to keysend (and vice versa) will return an error. Many dont want to move forward with lnaddress because they don't want to be the one feed thats lmaddress. Most paying users are already paying with keysend, so they don't wanna fuck themselves and miss the bulk of payments.

But this reluctance is also the very thing keeping things moving forward. (Well theres also the issue of full metadata not being passed with lnaddress because lnaddress doesnt allow a large enough text field. But this may be solved by nostr:nprofile1qqswfa547pdmqkerzf2uen3agudc67wxffjmenqpge3dylc006fppyspp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgkwaehxw309aex2mrp0yh8qunfd4skctnwv46qa3xytq's metadata implementation)

So there needs to be a transition... a period when, artists can list a primary and secondary wallet (say a keysend and an lnaddress), then when a user pays with a wallet, the back end logic matches the right recipient. This would not magically fix everything but at least it gives a backwards compatible path forward.

I’m happy to implement anything you need in the bounds of what current tech allows. But it’s also a good exercise to see what’s missing so new tech can be developed or adapted to serve specific needs.

VTS is The Split Kit by nostr:npub1yvgrrzf4dnmu30qfhw95x87ruu0g2kpv3a64h8hpvqsre8qeuspsgd6pv9

I imagine nostr:npub1yvgrrzf4dnmu30qfhw95x87ruu0g2kpv3a64h8hpvqsre8qeuspsgd6pv9 would be open to collaborating with a Nostr dev of your caliber.