Thanks! I just offered some thoughts on your proposal, [PIG] Enhancing RSS podcast feeds by using OAuth to access exclusive content - #4 by swaldman
I think you should absolutely supply the metainformation you are supplying in your JSON feed format in RSS, by defining a namespace for it. That’s RSS’ secret sauce. You can just do that. You don’t have to ask anybody, and it’s not a big deal. It doesn’t break anything. Your content shows up in any standard feed reader no matter what, but if you can demonstrate that the extra meta information you provide is useful, some feed readers will begin to pick and choose elements to support in their UI. If users, even some enthusiastic niche of users, love the enhancement, more readers will add more features, and people might even write specialized clients for comics, and voila, you’ve invented the new podcast.
Podcasts are an example of RSS-first applications, de facto.
Initially websites were the applications (even for podcasts), and RSS feeds just announced new updates. But over time and with extra metadata, podcast-specific RSS clients (which we just call Podcast apps) eclipsed podcast websites in beauty and usefulness, and now the website is just a kind of stub or backstop if it exists at all. Whatever the status of the website, since it’s still basically RSS at its core, podcast episodes and show notes and mp3 links are always part of the open web, accessible via any RSS reader.
If you embed rich comic metadata in RSS, and over time users come to prefer specialized feed readers that render them beautifully thanks to that metadata, but the important heart of the content remains accessible as standard RSS in any reader, then you’ll have made comics an RSS-first application. People will publish comics primarily in your extended feed format, rather than as a website that just uses feeds to announce updates so that users come visit the website. The feed item becomes the canonical content.