Nostr Web Client

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.

mrclownworld 0mo ago

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

Reply to this note

Please Login to reply.

Discussion

BITwise 🐳 >>= RIGHTish 0mo ago

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

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

BITwise 🐳 >>= RIGHTish 0mo ago

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.

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

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.