Feed readers are useful for keeping up with people's posts wherever they post, especially their own site. To further the goal of empowering individuals to post (and read) on the indieweb, it makes sense to develop indieweb-design-centric feed readers which address the limitations with legacy feed readers.
See: reader for current work on integrated indieweb readers.
- Bloglovin - web-based feed reader site
- Feedbin - paid, hosted + open source reader
- FeedHQ - Open source, hosted option available
- NetNewsWire - Standalone application for OS X
- Nextcloud News
- Owncloud News app - Open Source Owncloud application with a web frontend and an API
- Reader Self
- selfoss - Open source web RSS aggregator/reader
- TinyTinyRSS - Open Source with a web frontend and an API for external clients
- Minimal Reader
- ... other feed reader examples that community members have used (or are using)
- Google Reader (shutdown in 2013)
Fails to aggregate if not open
Email servers receive and collect your email for you regardless of whether you open your email program or not, whereas legacy desktop feed readers on the other hand typically DO NOT collect/accumulate posts from feeds you're subscribed to while you're not using them — this is not the case for hosted services, or native apps which sync with them.
Lack of publishing integration
Standalone feed-readers have for the most part been superseded by the much nicer overall UX of integrated read/post UIs as exemplified by Facebook and Twitter, where you can read, publish, comment, repost, like, RSVP and so on in one place — more and more users have switched to using these silos as their "aggregator" instead of aggregators that actually pull in content from around the web. This trend was one of the motivations behind the deliberate development of POSSE as a way for indieweb sites to stay in touch with their friends/users/readers that prefer to use silos as their primary aggregrator.
There was a proposed RFC (4685) "Atom Threading Extensions" that went unimplemented. However it introduced an "in-reply-to" element which was latter adopted as the simpler rel-in-reply-to for HTML. See in-reply-to for details.
The defunkt Google Reader had a way of "starring" posts, which then showed up in their own feed, but this interaction was local to the reading interface rather than pushed out to the original content.
On the indieweb, replying is done by creating a reply post on your own site that links (with rel-in-reply-to) to the permalink of the post you're replying to, and then sending a webmention to the post's webmention endpoint.
Whereas many social medias focuses on a continuous content stream, feed readers are instead often designed around an inbox, with unread counts and sometimes even sub-folders. The focus of such an interface is to read it all, whereas the focus of the continuous content streams of social medias is on getting a good snapshot of the moment.
As continuous content streams isn't concerned with an unread count or with giving a good overview of of the content left in the inbox they can provide a simpler interface where content can often be displayed fully inline in one large, infinitely scrolling list.
The inbox focus of many feed readers also means that they are often more concerned with what content they have received from whom rather than why they have received that particular content. The continuous content streams of eg. Twitter and Facebook on the other hand also makes it very clear of why you have received a piece of content – if it's because eg. someone liked it, reposted it or simply created it themselves.
Post Google Reader Readers
Since Google reader shut down, a number of independent projects have taken off. They primarily reproduce the Google Reader experience and a few are experimenting with new feed reader concepts. Because Google Reader was a hosted service, most of these projects are offered as paid, hosted services and promote this as a sustainable model for development and maintenance. If you use any of these post Google Reader readers, please document your experiences.
There are different opinions on "what is an aggregator", feed reader, site with public URLs copying content from elsewhere (like a planet), etc. Dumping these here because they were in business-models but none of them actually make money from aggregating:
Aggregators are a way to read (sometimes disparate) content in a single place. Aggregators can be silos, or can be open.
Aside from just distributing content, aggregators can compete on things like speed, user experience, etc.
From most indieweb-web friendly/encouraging to least:
Pure aggregators (no primary content, all content and comments are aggregated from around the web)
Content aggregators (aggregate content from around the web, primary hosting of comments only)
Hybrid aggregators (aggregate content from around the web as well as primary content posts hosted on their silo)
Silo aggregators (aggregate only posts in their own silo)