On the other hand: the developer became, or revealed himself to be, a nastier and nastier person (or adopted such a persona) each year. It was clear to me that he didn't like dealing with fools and considered everyone with a different technical opinion to be a fool.
I will go look for another Google-Reader-like selfhosted RSS server when I have to.
I wasn't around for Google Reader so I don't know how Google-Reader-like it is, but Miniflux has been quite pleasant to use for the past 2 years with the caveat that the only supported database backend is PostgreSQL.
I have 369 feeds right now, in 20 categories plus the Uncategorized dump that I occasionally sort through and re-assign. 8 feeds in there now.
I want -- and Google Reader, TheOldReader, and TT-RSS enabled this -- to click on a category and see the individual feeds, then click on a feed and see it as headlines-only in chronological or reverse chrono order. (I want different feeds in one or the other order; usually all the feeds in a category are the same.)
When I click on a headline, I want it to expand into the full article, or as close as possible, immediately. When I reach the end of an article, I want to read the next one with no more than one keystroke.
I have strong preferences on typeface, size, and formatting.
If an RSS feed doesn't offer full content, I generally prefer for the reader to make an attempt to get it for me anyway.
I need to support a dozen or so independent users, all of whom will have their own preferences.
You can jump to the next article using the keyboard.
Also claims "fetches the original article and extracts only the relevant content using a local Readability parser", but I think I don't use this.
, but certainly Miniflux is very simplistic wrt. to categories- it makes sense for me now that you don't use it, thanks! (I normally view all feeds at the same time, only when "reading in bulk" I would focus on categories or feeds. Sometimes I even query PostgreSQL to see what feeds have more stuff unread! But basically my solution for that has been to purge a lot of high volume/low reading feeds I had, so my daily items are much more manageable. But that's a solution that of course does not fit everyone.)
caveat that the only supported database backend is PostgreSQL.
It's a testament to the power of NixOS that I didn't have to do a single line of PostgreSQL configuration or setup to host Miniflux - it's done automatically by default.
But, as a side note, I checked a bunch of other distro packages expecting most of them to set up the db for you, and pretty much none of them did. It's not as common of a feature as I thought.
I second that. As he became more jaded, it turned me off. It's a shame as there may be many reasons for this (including the idea of creating a persona). I'm using Commafeed now and it's pretty good. If you don't self-host, Inoreader has been great too.
tt-rss was pretty great, it did exactly what I needed it to do for 8 years, but I was never super happy with the setup because of the lack of real releases. I switched to FreshRSS a few months back and it's been excellent.
It's still pretty feature light but I'm a fan of Yarr for a web RSS reader, it's the first self hosted one I've been happy using for an extended period of time.
See many people here using self-hosted or even local web apps for RSS reading. Would love to get some feedback on why you choosing a web app over a desktop app. No judgement whatsoever. I just feel that RSS is one of the domains where desktop and local apps can shine a lot.
My main argument for a hosted reader is that it’s on all the time. I can easily not launch my reader app a few days but I still get all the posts. A client-side fetching (mobile or desktop) is prone to missing items on high-volume feeds if I don’t launch it regularly. Another issue is synchronisation. With a hosted solution I have a single source of truth: both for items fetched and their status (read, faved, etc.). There’s a clear responsibility divide and it’s easier to reason about states. Sync is possible without a server but in my experience it’s much jankier as there’s no clear hierarchy.
I use client readers both on desktop and mobile. But mostly for UI. The server is for fetching and state management.
got it! Thanks for taking your time to reply. So your reader is keeping RSS items even after they vanish from the feed (which is common for high volume sites)? I considered implementing that but in the end opted against it for simplicity. My client doesn't do background fetching, it only fetches when you asked for it, but I'm focusing on a calm experience and not a firehose of news.
It’s not so much about firehose as going through the publication at my pace.
Most feeds are not paginated, you can’t get all the published items unless you fetch the feed at appropriate rate. E.g. if a feed has 20 items in it but there are 30 posts a day you have to fetch the feed at least 2 times a day to get all of them. I don’t want to check my reader as often. I know I’m not missing anything if I’m checking it only once a day or even disappear in the woods for a week.
I’m not sure if you really mean it but not storing items that disappear from the feed sounds to me much more like a firehose. It’s way too much “in the moment” for me.
Most readers present individual feeds separately. So I can easily ignore high-volume feeds and still not miss anything posted on a blog that publishes like twice a year. Those are usually the ones that actually post interesting things. You know, interesting and unique things take time to brew.
I’m not saying your approach is inherently wrong. Everyone has their own approach to media consumption. Maybe for someone a limited snapshot of the moment is right. I prefer batching. But for that to work I need background fetching and storage. Otherwise I’d be antsy to check the reader often. I’m cnsciously trading the amount of things to filter out for frequency and schedule flexibility on my part.
To expand on what others are saying: synchronized read state is essential for me; I use many devices to read RSS.
Of course, this doesn't mean necessarily a web app! In fact, I wrote a terminal client for Miniflux using their API. Many feed readers offer APIs; in fact I think feed readers should be headless/lightweight server process to fetch feeds and keep state, and clients should be built on top. Actually, many readers implement APIs, and of those, the "Fever" API is quite popular.
My specific favorite thing about Google Reader was that it stored the feed data globally, effectively making it into an archive.org of RSS. For a lot of feeds, the moment I added them, years and years of articles showed up. Something that is now relatively difficult to emulate for hosted apps (just due to being newer than Reader), let alone local apps.
Anyone knows of an alternative that is API compatible? I'd like to keep using the app i have for the time being (an open source one). Otherwise I'll have to start with the clone i have been thinking for a while
I've been using bazqux for the last 13 years and it's great! I think it's actually written in haskell. Never have problems with it and it's never gone down! And since I paid for the lifetime membership way back when I think I paid him $100 13 years ago! I don't have a recurring subscription fee!
On the one hand: it worked pretty well.
On the other hand: the developer became, or revealed himself to be, a nastier and nastier person (or adopted such a persona) each year. It was clear to me that he didn't like dealing with fools and considered everyone with a different technical opinion to be a fool.
I will go look for another Google-Reader-like selfhosted RSS server when I have to.
I wasn't around for Google Reader so I don't know how Google-Reader-like it is, but Miniflux has been quite pleasant to use for the past 2 years with the caveat that the only supported database backend is PostgreSQL.
I like Postgres a lot, so that's not an issue, but Miniflux lacks some essential elements for me in terms of UI.
I'm curious, could you elaborate?
To me, the minimalism of Miniflux is one of the main selling points (along with it using PostgreSQL instead of MariaDB).
I'm not a minimalist, so that's a start.
I have 369 feeds right now, in 20 categories plus the Uncategorized dump that I occasionally sort through and re-assign. 8 feeds in there now.
I want -- and Google Reader, TheOldReader, and TT-RSS enabled this -- to click on a category and see the individual feeds, then click on a feed and see it as headlines-only in chronological or reverse chrono order. (I want different feeds in one or the other order; usually all the feeds in a category are the same.)
When I click on a headline, I want it to expand into the full article, or as close as possible, immediately. When I reach the end of an article, I want to read the next one with no more than one keystroke.
I have strong preferences on typeface, size, and formatting.
If an RSS feed doesn't offer full content, I generally prefer for the reader to make an attempt to get it for me anyway.
I need to support a dozen or so independent users, all of whom will have their own preferences.
Ah, Miniflux covers some of those:
, but certainly Miniflux is very simplistic wrt. to categories- it makes sense for me now that you don't use it, thanks! (I normally view all feeds at the same time, only when "reading in bulk" I would focus on categories or feeds. Sometimes I even query PostgreSQL to see what feeds have more stuff unread! But basically my solution for that has been to purge a lot of high volume/low reading feeds I had, so my daily items are much more manageable. But that's a solution that of course does not fit everyone.)
For me, I don't use Miniflux's web UI, and just use a native client that's probably closer to what you want for UI, i.e. NetNewsWire.
It's a testament to the power of NixOS that I didn't have to do a single line of PostgreSQL configuration or setup to host Miniflux - it's done automatically by default.
I mean, the same goes for Debian.
But, as a side note, I checked a bunch of other distro packages expecting most of them to set up the db for you, and pretty much none of them did. It's not as common of a feature as I thought.
I second that. As he became more jaded, it turned me off. It's a shame as there may be many reasons for this (including the idea of creating a persona). I'm using Commafeed now and it's pretty good. If you don't self-host, Inoreader has been great too.
If you use Nextcloud, the Nextcloud News plugin is rather solid, at least for my light use.
tt-rss was pretty great, it did exactly what I needed it to do for 8 years, but I was never super happy with the setup because of the lack of real releases. I switched to FreshRSS a few months back and it's been excellent.
It's still pretty feature light but I'm a fan of Yarr for a web RSS reader, it's the first self hosted one I've been happy using for an extended period of time.
See many people here using self-hosted or even local web apps for RSS reading. Would love to get some feedback on why you choosing a web app over a desktop app. No judgement whatsoever. I just feel that RSS is one of the domains where desktop and local apps can shine a lot.
Ps: I am biased, I make a RSS reader.
My main argument for a hosted reader is that it’s on all the time. I can easily not launch my reader app a few days but I still get all the posts. A client-side fetching (mobile or desktop) is prone to missing items on high-volume feeds if I don’t launch it regularly. Another issue is synchronisation. With a hosted solution I have a single source of truth: both for items fetched and their status (read, faved, etc.). There’s a clear responsibility divide and it’s easier to reason about states. Sync is possible without a server but in my experience it’s much jankier as there’s no clear hierarchy.
I use client readers both on desktop and mobile. But mostly for UI. The server is for fetching and state management.
Just adding my vote for synchronization: I look at my feed from at least three computers, a tablet and a phone.
got it! Thanks for taking your time to reply. So your reader is keeping RSS items even after they vanish from the feed (which is common for high volume sites)? I considered implementing that but in the end opted against it for simplicity. My client doesn't do background fetching, it only fetches when you asked for it, but I'm focusing on a calm experience and not a firehose of news.
It’s not so much about firehose as going through the publication at my pace.
Most feeds are not paginated, you can’t get all the published items unless you fetch the feed at appropriate rate. E.g. if a feed has 20 items in it but there are 30 posts a day you have to fetch the feed at least 2 times a day to get all of them. I don’t want to check my reader as often. I know I’m not missing anything if I’m checking it only once a day or even disappear in the woods for a week.
I’m not sure if you really mean it but not storing items that disappear from the feed sounds to me much more like a firehose. It’s way too much “in the moment” for me.
Most readers present individual feeds separately. So I can easily ignore high-volume feeds and still not miss anything posted on a blog that publishes like twice a year. Those are usually the ones that actually post interesting things. You know, interesting and unique things take time to brew.
I’m not saying your approach is inherently wrong. Everyone has their own approach to media consumption. Maybe for someone a limited snapshot of the moment is right. I prefer batching. But for that to work I need background fetching and storage. Otherwise I’d be antsy to check the reader often. I’m cnsciously trading the amount of things to filter out for frequency and schedule flexibility on my part.
To expand on what others are saying: synchronized read state is essential for me; I use many devices to read RSS.
Of course, this doesn't mean necessarily a web app! In fact, I wrote a terminal client for Miniflux using their API. Many feed readers offer APIs; in fact I think feed readers should be headless/lightweight server process to fetch feeds and keep state, and clients should be built on top. Actually, many readers implement APIs, and of those, the "Fever" API is quite popular.
My specific favorite thing about Google Reader was that it stored the feed data globally, effectively making it into an archive.org of RSS. For a lot of feeds, the moment I added them, years and years of articles showed up. Something that is now relatively difficult to emulate for hosted apps (just due to being newer than Reader), let alone local apps.
miniflux just works on all my devices and lives in my browser, so the articles I open from feeds are where all my other articles are.
The main reason I use a web app is syncing read progress across my devices
Anyone knows of an alternative that is API compatible? I'd like to keep using the app i have for the time being (an open source one). Otherwise I'll have to start with the clone i have been thinking for a while
I've been using bazqux for the last 13 years and it's great! I think it's actually written in haskell. Never have problems with it and it's never gone down! And since I paid for the lifetime membership way back when I think I paid him $100 13 years ago! I don't have a recurring subscription fee!
Oh wow.. this brings back memories. Good to see that bazqux is still alive.
You're right that it's partly written in Haskell. According to https://blog.bazqux.com/2014/01/urweb-and-bazqux-reader.html the front-end is Ur/Web and the rest is Haskell.