Tiny Tiny RSS

> But the lead developer is the worst stereotype for the egotistical god-complex.

This is either a sad state for the project or an excellent use of self-deprecating humor. :)

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 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.

Well, this might sound harsh, but, let him... some of us need a dragon. People tend to pour their own poison, so i hope you don’t give it more thought

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 think he’s chilled out a bit. Definitely read the project forum guidelines and attempt a search for an answer before posting a question.

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.

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'm using Nextcloud RSS aggregator and really like it.

https://github.com/nextcloud/news

I wrote my own when I moved away from Google reader (after a brief feedly run) , and I've been using it every since

https://github.com/urandom/readeef

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.

Have you tried any of the others like ttrss or FreshRSS? Or any reason why you went with miniflux over others?

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?

Why was it ever called dead?

It's the obvious way to consume site contents.

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 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.

There is also JSON: https://jsonfeed.org/

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]

[0] https://github.com/john-bokma/tumblelog

[1] http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-...

[2] http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-...

[3] https://plurrrr.com/

For a reader what matters is what is used in the wild.

I use RSS because it is very easy to write RSS 0.90 by hand.

https://www.rssboard.org/rss-0-9-0

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 &lt;hr&gt; 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.

Par for the course in PHP