RSS has solved this (not saying their isn't a nostr solution as well).
https://lnbeats.com/album/287e27fa-adc5-4762-956f-0282bba5ed77
Here's a playlist nostr:npub15z2javq62eh2xpms7yew0uzqsk4dr7t3q3dq4903uuxdyw2ca3kstx6q95 put together of every song he's ever played on Lightning Thrashes. I'm currently working on the ability for you to save your playlists as an RSS feed to share with anyone. If you want create your own playlists, Sovereign Feeds is what Sir Libre used to build his feed and then he hosted it on his own server.
The issue with saving a playlist as an RSS feed is that I have to have a domain, and a server, and a https certificate for that server, and...
Where as if it was a nostr event it could just be signed and published to a relay
neither option is better UX for new users. but for existing users (and myself) its much easier to create and manage nostr events then it is to manage RSS feeds
So I'm trying to understand the mechanics of nostr. Doesn't nostr need servers to work as well? Like a relay is just a websocket server right? And to connect to the server I need to know the domain or ip address of the server? Like doesn't wss://relay.damus.io/ need a valid HTTPS/TLS certificate since it's working on wss? And doesn't it have a domain, which is damus.io?
yes, however the difference is as a user I can use other users relays. I don't have to have my own relay to make my events (data) available. whereas for RSS I need to have FTP access to my server. or a friends server that is configured with my domain
I like these discussions because it gets me thinking about new ideas. I actually think saving a playlist as an RSS feed is the solution. RSS works for podcasting, and all the players know how to read the feeds. But, what if the players had another way of fetching the feed, like over a websocket. Right now, the feed is known by url. But what if it was also known by its event ID?
We could keep the underlying mechanism of RSS to send a file from a central server on the podcaster's chosen domain, but we can also broadcast the updated RSS feed to any RSS relay, and those relays can also store the feed. Put the eventID (or whatever the proper nostr term is to fetch a file and broadcast it) in the feed, so now when someone subscribes to the feed, they have the nostr id to find the feed from the RSS relays. It's backwards compatible with legacy podcasting, still uses a 20 year proven method, and updates the delivery mechanism so it's more reliable by having many points of fall back. Any podcast player can easily be updated to subscribe to a relay to fetch the latest updates to a feed, so it would also work with legacy players with very little update to their code.
