Tiny Tiny RSS
Long story, but while I have Newsblur running locally I've got myself a virtual private server in "the cloud". Which gave me a different platform & an opportunity to retry tt-rss.
It's pretty easy to set up, given that it's already delivered as docker containers & there's a docker-compose to get everything running. The installation instructions are here.
I'm also going to skip setting up access via a reverse-proxy. It's not difficult with caddy.
Why the post here then, if it's all "simple" & "easy". Well there was a little challenge in getting tt-rss to play nicely with the local (vps) install of Huginn. I've mentioned using it for generating feeds before, as well as using it to provide feeds created from redlib.
The second challenge was to get the "priority" display that NewsBlur provides so easily. I really like being able to see the most important bits of my feeds highlighted as an unread count within their own feed/category, while still being able to read the whole lot (pre-filtered, remember) when I've got a bit more time. That reading usually takes place on my phone, via an app, rather than using the tt-rss web interface. Which means that a little trickery was needed.
tt-rss & Huginn
Huginn only provides access to the rss feeds via a URL that has to point to port 4750. tt-rss doesn't do ports, so can't read the feeds that Huginn has generated. 😦
There is a solution in the tt-rss forum. Add a "sidecar" container that redirects the queries & presents the feeds on the ports that tt-rss expects.
The relevant bits of writeup are here:
I only really have need for a single purpose “internal reverse proxy sidecar container”, but there’s no reason that this can’t be extended to handling multiple services through a single instance of the caddy container. I’ll assume that you’re using linux & have chosen to keep your docker stuff in your home directory…
Change the <user> to your own username & alter the networks to suit your needs:
$ cd ~/docker/
$ mkdir caddy
$ mkdir caddy/config
$ mkdir caddy/data
$ mkdir caddy/conf
$ cd caddy
$ nano docker-compose.yml
services:
caddy:
image: caddy:2.8.4-alpine
container_name: caddy
restart: unless-stopped
cap_add:
- NET_ADMIN
ports:
- “7080:80”
- “7443:443”
- “7443:443/udp”
volumes:
- /home/<user>/docker/caddy/conf:/etc/caddy
- /home/<user>/docker/caddy/data:/data
- /home/<user>/docker/caddy/config:/config
networks:
- caddy_default
- ttrss_default
- huginn-default
networks:
caddy_default:
ttrss_default:
external: true
huginn-default:
external: true$ nano ./conf/Caddyfile
(logs) {
log {
output file /data/logs/docker-access.log
}
}
:80 {
reverse_proxy huginn:3000
}$ sudo docker compose up -d
The networks part of the docker-compose.yml joins caddy to the networks (apps) that need to be able to see each other. Which lets container to container DNS work so that we can use the container name for access. i.e. ttrss can “see” caddy, & caddy can “see” huginn, which is what is needed.
The Caddyfile just redirects all incoming traffic on port 7080 to the huginn container, at port 3000. If there were more apps then they could be filtered into the correct containers using the URL that was sent to caddy. Something like this:
:80 {
@h huginn
handle @h{
reverse_proxy huginn:3000
}@r redlib
handle @r {
reverse_proxy redlib:8080
}
}
(It’s worth pointing out that my issue was with having a reverse proxy on the same host, so ports 80 & 443 were in use. That doesn’t stop you using that reverse proxy to forward requests & their requested URL to caddy on port 7080 though, all that you need is a suitable proxy URL. Or you can do what I did & refer to the caddy container from within the docker network - so ttrss can refer to caddy in the RSS URL by using the docker internal DNS & the visibility allowed by the shared docker networks e.g.http://caddy/users/1/web_requests/33/Lemmy-Highlights.xml)
Basically, use docker networks to put tt-rss, Huginn & caddy in a place where they can see each other & use their "names" to identify each other. Then use caddy to translate calls to port 4750 so that they are "seen" on port 80 (only available within the network).
Priority lists
This is more complicated than with Newsblur. You can't just "thumbs up" & then switch to the "thumbs up" view to see the posts that match your filtering preferences. (Or have them deleted by choosing "thumbs down").
tt-rss does offer ways to order the priority of feed items, as well as filters that can be curated to act on the required characteristics. The filters have to be created & maintained outside of the feed/articles themselves (although there is a keyboard shortcut of c f if you are using the web interface & a keyboard & want to create a filter).
OK, so the obvious thing would be to use the filters to add a tag or a label to the articles that I want to see as a priority. I started with tags - they come assigned by the feeds at least some of the time.
Creating a filter is easy enough: specify the regex to use to recognise the content of the article that you want to trigger the filter. Then choose which parts of the article to consider & which feeds need to be considered. Then change to the other tab in the filter creation window & choose to assign a tag. Type some easily searchable text & you should be good to go...
I didn't have as much luck with that as I'd like: the way to search for tags is easiest achieved by finding an article with the tag & then clicking on the tag, which generates a search for the articles with that tag.
To the left of the article list is an RSS icon - click that & you get a feed URL that you can use for external subscriptions. Subscribe to that feed & you'll get the search results for your tag, right? Yes, totally right. You get the search each time you update - with a new hash for the results... so each unread article gets duplicated for each RSS feed fetch. That's not what we want!
What about labels then. These are a bit like internal tags, used within tt-rss. Well, the first catch is that you need to define the labels (in the preferences) before you can assign them.
Then create your filter & assign a label
That was as easy as adding a tag, but... the labels don't show in the article header. That's because they are pseudo-categories & show in the sidebar
That makes it easy in the web interface to find the articles tagged by your "priority" filters. I use an app on my phone though. Does that display labels - no it doesn't 😦
There is a positive though - the RSS feed generated by the labels doesn't seem to have to same issue with creating new hashes for each "search". Presumably the label category is created/updated without an active search process to create a "new" hash for the feed. Doesn't matter though - I have a way to create my priority view of the full article list. All I need to do is to subscribe to the RSS feed for the label (which works the same as for the tags, as shown above). Then as long as I have enough labels to make it feel similar I can read these new feeds as the priority view that I'm used to.
Alternatives would be to use the star category (but there's only one of those) or to use the scoring system to boost the interesting articles to the top of the feeds (or the bigger mixed lists such as "Fresh articles")
There is a downside if you switch between the mobile app & the website, or if you have time to read the fuller list of articles in the feeds though. Those labels that you can't see in the app (as the source of the RSS feed that generates the priority view)... Reading those feeds doesn't link back to the articles that have the labels. So they will appear as (separate) duplicates when you feed that they are actually pulled from.
Side note: Category ordering
If you go to the preferences section & choose the feeds tab then you can drag & drop feeds/categories so as to change the sort order. That lets you add feeds to categories or move them between categories. What's less obvious is that if you drag a category to another category then you get a "sub-folder" - which lets you nest feeds within specific categories, within broader categories. On the website view at least. The app I'm using doesn't support it & flattens things to just show the categories without nesting them.
Final thoughts:
Setting up tt-rss to use the filtering from huginn is pretty much a one off action. Using tt-rss to prioritise parts of the feeds is much more manual than NewsBlur & the best I've managed in the attempt to mirror my preferred workflow within tt-rss is a bit of a kludge to say the least.
In honesty I think that splitting the feeds using a trigger node within Huginn is about the same amount of effort & would avoid the duplicate unread articles.
YMMV, of course. I happen to like to have a pre-filtered stream of feed articles that are then split into a high & lower priority view while remaining in their feed/category. That lets me read as much as I have time for & lets me pick the content that I most want at the time, as well as letting me skim read the feed with my "eye in" for the type of content that I'm after. NewsBlur does that very well.
Others would prefer the scoring system within feed/categories, or harsher filters to only show highest priority articles, or a mixed stream of "top rated + newest". You do you.
Hopefully I've shared a couple of config points & options that aren't as obvious as they could be, as well as covering how you could enable the use of Huginn to deliver some of the options before tt-rss gets the feeds.
Well done for reading this far!