Nostr Web Client

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?).

mrclownworld 0mo ago

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

Reply to this note

Please Login to reply.

Discussion

BITwise 🐳 >>= RIGHTish 0mo ago

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.