# Feeds are Still Cool (created Apr 9, 2018) By feeds, I'm referring to syndication, such as and Atom feeds, which are based upon XML, the Reece-Simmons JSON Feed spec, released in May 2017, and the IndieWeb's h-feed format, which is an HTML page, marked up with MicroFormats to identify h-entries. => http://www.rssboard.org/rss-specification RSS => https://jsonfeed.org => https://indieweb.org/h-feed => http://microformats.org/wiki/microformats2 => https://indieweb.org/h-entry The advantage of h-feed is that since a website is already producing HTML pages, why not make the feed file an HTML page too. For some IndieWeb bloggers, their feed file is their homepage. The disadvantage is that only a couple of feed readers, produced by IndieWeb users, support h-feed. Multiple feed readers, however, added support for JSON Feed in 2017. I use The Old Reader as my feed reader. It's web-based, which means nothing to install, and obviously, I can use it on any internet connected device that contains a web browser that supports JavaScript. => https://theoldreader.com My post: => /2018/04/03/feed-reader-the-old-reader-supports-json-feed.html The Old Reader supports JSON Feed I like The Old Reader because it's simple and easy to use. I've briefly tried other feed readers, and they seemed too busy with too many features. XML and JSON are meant to be produced and consumed by computer programs, but sometimes, I like to view the output, especially when debugging JSON-REST API code. In my opinion, "pretty" JSON is easier to read than XML. I use XML in my web publishing apps that create RSS, and sometimes, I need to consume RSS/Atom feeds in my other apps and utilities, such as ToledoWX, which is used to power my weather website toledoweather.info. => http://toledoweather.info toledoweather.info It's also now located at my Gemini site. => gemini://sawv.org/tolwx ToledoWX app needs to consume RSS data from the Storm Prediction Center and custom XML or Atom-based alert files, produced by the regional National Weather Service offices. The NWS offices also produce a large custom XML file that contains a lot of current weather data, including forecasts, but a JSON version also exists, and I use the JSON option. Whenever possible, I choose JSON over XML. In Perl, NodeJS, and Lua, it seems easier to work with JSON than XML, mainly because JSON text easily translates to objects, hashes, and arrays within the programming languages. Whether the feed format file is XML, JSON, or HTML, the key point is that syndication feeds are still produced by many websites and consumed by users with feed readers. When Google shutdown its popular reader in the summer of 2013, that opened the door to other existing feed readers to improve their products and for people to create new feed readers. Blogger.com and Wordpress.com automatically produce feed formats. Authors, however, may not realize that their CMS providers are creating these syndication feed formats. And authors probably have no idea that some readers consume their posts in feed readers. I don't care if only a snippet of a post appears in the site's syndication feed. Some feed reader users expect the entire post to appear in the feed. That way feed reader users can read the entire post within the feed reader, without needing to visit the author's website. Personally, I like visiting websites. Some formatting may not appear within the feed reader. Within The Old Reader, I focus on titles. I collapse the rest of the content for a post. I only need titles and the URLs to the posts. If the post lacks a title, then The Old Reader uses the first X-number of characters of the post as a title. That's fine with me. Based upon the title or the first sentence or so of a post, I can usually determine if the post is interesting to me. I dislike vague titles and posts that take forever to get to the point. I don't care if the feed reader supports title-less posts properly, according to the RSS spec. First of all, the feed format might exist in Atom or JSON Feed format. Dave Winer helped to create and define the RSS spec, and it's understandable that he might be adamant about feed readers displaying titleless posts properly. => http://scripting.com/2014/04/07/howToDisplayTitlelessFeedItems.html DW's Apr 7, 2018 post: => http://scripting.com/2018/04/07.html#a154555 > I generally don't like to look at how mailbox-type readers render this site. The best I've seen are ones that ignore titleless posts. At least they don't show the reader a mangled version of my writing. **Then there's the ones that repeat the body of titleless posts in the title.** So you see my writing twice, as if I had a stutter. It's not my stutter, the text only appears once in my feed. **Readers that get on board with titleless posts are helping to open the door for new kinds of blogging.** I've chosen to ignore their ignoring and just plow ahead. I don't understand why it's important for feed readers to display titleless posts properly, whatever "properly" means. Who cares? > ... repeat the body of titleless posts in the title ... That is how The Old Reader functions, and it doesn't bother me. I'm not losing sleep, nor am I getting cramps in my calf muscles. When it repeats like that, I assume that it's a "note" type of post. I'll refer to the IndieWeb's definitions. => https://indieweb.org/note > post that is typically short unstructured plain text, written & posted quickly, that has its own permalink page. Though unstructured meaning without a heading/title or any other explicit structure, notes can include several lines of text or even lists using "*" or numerical markers due to common whitespace support. => https://indieweb.org/article > post that typically has more structure than a simple note. Articles usually have a name (title), multiple paragraphs, and often subheadings, blockquotes, and a footer of references or citations. In my web publishing apps, I define a title as the post beginning with either the single pound sign, indicating Markdown markup will be used or beginning with `h1.`, indicating Textile markup will be used. Since the post has a title, then my code considers it to be an article. If the post fails to start with either of those two formats, then my code considers the post to be a "note" type. About the only reason for the difference for me is which template to use when creating the HTML. Mostly, I consider all content to be web pages or simply "posts". Many IndieWeb users define a dozen or more different post types for their websites. That's too complicated for me. They use MicroFormats to specify the post type. Since only a tiny fraction of a tiny fraction of all internet users use a feed reader, I'm indifferent about articles and notes and how they get displayed in a feed reader. As long as link exists in the feed reader, then I'm good. Instead of worrying about how feed readers display titleless posts, it might be better to encourage more information consumers to use feed readers. I tend not to consume media orgs in my feed readers, since media orgs produce dozens or even hundreds of posts per day. I prefer to follow individuals who post infrequently. The Toledo Blade is about the only media org that I consume in The Old Reader. I'll try other media orgs for a while, and then I drop them. But most major media orgs offer syndication feeds. Email newsletters might be a better way to consume media orgs that produce a ton of content. I like the Politico's Playbook email newsletter that gets sent each morning. My email newsletter subscription increase and decrease too. I'll try new ones for a while, but I'll unsubscribe when I realize that I rarely read them. It all can add up to too much information. That's why I like visiting websites directly, recalling the URLs from memory or by clicking the URLs that I store on a bookmarks page. => https://techcrunch.com/2018/04/07/rss-is-undead That TechCrunch post is the dumbest article that I have read thus far in 2018. It's shocking that it appeared at TC, which is supposed a media website that covers technology. But maybe it's not surprising. The dumbest thing that I read in 2015 was this article about using the web on mobile devices that was written by The Verge, which is also an alleged tech media site. => https://www.theverge.com/2015/7/20/9002721/the-mobile-web-sucks The TC author who wrote about RSS lists negatives about RSS and ideas about how to improve RSS, but his suggestions are senseless. His negatives are the positives for everyone else. His negatives are the reason why people like RSS. Since the author writes for a for-profit media org, I assume that he's a journalist, and that's why he views RSS from the viewpoint of advertising, analytics, discovery, prioritization, and other absurdity. That lack of those annoyances are a positive for syndication feed formats. Naturally, the author likes to define success by comparing feed reader usage to the number of Facebook users. This kind of comparison shows the lack of true technical intelligence among media orgs. These journalists probably never wrote a program that produces or consumes a feed. The TC writer mentions the overwhelming amount of information that exists in feeds produced by media orgs. Duh. Many media orgs produce dozens or hundreds of stories a day per media org. Content mills. That's why I focus my feed reading mostly on individual publishers who post infrequently. I focus on the areas that interest me. If I want news, I can visit media websites directly, such as: => http://toledoblade.com => https://text.npr.org text.npr.org I visit Hacker News, since HN is an aggregator message board. The comments can provide better info than the article that the thread starter post linked to. => https://news.ycombinator.com Success is the fact that since enough people around the globe still use feed readers, then developers continue to build new feed readers and update existing feed readers. I do not consider the people behind Inoreader, Feedly, The Old Reader, etc. to be failures. => https://www.inoreader.com => https://feedly.com These are businesses. Other feed readers are open source projects that anyone can install on a local machine or on a server. Some feed readers are desktop and mobile apps. But the media views the social web through their blinders. 300 million Twitter users is smallish to journalists because the media compare everything to Facebook's two billion users. If some app, service, website, or idea does not have at least 100 million users, then it's obviously a failure. Related HN thread that currently contains about 200 comments. => https://news.ycombinator.com/item?id=16785335 Anymore, I consider "RSS" to be an umbrella term that means syndication feeds, produced in XML, JSON, and HTML. The feeds don't have to be RSS to be consumed by feed readers. RSS, however, might be simpler to create than Atom, and since podcasts rely on RSS, this could all add up to make RSS the more popular format. Encouraging more people to post on their own websites, located at their own domain names is more important than syndication formats and feed readers. That latter needs the former. Hopefully, the authors use CMS tools that produce syndication feed formats. Many authors of personal, independent websites also offer email newsletter subscriptions in addition to or as alternative to syndication feeds. A reason for this is because more people have email accounts than feed readers. Not everyone, however, likes mixing feed subscriptions within email. For website authors, it might be a good idea to offer both email newsletter subscriptions and syndication feeds. It might also depend upon the audience. A more info-savvy or tech-savvy audience might like consuming syndication feeds. A non-tech-savvy audience might be better served with email newsletters. HN comment from December 2017: => https://news.ycombinator.com/item?id=15675823 > I wrote about this recently. The "problem" with RSS, that essentially lead to it falling out of favour, is that it is pure consumption, not interaction. You can't "like" an update that comes to you via RSS, nor comment, nor easily share. In the IndieWeb world, that last claim is false. A couple IndieWeb-featured feed readers permit liking and replying to posts from within the feed readers. The feed readers act like MicroPub clients. This requires the feed reader users to maintain personal websites that support MicroPub on the server. The reply post gets created on the users' own websites. Their websites' CMS apps process the incoming post from the feed readers and determine that the posts are reply posts, meant for to other websites. Then their website CMS apps send Webmention replies to the other websites. That's how it's possible to reply or like a post from within a feed reader if IndieWeb.org tech is used. The Old Reader and most mainstream feed readers don't support IndieWeb tech. Even if it was possible to reply from within a feed reader, using IndieWeb concepts, the site on the other end must support receiving Webmentions. => https://micro.blog micro.blog might be viewed as somewhat like a feed reader. I follow other micro.blog users. Their content is either created directly at micro.blog, or micro.blog imports their content from their own websites, via RSS or JSON Feed. And when a user creates a reply post at micro.blog to one of my posts created at sawv.org that was pulled into micro.blog via RSS/JSON, then micro.blog posts the reply into my stream or timeline at micro.blog, and micro.blog also sends the reply as a Webmention to my website. Pretty cool. => https://indieweb.org/Webmention => https://indieweb.org/MicroPub => https://indieweb.org/indieauth Microformats are helpful or required to make these interactions possible from within feed readers. One of my favorite posts to read in 2017 was created by IndieWeb supporter Chris Aldrich, titled "Feed reader revolution." => https://boffosocko.com/2017/06/09/how-feed-readers-can-grow-market-share-and-take-over-social-media/ > It's time to embrace open & disrupt social media He discussed how the social-like interactions would work and do work from within feed readers that support the IndieWeb concepts. But it's all optional. Some users have no interest in replying to nor liking posts that they read in their feed reader. The other part of the above HN comment, regarding RSS: > It's difficult for sites to monetise it, or track, or promote their own agenda. It's not "social" and since every other site these days needs to be social, whether through aforementioned ways, or adding some sort of messaging process, it's not a way that sites can keep users hooked on the site to boost ad impressions. > > RSS is pure content, curated only by the consumer and presented in chronological order not algorithmically messed with, which is why there's nothing better. Reply comment: > Yup. RSS is exactly what it say it is. Nothing more. Nothing less. And in that simplicity is a tool that just works. No wresting with authenication. No "oh shit they updated the API." None of that. Another HN reply: > Couldn't agree more. RSS is just about content. It's up to the feed reader to provide interactions, e.g. w/plugins allowing to ping back authors/original URLs in order to create a kind social network. I don't think such a business logic would have to be implemented in RSS for it to be successful. Separation of concerns rules. Good post mentioned in the above HN discussion. September 2017 - leejo.github.io - "Social Media Zero" => https://leejo.github.io/2017/09/27/social_media_zero ### July 2019 update I have been accumulating RSS-related links here. => gemini://sawv.org/rss.gmi Last summer, I discovered and implemented the jokey RSS 3.0 spec at my Sora test site. => gemini://sawv.org/2018/08/21/rss-30-jokey-but-useful-spec.gmi => http://sora.soupmode.com Example RSS 3 feed: => http://sora.soupmode.com/rss3.txt -30- ``` dir : 2018/04/09 ```