We dont need a one-app. We need wide interoperability and pay-per-use bots that turn nostr zaps into boostagrams and rss uploads into nostr notes. That'd be cool.
We need tools that notify us on nostr when stuff happens in the RSS world.
We need tools that help listeners discover, follow, and boost/zap their favorite artists.
If anyone wants to build in the demu space, these are some quick ideas on the FAN side of things
I submitted an nostr:nprofile1qqs8suecw4luyht9ekff89x4uacneapk8r5dyk0gmn6uwwurf6u9ruspzpmhxue69uhkumewwd68ytnrwghszxthwden5te0wfjkccte9eekummjwsh8xmmrd9skctcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs2juazd grant for interoperability testing. Denied. No one is going to be the janitor of nostr for fun, it's a pretty much the worst kind of coding work, even though it'd super needed, they don't want it.
On super apps, checkout the browser in nostr:nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qnse3k pretty epic. Built in wallet and secure chats. once they get notifications working on graphene without Google services, probably will use it way more
I dont believe music on nostr actually happens on nostr. It happens on rss and is distributed and discovered over nostr.
We dont need a nostr janitor as its downstream from RSS. RSS has been a standard thats been reliable for decades. No need to recreate the wheel. They've already got plenty of janitors.
We simply need bots and other programmatic triggers so when things happen in the RSS world, they get automatically noted and bridged to nostr. Plenty ofnpeople have been making music kinds - use those by parsing the rss feeds for metadata. Its a goldmine, seriously. From there people can pull endless other automation and integrations.
I did all of this on nostr without RSS. The only thing missing is zap splits. Currently not possible easily without NWC, but I think we could make progress on this if some smart minds come together at lightning protocol level
I 100% appreciate your efforts and will continue to support however i can.
But the reality is nostr native music content is sparse. Whereas there is a massive library waiting and growing on RSS and its foss tech. Yes you can do it without, but... why?
Splits are a deal breaker as well imo. From a music professional pov, if it cant simply handle native auto splits, its a non-starter. They are essential.
Itās not native in RSS either - those splits are done on someoneās server. Itās not permissionless. We actually do have splits but currently with NWC
Im mostly tech agnostic but i very much understand whats happening under the hood. If it works for the intended audience or use case then thats where I go.
The RSS splits are absolutely permissionless if you're running your own node and hosting your own files.
If you're not, we'll its no different than having a custodial lightning wallet (it literally is that).
The RSS feed simply has a text file with a tag to a lightning or node address. If you self host your feed (on any server) as well, then everything you are doing is 100% permissionless.
If you're talking about the payment rails being used, thats lightning network. Keysend vs lnaddress vs whatever else is a bitcoin lightning problem, not an rss issue. RSS (or more accurately DeMu) uses both keysend and lnaddress but its a bit of a mixed bag of semi compatibility so admittedly not a perfect situation either.
How many people do you suppose will run their own lightning node ā¦
Very few. But i have no problem with that. I dont believe most people in the world will be their own bank when hyperbitcoinization hits. I have no belief this happens in music either.
But I respond as such because you characterize RSS disengenuously similae to as if you said all lightning was custodial. Yes custodial flavors exist, but there are also 100% non custodial options too.
For the record, not every boost running through DeMu is fully decentralized and super based blah blah blah. I dont care. I believe custodial options are necessary too. What i care about, is the option to be fully 100% self sovereign exists in this ecosystem IF i want to put in the PoW to learn to do it. The tradeoffs you make are your choice. That's real freedom tech in action.
If you're talking about hosting non wavlake or fountain, then yes, agreed those splits are not permissionless if you're using their wallets or hosting your feed on their server.
Thats sorta how it works by definition... If you chose a permissioned option in your workflow then the whole workflow becomes permissioned.
But if you dont... and only chose permissionless sovereign options in your stack then... youd be permissionless.
Guyputsstickinbikewheel.meme
I think im unclear when I say native auto splits. My bad on that. I shouldn't have used native.
What i mean is: the ability to input my own splits, have the ability to update them permissionlessly at any time, and for them to be broadcast and globally updated automatically everywhere with reasonable assurance that every client playing my audio has the updated splits.
You can do this with Nostr. Replaceable events make it possible.
What's the implementation look like?
Playing contrarian, id be concerned if someone is not connected to one of my relays, they might not get the update (like how follower count is not accurate).
Are replaceable events backwards compatible? Both the relay and client would have to support them to see anything right?
Nostr by its nature is probabilistic. You donāt really know if the latest version of a replaceable event is truly the latest but there may be ways to reduce the likelihood of on old / stale event. Iād be talking out of my ass if I pretended to know how to do this well but I do believe there are ways. The most important is multi-relay publishing at the time of event signing so you query multiple relays at client level and reconcile them to select the latest event. You can probably also add relay hints to events themselves - but Iāve never done this.
Seems to me a Nostr event can be the canonical publishing if and only if we get the content delivery to be resilient (something like IPFS or torrents)
Then interoperability with RSS and then youāre bulletproof for self-publishing audio and video
Anyone can develop the clients and publishers can hit all of them at once
Maybe a simpler answer is pointing to a cdn in the kind zero like we do with lightning addresses. Then having a schema where notes reference hashes instead of full URLs, so you can swap a new CDN and all the old notes still register
One major hurdle that is a non-starter is ability to edit and ensure all end users are being delivered the most up to date version every time. The uploader must have control over a universal truth "current" copy. I believe this is difficult over nostr because of the relay model. Maybe not impossible but whatever is being explored needs to be absolutely certain it first answers the problem of editing files and all end users being delivered the correct latest version.
Correct latest version of the av file or of the kind zero?
Iād actually prefer if you couldnāt swap the file once itās been published
Think about it like this - your kind zero lists a primary blossom server. Notes reference the file hash. Basic Clients take the file hash from the note and pull it from the blossom server mentioned in the kind zero. More advanced clients can search a lot of blossom clients to find that hash.
Thereās no reason the kind zero canāt mention multiple blossom servers in fact (mirrors)
Because the hash is used, no user will be served an incorrect file. Because the kind zero can be updated, broken links can be fixed without breaking the original published note
This even allows for authorship metadata in the original file to point to the npub for making sure the right publisher is Zappable no matter how you got your hands on the file
The use case is as follows. Real life example: uploaded a track. Turns out, there was a minor error in the mix and uploaded finalv2 instead of finalv2forreal. Everything's been published and suddenly we find this error. Now we need a new audio file.
Another scenario - feed is published. New band member joins. As part of their deal, they get a minor cut of back catalog. Now we need to update splits (presumably this metadata is saved in the kind zero?).
Hmmm these are cases I wasnāt thinking of. Iām thinking as publishing video content, like a film. A canonical publication seems ideal.
An even simpler solution to resiliency would just be a āmirrorā note kind. This offers an alternative link to the shared media. If the original note has the hash, this can prevent mismatched mirrors.
Does RSS handle mirrors? I donāt know enough about it
So RSS is simplicity in action. RsS is literally a huge text file full of metadata. It contains tags, which can be created at whim. The only pseudo-requirement is consensus. If other ppl use it, its a thing. If youre the only one, then it isnt. Sorta like publishing a kind, but easy like making up a hashtag. When you hear someone say PC2.0, it really refers to the generally accepted namespace. A tag can be anything like "artist" or "splits".
To answer your question... since all you're doing is putting the source location of the audio file next to the appropriate tag, id imagine that if its a printable address, it can be permalinked in the feed. If you need to change the link, thats a quick change in your txt file.
But I didnāt answer your question - I guess additional notes for ārevisionā or āsplit updateā would be necessary and you just run the risk that the end user doesnāt get those updates in whatever they pull from
I still maintain that trying to do the whole system on nostr is an unnecessary overcomplication. There are certainly benefits but they dont outweigh the ease of use. Remember... these are things musicians need to be able to do on their own (notoriously non techie).
And thats not even to say... all else held equal, RSS has an existing library of thousands of high quality tracks. Nostr native tracks... does that even exist right now? What is that even defined as?
I like nostr as a downstream layer from RSS. Let the existing freedom-oriented structure handle the primary plumbing. Its more efficient to create nostr bots that watch RSS and the podcastindex and publish notes and updates that are nostr-native formatted based off the standardized metadata tags and associated data. This would be a cool use case for an LLM potentially. There can be a lot of data co tained in a single feed. Everything from lyrics to album art and credit.
So the thing is RSS already solves this. I simply change the address on my feed, hit save, and it updates across any and all feeds that also reference my feed.
I dont understand why we have to shoehorn nostr into all of it. It has a really amazing use-case. It just needs to plug in to the existing tech.
I think the difference Iām suggesting is being able to publish without permanently maintaining anything. With RSS, someone can actively archive your files and update and publish a new RSS, yes
With what Iām saying, the notes remain the source of truth, so an archivist would just need to host the files on a discoverable CDN, not republish a feed.
The original author could add more CDNs to their kind zero, and the original notes still work. No replacing the notes, no replacing the files, just propagating verifiable copies of them
I see (sorta). But if IP protection is the goal, im not sure how this fully solves it either? Yes they cannot pull directly from the feed but as soon as they stream they can record. What would prevent someone from duplicating a feed that way?
On the flip side, a large part of the ecosystem involves dj's playing their tracks. If it can only be streamed, that limits things that can be done creatively on the broadcast side.
The CDN idea is good for setting a static address without doxxing the source location (pls correct me if im wrong). While that can be useful, I dont think its solving the right problems. IMO we dont need to lock down the audio files. Music is collaborative by nature. We just need to ensure artists can be tipped anytime their music is heard.
You could do all the fancy hashing and cdn lookups but i think thats still overcomplicated. There's no need to push the metadata or file hosting onto relays. All the relays need is the guid of the feed (its in plaintext, can't miss it) and the apps just need a library or template or git so it knows how to decode the tags. But I digress... it's self hosted and thats the key.
If you want it distributed, put it on a blossom server and literally ctrl+v that in your RSS (a text file). Done.
The hashing is the only way to make sure the right file is served from whatever server and that links donāt permabreak
