@anildash We need that radical openness that podcasts have across mediums. It is the purest gatekeeper-free medium that we have; we need to duplicate it.
@anildash We desperately need an RSS-like medium for written content, but with respect for formatting and branding.
To me, I think the reason why audio has long remained the perfect object for the medium of podcasting is that an audio file can’t be modified. It’s delivered as the creator intended.
I think email won the war for newsletters because it does a better job respecting the “as the creator intended” truism than RSS does.
I’m sure people will push back on this POV. But it’s so obvious.
@alcinnz@ernie the point is that iterating the format also necessarily updates expectations for client apps, instead of a piecemeal voluntary set of improvements.
@alcinnz@anildash The best comparison I have is that I want to see someone take the parts of Google AMP that were a good idea and combine them with the good parts of RSS.
@alcinnz@anildash I think RSS deserves an update that allows publishers more control over the experience, but also isn’t stuck in the backwater of 25-year-old email markup.
@alcinnz@anildash I think you’re misunderstanding what I’m asking for.
I’m saying content should be presented as a single piece, exactly matching the creator’s intention, with design. I basically want to see a format that presents information similar to a newsletter.
RSS feeds are often neglected, even forgotten by publishers, because they do not make them money. We need a higher-end publishing format that allows publishers to better control how they present themselves.
@ernie@anildash Again: I don't see any lack of uptake amongst publishers. But what you're complaining about is an issue with many, not all, feedreading clients.
I see the issue as being with a promotion of feedreaders, most people don't know the tech exists.
@alcinnz@anildash The problem is not with the format, it’s what the format does for the creator or publisher.
You can make a living on a podcast because you often shape how it’s distributed and what it includes. You often cannot make a living on an RSS feed, because the content is untethered from things that allow for business models.
@ernie@andy I think the technical way of talking about this would be a define profile of Atom that you specifically want clients to support. And then the trick is figuring out the incentives nad rewards for everyone embracing that subset of the format. (This is how OpenID evolved into being useful.)
@andy@anildash I think this is actually why you want to build a new version or scheme from ground up so everyone is on the same level. It’s sort of like, what’s the point of adding something like this if readers don’t support it?
@ernie@anildash the Atom format supports including HTML as the format type, so you could maybe get there? But I really don't know how the various readers respect that.
> If the value of "type" is "html", the content of atom:content MUST NOT contain child elements and SHOULD be suitable for handling as HTML [HTML]. The HTML markup MUST be escaped; for example, "<br>" as "<br>". The HTML markup SHOULD be such that it could validly appear directly within an HTML <DIV> element.