Open arkin0x opened 2 months ago
pablof7z
commented
2 months ago If you want to save some bytes, you don't need the full content inside the XML. You can just add the event id, pubkey and relay hint. You can event put the nevent1.. in the XML instead of the 3 things.
was here to say this
I think having the nevent with either relay hints and/or author or event ID + author pubkey would be the way to go
fiatjaf
commented
2 months ago This is kinda useless. What podcast player will verify this and why does it matter anyway?
Isn't it much better to just publish the podcast directly on Nostr and have podcast players fetch the feed directly from relays instead of expecting them to fetch everything from RSS but then have a full-blown Nostr client embedded in just to check for something no one is interested in checking?
arkin0x
commented
2 months ago This is kinda useless. What podcast player will verify this and why does it matter anyway?
Isn't it much better to just publish the podcast directly on Nostr and have podcast players fetch the feed directly from relays instead of expecting them to fetch everything from RSS but then have a full-blown Nostr client embedded in just to check for something no one is interested in checking?
FanFares is using this in our v2.0 dev build to implement nostr features on top of RSS, like enabling an npub to add gated kind 31338 episodes into their existing list of episodes, publish official text updates on behalf of the podcast with their npub, highlight fans who have left positive reviews, and more. Without a way to verify an npub owns a podcast, you can't definitively associate an npub's nostr content with it.
Right now the only practical way to find existing podcasts is to depend on a centralized API like podcastindex. While podcastindex is great, announcing podcasts in events allows for clients to discover podcasts via nostr.
FWIW Fountain, npub.pro, and FanFares all think this is a good idea. Ask @MerryOscar and @brugeman , we've been talking about this.
fiatjaf
commented
2 months ago There are only two possible reasonable alternative futures:
You are trying to push for an unreasonable and suboptimal future that
a. still requires podcast players to know about Nostr, care about Nostr, implement a Nostr client, verify signatures; b. doesn't get any of the benefits of having podcasts be published on Nostr.
Therefore this is at best a waste of time, at worst a weird standard that will confuse other podcast players when they see it because they will think Nostr is some kind of useless and heavily bloated identification scheme that requires multiple websocket connections just to check a signature that no one cares about.
I'm happy that @MerryOscar is trying to push the podcast world into Nostr, but I feel like having a mode that fetches podcasts based on Nostr directly from relays instead of from RSS is both easier to implement and cleaner, better and more useful than this in the long-term.
arkin0x
commented
2 months ago Your point 2 above is literally accomplished by this NIP, with the one distinction that most podcasts continue to live in RSS. But enabling new forms of interaction only possible with nostr are the whole point of this NIP. It's a bridge between decentralized protocols.
Ask a podcaster to give up their RSS feed and switch entirely over to some other thing and you'll quickly learn what an unreasonable and suboptimal future is in the eyes of the people whose opinion actually matters on this — podcasters.
Podcast apps that are non-nostr are not relevant to this conversation. Normal podcasting 2.0 apps are unaffected while nostr-based podcast apps get extra features and benefits. In the long term this makes Nostr-enhanced podcasts more desirable and hooks into network effects without the entry price of "sacrifice podcasting 2.0".
I get that you want to replace RSS with nostr but that just isn't going to happen. But we can offer a better and more desirable experience for podcasts and their communities on nostr. This is a reasonable middle ground that lets podcasters benefit from nostr and keep their RSS feed. Ultimately, if nostr provides better features for podcasters than they can get with RSS alone, then that is great for the nostr network adoption.
For nostr to grow, it doesn't have to kill other good decentralized standards like podcasting 2.0. It should interoperate.
staab
commented
2 months ago I think having the nevent with either relay hints and/or author or event ID + author pubkey would be the way to go
I would even go so far as to only include an nprofile (or hex pubkey and relay hint) since clients will know to look for a kind 1338 if they implement this nip.
Also, fiatjaf is wrong about podcasts, don't listen to him.
fiatjaf
commented
2 months ago I get that you think RSS is eternal and will never be replaced, I don't get how you think we can replace Twitter, Telegram, Facebook, Instagram, Discord Tiktok and everything else, but RSS somehow is a sacred rock that can't be broken, but fine, let's assume it is. That just brings us back to point 1.
But I won't complain anymore.
Also, I'm all for enhancing the RSS experience with Nostr while it exists, that just doesn't seem to have anything to do with this NIP.
mikedilger
commented
2 months ago Podcast software will need to continue to use RSS to handle existing podcasts for the forseeable future.
If we want to have nostr involved in any way, the question is "what is the best way?" Podcast apps will need to be modified with nostr code, let's just modify them once. The options appear to be:
1) use a nostr event that verifies the owner of a podcast (this PR) 2) put the podcast onto nostr entirely (fiatjaf's option 2), but also into RSS separately for the masses that aren't using these enhanced apps.
In either case, only the nostr-enhanced apps will have the increased functionality, AND the nostr-enhanced apps will need nostr-specific code to be added AND the podcast data will have to be found somewhere (either RSS or nostr or both).
I don't see much difference.
arkin0x
commented
2 months ago I get that you think RSS is eternal and will never be replaced, I don't get how you think we can replace Twitter, Telegram, Facebook, Instagram, Discord Tiktok and everything else, but RSS somehow is a sacred rock that can't be broken, but fine, let's assume it is. That just brings us back to point 1.
The key difference between RSS and Twitter/Telegram/Facebook/Instagram/Discord/Tiktok is that RSS is a decentralized protocol and the rest of those are platforms. Yes, nostr could indeed replace RSS. I would be in favor of that. Nostr could replace everything, centralized platforms and protocols alike, but I think that taking down centralized platforms is an obvious win and way more feasible than replacing other well-established decentralized protocols like RSS.
I'm fully open to a future where nostr replaces RSS and this NIP does not preclude that. I am just trying to meet people where they are at and build something that can work right now. Podcasters use RSS. Let's show them how nostr can make it better. And someday I hope nostr eventually becomes the superior and preferred podcast publishing medium.
Now as far as the implementation is concerned, I see what everyone is saying about using an nevent or nprofile. But why do we have to make it more steps to complete the verification?
Include the whole event: 3 steps
Include the nevent: 5 steps
Include the nprofile: 6 steps
Keep in mind podcast clients would likely check this for every podcast in the UI so extra steps matter (although they should plan to cache the verification results).
If you want to save some bytes, you don't need the full content inside the XML. You can just add the event id, pubkey and relay hint. You can event put the nevent1.. in the XML instead of the 3 things.