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.
Thread collapsed
Thread collapsed
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.
Thread collapsed
Thread collapsed
Thread collapsed
