Tested this with the RSS feed for https://plurrrr.com/ and it works great! Go to https://srv.tt-rss.org/tt-rss/#f=12&c=0 (user: demo, password: demo). Only thing that was confusing was that it takes some time (like 40 seconds?) before the feed is fetched the first time; it looked for a while like something went wrong with my feed as nothing showed up. Maybe some placeholder until the feed is fetched?
Oh right, I just had the same experience, I thought it was failing and went to some RSS validators to be sure I didn't have something incorrect in my setup. When I went back to the srv.tt-rss.org instance after a few minutes my articles were there. The initial UX could be improved, that's for sure!
The fetching of content is done by a long-running update daemon that is separate from any PHP code that is the UI. The worker code is pretty naive, does not use a blocking queue etc, and sleeps for a configured interval before the next feed update run.
It's normal. A half year or so back I logged in to the demo instance and added my 1.4 MB .opml list of RSS sources. It loaded about the first couple hundred from each folder. But only after I waited a while.
I tried out the TTRSS with another feed and saw what you did - there's definitely about a minute gap between adding a RSS feed until those articles are processed and available in the web view. I assume it's due to the current heavy use, or perhaps it's being throttled.
Slight offtopic; I love your microblog Plurrr - the site and code are clear, simple, and get the job done. I poked around the code a bit because I'm interested in starting my own microblog. A quick question: in your CSS file located at https://plurrrr.com/soothe.css , the code declares font-family: San Fransisco - is that a misspelling of San Francisco or does the CSS spec mandate that spelling?
CSS spec doesn't mandate specific font names, those are decided by the font creator or css author. San Francisco is Apple's new (?) font that replaced Helvetica Neue. The typo might be intentional--I had to intentionally use the wrong name for a Windows system font in my @font-face stylesheet recently to ensure the browser wouldn't use the system version (fake-bold italic looked better than bold fake-italic in the headings, and I couldn't find a bold-italic version)
When I wrote my own static site generator [0] I added JSON first because it's dead simple to do so. Later I added RSS and it was quite some work to get it right ([1][2]), as in I wanted both the Perl and the Python version to output an identical feed. Last time(s) I checked, they do validate for my tumblelog [3]
Atom is technically substantially superior. RSS is an awful hack that leaves far too much to chance, such as in not specifying the format of fields that could be HTML or text. Probably the most significant thing is that Atom encodes whether a field is text or HTML. If you want your feed item’s title to contain things that could be parsed as HTML (e.g. “how to use the <hr> tag”), you’re in for a miserable time: some feed readers will treat it as plain text; some will treat it as HTML (and then probably strip out the <hr>); some may even double-encode it (“how to use the <hr> tag”). If you use Atom, you can specify that the title is plain text, so that the intent is clearly conveyed, and any client that mangles it in any of the aforementioned ways (and I’m not going to rule that out, though I’ve observed fewer problems with handling of Atom feeds) is clearly and definitely wrong. You can also use this to deliberately write HTML in your titles, e.g. <strong>, <em>, <code>. I like to do that, especially for <code>. Most readers will probably subsequently strip the HTML (which is a bit of a shame for inline formatting), but the idea is nice anyway, and more importantly it makes it clear what the correct way of handling it is, rather than leaving it unspecified and hoping for the best.
For normal feeds, I recommend developers use Atom every time. No need to subject yourself to the pain RSS engenders.
However, there’s one place where you still need to use RSS: podcast feeds. Most podcast software doesn’t support Atom, despite the fact that at the time when all that software was written RSS had been obsoleted by Atom. The industry just doesn’t seem to have realised Atom exists, which is stupid: they all just keep on copying one another instead, and adding their own namespace both to add their own fields and to fix the shortcomings of RSS, so that if you follow all of the recommendations from Apple, Spotify, &c. &c. you’ll end up with most of the fields written out in 3–6 different ways (e.g. <foo>…</foo>, <itunes:foo>…</itunes:foo>, <spotify:foo>…</spotify:foo>, <something-else:foo value="…"/>, that kind of thing).
Pretty much all progress in feeds happened between about 2002 and 2007. Roughly no documentation or review of the situation has been published since then. It’s a very unhealthy ecosystem.
Summary: RSS for podcast feeds, Atom for everything else.
Been using it for many years. Its a great self-hosted solution. The android app also works well.
But the lead developer is the worst stereotype for the egotistical god-complex. You have to worship the ground he walks on or he'll publicly attack & mock you. If you don't anticipate all of his questions in advance, he'll attack you with all sorts of infantile insults. He clearly feels that he is doing everyone the world's biggest favor by providing his software to the masses.
Pretty spot on. I use a slight fork of TTRSS, and most discussion of offering up PRs upstream is "probably not worth attempting". Unfortunately, developers with this attitude end up harming themselves more than anything else.
But I've been pretty attached to using TTRSS for over five years now.
I use TTRSS as a Sandstorm app, so there's a bit of adjustment needed to make it work well. There's a few tweaks we could send back as PRs but we had a pretty rocky first interaction with the dude.
I almost posted something similar but stayed my hand. I tried to submit patches in 2006. I got one in, I think, but that was enough for me to fork and go on w/ my own version. I really like my fork, but I can't make any recommendations about the current mainstream version because I haven't looked at it in 10+ years.
But at least it's maintained consistently and has been maintained for the past 14 years now.
I've been using it since the end of google reader and it works great. The filtering aspect alone is wonderful for me to filter out some tags/authors.
The (paid official ) Android app is pretty good too and supports offline reading (for a very small fee).
I self host it on a public facing server. Great to sync my reading between all my devices. I do recommend adding some basic auth in front of the (obviously https) login page as the client apps (android) supports it and it adds a layer of security.
I haven't used tt-rss but FreshRSS has been working phenomenally for me over the past several months. I don't even use a mobile app because the web site works perfectly well on mobile. I have a few minor quibbles like GitHub release feeds having broken favicon images, but overall I'm extremely pleased with it.
Glad to see FreshRSS working well. Seems like most people are pretty happy with any of the big ones that come up (including miniflux). Good to be spoiled with choice, though for those of us that are indecisive....
Running FreshRSS on my cluster with FeedMe and happy with it. I looked at TinyRSS when getting going. Chose FreshRSS because it can run self-contained, whereas TinyRSS requires Redis. Just one less moving part is all AFAICT. Could be wrong, don't really care at this point as FreshRSS is fine and working. :)
Another vote for this fantastic software. I have been using it for about two years now - with Reeder on Mac/iOS. Reeder introduced our of the box support for FreshRSS (it used to be via Fever API earlier), and now things are super fast - 12,000 starred items are downloaded on a fresh install in a jiffy. Just can’t say enough about FreshRSS.
I used, and selfhosted, TT-RSS for a long time but eventually gave up due to it braking at almost every update. I was furious.
So I found and tried FreshRSS. I have been using it for years now, without a single hitch. I always chose apps that run SQLite over full fledged DBs these days. So much easier to manage, migrate etc.
Been using TTRSS hosted on a Raspberry Pi 3 every day for over a year now. I can't believe how many people think RSS has fallen out of style. It's great to keep on the pulse of everything interesting to me, and quickly tab through the stuff that isn't, without potentially missing something.
I'm not glued to TTRSS though, there may be a better self-hosted feed reader out there. TTRSS has some important features I wouldn't want to be missing, though; it has a built-in feed aggregator where you can choose which posts to re-post to your own feed, which you could distribute to others if they were interested in what you find interesting.
Miniflux is very opinionated. You do things the miniflux way or you don’t. I didn’t like it at all, others swear on it. I’d try it out and see if it works for you, if it does, you’ll probably love it ;)
I love Miniflux. I found TT-RSS to be much too cluttered and I enjoyed Miniflux's focus on minimalism & privacy, but that's a personal opinion. It also doesn't require a mobile client: it works just fine in a mobile browser, a big deal when most Android apps for self-hosted RSS readers are either ugly or unmaintained.
Setting up Miniflux was problematic because documentation around its pSQL & environmental variables aren't too well-documented or universal in implementation.
However, I've noticed a lot of people really don't like Miniflux because it is very minimal and doesn't try to do everything.
I tried ttrss, freshRSS, miniflux and a couple other hosted solution: all made use of some "modern" feature that prevent me from using it on a ageing BB10 device. So it now host my own instance of rss2email and just get my feeds as email.
I wound up writing my own but mostly because I couldn't be bothered with complex setup: https://github.com/rcxdude/nobsrss . It should work on basically any browser, it uses no javascript. However it's super minimal to my RSS use-case, which is basically just notifications (it doesn't attempt to parse or render the content of the feed beyond the link).
All these projects to self host a copy of google reader are kind of missing the point. A native RSS reader that runs as a single application (ie, not web-crap) does everything better, faster, leaner, and more reliably over long timespans.
I'm all for 'self-hosting'. I do it for all things that require it. But an RSS reader simply doesn't need that kind of complexity. It's cargo-cult.
A great companion is FeedMonkey, a web based reader which plays very nicely w. tt-rss. I forked it w. dark theme, ES6 syntax, article grouping. Just host it on the same server as your tt-rss, no cross-site issues:
What Reader do you use with this or other recommendations here? A web browser?
Is it possible to use any of these aggregators with a standard RSS feed reader application and still see the feeds on the client as if the client is fetching those from the original sites (so you still see site names and the articles under them)?
reply