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

Replies (3)

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?
hzrd149's avatar hzrd149
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
View quoted note →
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.
hzrd149's avatar hzrd149
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
View quoted note →