Elfeed, if you are using Emacs. You can view most blogs and lighter websites w/ no problems with Emacs's web browser, EWW. Or you can tell Emacs w/ one variable to open links with an external browser.
All these services have free plans either if you have little traffic or if it's open source. So it's definitely possible to self host this (although maybe not completely trivial).
Disclaimer: I work at Stream (but haven't really worked on Winds)
An outage at any one of five services will stop your thing from working, and it won't necessarily be obvious what happened. Now you need to monitor five services, plus the one you actually built. Oh, and the free plans will stop being free once you cross a threshold of use, which is probably about when it becomes important to you.
If each of those services has an outage once a year, you'll get to feel all of them.
Compare to tt-rss: if your own web server and database are running (and there's an internet connection), it's working.
Those are enterprise services that offer at least four nines of availability each, probably more. AWS even advertises 11 nines for a select set of features. They should add up to a service that has an availability in the 99.98%.
Meanwhile, obtaining anything over 99.9% is usually a challenge for the amateur. Even if you are on call on every day of the year, it's very easy to go to sleep with your phone muted and wake up the next morning to discover the service is down for whatever reason.
That's not self-hosting. That's paying a cloud provider for a lot of services I don't need.
To me, self-hosting means I can (theoretically) run everything I need, on my bare-metal -- a cloud provider or cloud service (eg, RDS) then becomes a choice, not a requirement.
Suppose you swapped out every piece with a free, local one -- it'd still have the problem of being way overdesigned for what I'd need. Even if the UI looks decent.
Did RSS ever go away? Almost all of the blogs I follow still have RSS feeds. Maybe I'm just in a bubble. I think the decline in relative importance of RSS is certainly real, but that's more an effect of people getting their information from more centralized sources (like HN).
I have no idea. I'm still using it and all the blogs I read still use it. I'm a little confused. I think the death of rss has been greatly exaggerated. As an aside I described one of my worst experiences with food poisoning as "having the winds" I'm a little biased against the name I guess.
I don't think many sites removed RSS, but many new sites and services in the last ~5 years, never implemented or served it in the first place. The typical share icons now are FB, Instagram, and Twitter. Email is less common (although usually there's an email newsletter signup). For a while, there wouldn't be link to RSS on the page, but you could still find the .rss or .atom link in the HTML header. But a lot of times that's not there anymore either.
It makes me sad to have to settle for Liking a company's FB page, since it's up to FB whether or not I ever see it.
Youtube is like this. They don't advertise rss feeds but include them in the page source of youtube channels. In the one or two times I couldn't find the link in the source, I'd just copy the channel id of the channel and use the feed url from another channel. Works like a charm!
A surprising amount of services have this. You can even turn your Gmail inbox into an (authenticated) RSS feed[1]. Small warning: it uses an outdated XML feed namespace, but most readers should handle it fine.
> "For a while, there wouldn't be link to RSS on the page, but you could still find the .rss or .atom link in the HTML header. But a lot of times that's not there anymore either."
Most blogs that I visit will highlight the RSS ("Subscribe to this page") icon in Firefox's icon bar. (The RSS icon is not present by default, but you can add it via the Customize dialog.)
For Chrome, there might be extensions that implement similar RSS auto-detection functionality.
I can tell by my experience of building https://telescope.surf, a lot of the sites are killing RSS or simply not linking it from any of their pages. I had to build crawlers for a lot of the sites.
Same thoughts here. I actually designed my own template for ATOM feeds for my Hugo generated blog. My blog serves both RSS and ATOM for the home page sections and even various taxonomies. So people interested in Emacs can subscribe to a feed of Emacs related posts only.
Why is this a downloadable app instead of a web app? It's built entirely using web technology. I think RSS belongs in my browser, so I can easily access it from whatever computer I might be using.
This is a great point; however, we wanted to bring the user experience to the desktop. You are more than welcome to submit a PR to make this application web compatible.
Your comment broke the HN guidelines, so it was properly downvoted. This one too. Could you please (re-)read https://news.ycombinator.com/newsguidelines.html and post civilly and substantively, or not at all? We're hoping for something a bit better here.
Well yeah, ofcourse. I dont see where my inital post broke anything.
It was esentially as meaningfull as OPs reply.
Ofcourse, the point of "this app should run in a browser" is very valid. The reply, he can just code it himself is in my eyes a passive aggressive way of saying "no, i said your point is valid, but actually think it isn't and therefore ill ignore it anyway."
Its obvioulsy, that a well developed web app should be runable in a browser and the developers could have thought about it earlier. They know their project better than anyone, so the afford of understanding how this piece of software works for an outsider is way to high.
"Your app should run on windows. It only runs on [not windows]? Downvote!"
"Your app runs based on technologies that mean you could easily port it to windows. But it doesn't run on windows? Downvote!"
"Your app runs on windows, but it's built on technologies that allow it to run anywhere else; why does it only run on windows? Downvote!"
See the pattern? Saying "I don't like your entire contribution because it doesn't run on a given platform on which I think it COULD run" is counterproductive and at best pointless; at worst rude.
Why do you require users to make an account? I personally would rather have all my settings stored locally, and export them if I needed to. An option for this would be great.
Yeah I installed it, saw you need an account, and uninstalled it.
I quite like desktop programs still, but I expect everything to be stored locally and not to need an account. I had hoped for a KeePass style db file that I could sync on Dropbox or something, but the last thing I need is more accounts and my data on some randoms server that could be taken down when they get bored, or run out of money/motivation.
Stream is an API for building activity feeds. You use it when you want to follow things in your application. Another use case is notification feeds. RSS readers are a tiny fraction of our customer base, but it's something we care about. API tour is here: https://getstream.io/get_started/
Currently Stream powers the feeds for over 300 million end users, Stackshare did a nice post about our tech:
https://stackshare.io/stream/stream-and-go-news-feeds-for-ov...
It's a circle that right now is spiraling the wrong direction. I hope that the community can come together and improve the user experience around RSS. This in turn will help show the value of RSS to publishers. The current user experience around RSS isn't always very use friendly. On the other hand, the people that care about RSS are designers, developers and journalists. We should be able to turn the tide.
This makes me weep. We are returning to RSS _because_ of dumb over-engineering web apps. The solution is not a dumb over-engineered web-based RSS reader.
> I love using RSS to follow the programming and tech news I care about. Unfortunately, the number of sites supporting RSS has been in rapid decline over the last few years. The reader ecosystem is slowly degrading as well.
After that introduction I was hoping Winds would be some kind of proxy that creates an RSS for sites that don't have one. But well, it's just another RSS reader. Those have actually never gone way, I'm using Inoreader every day.
A site should still be able to choose to not produce RSS if they don't want. Encouraging RSS is different than forcing RSS feeds on sites that don't want them.
Torrenting is illegal because you (generally) weren't authorized to make a copy. Stripping commercials isn't because you're removing something, or changing the way you read it. There might be some legal case if you have to make another copy of media in order to alter your consumption, but thank God I'm aware of no case attempting to control your personal use of media.
(DMCA doesn't count, it's about circumventing things that prevent you from copying, not change your consumption.)
Just to this point, an example: My parents' VCR had a built-in feature that would automatically fast-forward through commercials when playing back something that it recorded.
I think so too. I use RSS as a very minimalist blog and have had good experiences with it so far. It's hard to monetize the format, but it really draws a lot of people to my side.
For reasons I don't understand, it remains incredibly difficult to scrape a well-organized blog and turn it into something I can consume like RSS or a kindle book.
Note that many/most WordPress RSS feeds aren't that useful because they only show a snippet rather than the entire post. This dreary state of affairs is due in part to the fact that "checking" an RSS just means downloading the entire file containing all posts the author would like to make public, regardless of how many are new to the reader. This insanely unnecessary bandwidth usage penalizes sites that have long (>10) feeds with complete posts. (The single RSS file on my blog takes up the majority of my bandwidth costs.)
Is the problem really that RSS needs replacement, or can it simply be improved. I think there is quite a bit of room for extension to address some of the concerns that are expressed here too, including accurate meta tagging for educational resource discovery purposes.
I'm under the impression that pulling extensions on RSS will land us in the XMPP situation, where you have servers and clients speaking different languages.
On the other hand, if you want to say that your client supports this supposed RSS-ng standard they need to support those new features because they're part of the protocol.
This is to say, I don't like protocol extensions, but that's just me :)
You mean the fact that aggregators like The Old Reader just download the RSS file from the website periodically, and then serve up cached copies to their many user? True, although this is another way of saying that some of the value added by aggregators only exists by virtue of the terrible design of RSS.
It doesn't need code. Just a static text file with a list of publication dates and URLs, each of which points to static HTML file for each publicly available posts. Then each user could check the list and download only what's new, without needing an aggregator. Users would never need to download the same content twice.
You can pretty much do that with RSS, if you want. Slightly decorated with some XML stuff but that'll pretty much gzip right away. Statically, if you use the right web servers and magic invocations the web server may specify.
You'll find your feed readers aren't particularly impressed, though.
This won't work because my users don't have software to automatically download the new posts, curate them, and save them for offline reading (in contrast to having the posts directly in the RSS file, for which all that does happen). That would require...a new standard, i.e., a replacement for RSS.
No, it would require a new type of consumer. RSS can carry a list of URLs just fine, as a degenerate case of RSS. RSS does not itself mandate that the content of the RSS must be displayed in "some sort of feed reader".
The good news is that means you don't have to wait. You can write that now. It will work on existing RSS feeds, just not quite as optimally for your proposed use case as you might personally like, but it will still work. It will work even better on yours, which will also work in conventional RSS readers.
Now, you might have problems getting "the real page content" from your URLs, but that's a separate problem. (History strongly suggests the large-scale content producers would actively fight you if you try, because you'll probably be trying to strip their ad revenue either deliberately or accidentally as part of what you'd be doing. Which is, after all, the reason why RSS is already not terribly favored by that crowd and why they want you in closed gardens of their own devising... unfortunately getting around this problem is a great deal more difficult than hypothesizing that some sort of new standard could somehow deal with it....)
I'm using "RSS" to refer to the standard practice people actually do. It's not very important that some organization somewhere defined an official RSS standard which in principle is flexible but which in practice is never used other than in a very specific way. (Without an agreement on how to use it more generally, no one can build an offline blog archive reader, and the fact that RSS could in principle be the base is irrelevant.)
If you want to play semantics, I'm fine with rephrasing my complaint as: "We need to build on the flexible super official RSS standard -- which is little more than an XML file -- and actually agree on a way of delivering blog archives for offline reading. RSS in practice does not currently achieve this very simple goal." This is just different words to describe the same thing.
> You can write that now. It will work on existing RSS feeds, just not quite as optimally for your proposed use case as you might personally like, but it will still work.
Huh? Other website owners who would like me to be able to read their archives can modify their RSS file, but we have no agreement on how to do that in a standard way. Likewise, I could modify my RSS file, but since there isn't a standard my readers won't have software to take advantage of it.
> (History strongly suggests the large-scale content producers would actively fight you if you try,...unfortunately getting around this problem is a great deal more difficult than hypothesizing that some sort of new standard could somehow deal with it....)
The blogs I want to read offline do not have ads and do not care about this. I just want a solution that works for this simple problem, not a way to take content from people who don't want to give it to me without attaching ads.
>This dreary state of affairs is due in part to the fact that "checking" an RSS just means downloading the entire file containing all posts the author would like to make public, regardless of how many are new to the reader. This insanely unnecessary bandwidth usage penalizes sites that have long (>10) feeds with complete posts. (The single RSS file on my blog takes up the majority of my bandwidth costs.)
Still, exceptionally low cost compared to running pretty much any website's massive CSS and JS files. A single image in most cases will take more than the entire RSS feed before compression.
That said, I would like to see a new standard (a new one would be needed [1]) that only gets the difference from what you last read - I think that would really take RSS feeds to new places of usefulness. There's no reason why you couldn't send the server an ID (not timestamp to avoid issues with timezones, clock stretching, forward/backward time setting, etc) of the last request and have it send back everything since (within reason).
That's something both RSS consumers and produces should already support, but don't always, called an E-Tag, a standard part of the HTTP standard. However, the E-Tag is all-or-nothing; either it matches, and the entire request is essentially aborted, or it doesn't match, and the entire file is served up.
Passing "the ID of the last piece of content I saw" would allow the server to return just the updated stuff, or abort early like an E-Tag. However, counterintuitively, as is often the way in computer science, I'm not sure it would be that big a win to be able to return partial content. The vast bulk of the win on most blogs will just be the ability to abort at all, provided just fine by E-Tags.
I would say that if your site is getting hammered by HTTP requests for your RSS, do double-check that you've got E-Tags set up and working correctly. It is in the best interests of the big scrapers to support that properly, as they are paying for that bandwidth too. RSS aggregators don't have to get too large before this becomes a top-priority feature request. Unless the feed is literally changing on roughly the same frequency as it is scanned, it shouldn't be the dominant factor in your bandwidth bill.
> Still, exceptionally low cost compared to running pretty much any website's massive CSS and JS files.
My blog has both RSS and browser readers, but the bandwidth is dominated by the RSS feed. Since the RSS file has no images (just HTML pointing to the images), I think it's more likely that for my Wordpress blog the CSS/JS overhead is just not that much (as opposed to the alternative hypothesis that I have many many times more RSS readers who never end up downloading the images).
Or you have way more users via rss than through their browser. This could be a good thing as it results in less bandwidth than if they all hit you directly through browser.
Exceptionally low cost per hit, as opposed to overall bandwidth. Overall bandwidth will probably fair off worse as you say due to the polling nature of RSS. I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.
Also in general, I would be tempted to make an RSS feed more minimalist in terms of content and markup. It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).
>I think it's more likely that for my Wordpress blog the CSS/JS overhead is just not that much
Also, bandwidth is just one resource - potentially each call to a page is a database read, whereas your RSS feed should be static (not sure about the WordPress implementation, but I would hope for static caching with something that doesn't change for long periods of time). I've seen WordPress database lockups with modest amounts of traffic (again, most of the time this could have been easily statically cached - but doesn't appear to be by default).
> Exceptionally low cost per hit, as opposed to overall bandwidth.
I don't understand. I'm telling you that my RSS file literally dominates my bandwidth usage in GB.
> I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.
Yah! Agreed.
> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).
No, I want people to be able to read it offline. I'm not trying to monetize anything.
> Also, bandwidth is just one resource - potentially each call to a page is a database read
I have a simple website. The bandwidth is the dominant cost.
>> I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.
> Yah! Agreed.
You could also reduce the number of `<item>`s you keep in rotation to a more manageable number.
>> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).
> No, I want people to be able to read it offline. I'm not trying to monetize anything.
It should still be much more lightweight than it's HTML counterpart. Should be almost nothing to it, next to no markup, no styling, no scripts and a highly compressible piece of data.
I don't understand how you're racking up massive bandwidth. Can you put some numbers to it:
You should already be able to implement this using the If-Modified-Since HTTP header. The server only needs to send you back articles in the RSS feed that have been added after that date. The If-Modified-Since value is meant to come from the previous responses Last-Modified (not a timestamp you make up), so that side-steps timezone issues.
For your RSS issue, you can safely truncate your RSS feed to the latest N articles, where N is a random reasonable number you choose (10 is good, because it's so decimal). RSS reader software will know how to deal with it.
WRT scraping, it is getting harder because funny websites w/ no static content where everything is generated via Angular or Perpendicular or sth. are really hard to deal with. Recently my uni switched from an army of Wordpress websites to an homegrown AJAX-MVC-Reactive abomination where the links are reimplemented via some funny black magic where the actual link items (which are not anchors btw) don't have encoded in them the link targets, but only an onclick event that knows somehow where to go. And because they just killed all the RSS feeds, I wrote up sth. to revive them for me via phantomjs, but could not figure how to find the link targets, I cannot link the RSS items to anywhere but the main announcements page, and I can't add any description from the link target.
RSS should be kept, those who don't know the job they are doing should be replaced.
> For your RSS issue, you can safely truncate your RSS feed to the latest N articles, where N is a random reasonable number you choose (10 is good, because it's so decimal). RSS reader software will know how to deal with it.
But people who don't use the right aggregators will not be able to read past 10 posts. And if everyone was using aggregators, I wouldn't have such a high bandwidth bill.
> WRT scraping, it is getting harder because funny websites w/ no static content.
But sites that can have an RSS feed necessarily need to deliver their content in a static form. What surprises me is that we don't have a tool for even those cases.
> But people who don't use the right aggregators will not be able to read past 10 posts.
I do not think such aggregators exist, and you can just ignore people using software that do not comply to widespread conventions.
> And if everyone was using aggregators, I wouldn't have such a high bandwidth bill.
I don't understand this sentence. All RSS client software is called aggregator.
> But sites that can have an RSS feed necessarily need to deliver their content in a static form.
Not really. Many websites which are essentially blogs are transforming themselves into single-page web apps. My uni's websites included. Some do it for the $$$, some for reasons that I can not know (jumping the bandwagons with minds toggled off).
You can just set your blog software to truncate your feeds to a reasonable number w/o any worries. And I suggest you look at your logs, because some silly bots might be consuming your bandwith along with your normal traffic; there are some that like RSS feeds.
> I don't understand this sentence. All RSS client software is called aggregator
I'm trying to distinguish between (1) people using software the directly downloads the RSS feed from my website to their device and (2) people who use services that download the RSS feed to a server which can then serve a cached copy of the posts to many users. If everyone used (2), then I would only have my RSS file downloaded as many times as there are separate services, which is not very many. So apparently many people are doing (1), and if my feed is short then they are limited in the blog history they can read to how long they've personally been subscribed (or less, if they need to clear their device and can't re-download my old posts).
> Not really. Many websites which are essentially blogs are transforming themselves into single-page web apps
That's why I specified "But sites that can have an RSS feed...". If you have an RSS feed with useful posts in the feed, then you must be delivering static pages. (If you're just delivering snippets with links to a dynamic page, then there is no way for any service to cache the page either.) So my question is: why isn't there software to scrape webpages of blogs that offer an RSS feed with complete posts? This would enable me to comveneiently read post history going back more than 10 posts.
> And I suggest you look at your logs, because some silly bots might be consuming your bandwith along with your normal traffic; there are some that like RSS feeds.
All the bots put together make up 27% of my bandwidth. It's a lot, but it's not the root cause.
> So apparently many people are doing (1), and if my feed is short then they are limited in the blog history they can read to how long they've personally been subscribed (or less, if they need to clear their device and can't re-download my old posts).
RSS is a means for people to follow new posts from you, in order to read new posts they are supposed to come to your blog and use your archives.
Yeah, but for my case it means waiting 10 seconds per link, and another 10 seconds when returning to the initial page, which has some 20 entries, and there are more than ten such pages that I need to scrape, so I passed on that...
“This insanely unnecessary bandwidth usage penalizes sites that have long (>10) feeds with complete posts.”
Since rss is text only the sizes are very small and compress well. Considering the average web page is 3M[0], pulling down 10-100k of every post ever doesn’t matter. And http takes care of not pulling the same file over and over.
It’s certainly a downside, but completely useable as is, and better than any viable alternative.
As far as standards go, I prefer simple, static file, over something requiring dynamic response.
There’s also nothing stopping the site from limiting the RSS feed to only 5 posts with a link for full.
Even better: instead of serving the generated for, point your RSS subdomain to your favourite CDN and only update your files when the site changes. That's likely to save you some money.
> Since rss is text only the sizes are very small and compress well. Considering the average web page is 3M[0], pulling down 10-100k of every post ever doesn’t matter.
My web pages are 100k and my RSS feed is 500k.
> It’s certainly a downside, but completely useable as is, and better than any viable alternative.
It doesn't fulfill the need I originally mentioned: making blog archives readable offline.
> As far as standards go, I prefer simple, static file, over something requiring dynamic response.
I agree static is better, but a dynamic response isn't necessary. You could just have a static file that listed all the blog posts, with a link to another static file for each post. This avoids having the user download 10 blog posts each time they want to poll if something new has happened.
They only show a snippet because they can't sell your eyeballs via the RSS feed. They need just need to drsw you to click onto their full site to blast you with ads.
If I may add mine: https://www.pipes.digital/. It allows creating feeds for sites if the site is structured enough, and the feed can then manipulated with other blocks, similar to how Yahoo Pipes worked.
Feedback is always welcome (and subscribers even more ;) ), you can also send me a mail (in profile) or follow the way described in the docs to reach me (https://www.pipes.digital/docs#support).
Marketing is a powerful force. It's true that RSS has existed for many years, but also consider how many people have grown up without learning about it.
That's because rendering JS/CSS/whatever has become the norm. It has become the norm for two reasons: tooling for building "static" sites with this technology has gotten very popular and well-done, and sites with a vested (advertising/lockin) interest in showing their content "their way" have jumped on board.
* Shameless plug *: Our little startup, Feedity - https://feedity.com, helps create custom RSS feeds for any webpage, via an online feed builder and REST API.
Custom feeds can even be created for dynamic content, utilizing Chrome for full-rendering, and many other tweaks & techniques under the hood for seamless & scalable indexing.
If you don't mind writing a bit of Python glue code, you can also use https://github.com/nblock/feeds (I'm one of the authors). It uses Scrapy under the hood and is supposed to run as a cronjob. It will create full text Atom feeds of whatever data you will feed to it. Spiders (plugins) are usually quite small, especially when there is no login (paywall) involved: https://github.com/nblock/feeds/tree/master/feeds/spiders
Just a friendly PSA that WordPress comes with RSS feeds enabled by default. Since an overwhelming majority of content websites use WordPress, I think it's safe to say RSS is still widely available. Try going to your favorite blog and append "?feed=rss2" to the end of the URL. Like so:
I've never used an RSS reader so correct me if I'm wrong, but RSS can basically allow you to read the content without advertising? Sharing is fine, but I think they would prefer sharing in a way that can make money.
I use RSS/Atom to keep up-to-date on the 100+ webcomics I read, and the content in those feeds can vary wildly. Some include the full comic page, some only a thumbnail, some contain an accompanying blog post, others are empty and you need to follow the link to see the post.
If you want to read everything in your feed reader, those "incomplete" feeds are disappointing, but I just use it as a kind of newsletter to get notified of updates. I even use Thunderbird's built-in feed support.
Most feeds only contain "excerpts" - which require you to visit the website to read the entire article. Thankfully, "reader mode" exists. Ads are also entirely possible, but not commonplace.
Nearly every site I visit on a regular basis, HN, Reddit, YouTube, has RSS feeds. Granted, they're link only feeds, but that's far better than having to create an account just to get an inferior "subscription" experience or having to re-scan over things I've already read and ignored.
* Allows items on that feed (from all the sources) to be earmarked
* At the end of reviewing the unread items of the feed, summarise a 'checkout' of earmarked items
* Sends a payment to each of the publications for the content earmarked
* Compiles the content into a consumable format such as kindle, PDF or download for mobile
I can only think of instapaper/pocket type services that don't allow for payment, or for browsers like Brave that use blockchainy things that seem new and scary. Or are just RSS readers.
Pretty much my thoughts: if you want RSS to live, turn it into the platform for content micropayment. If you just want it to be a better adblocker, don't act surprised if nobody wants to play along.
The thing that bugs me about the Feedly website is that it doesn't really feel like a RSS reader, at least on the free service. Maybe the paid version is (much) more customizable but I doubt it. It reminds me more of Flipboard.
Edit: It's tailored to marketing people so I think that's why.
You might want to try NewsBlur.com - it's quite similar to how Google Reader used to be. It has a free version (64 RSS feeds) and a paid version (unlimited feeds).
(I remember trying Feedly when Google Reader died, but ended up going with NewsBlur instead.)
I switched to inoreader.com when Google Reader went away. Not the best but it works for me, a tad slow to load the first time.
I tried Feedly but gave up when their nginx LB timed out after a minute because my OPML import was a big file. Plus, the interface does not feel like an RSS reader, as somebody else points out.
I use the Feedly iOS app - never used or even seen the website. What I like about the app, is the "all done!" message at the end of your daily feeds. It's a nice reminder/poke to get off the phone and get on with life.
Question: why am I constantly hearing about RSS and never Atom? Isn't Atom newer and supposedly better? Are the two basically interchangeable, or did Atom never catch on enough that people want to revive it?
I think it's a situation sort of like with SSL and TLS, where the former term implies the latter. I mean, it's not rare to find people using the term "SSL Certificates" even on TLS-only setups. Also:
Not the guy, but one reason to avoid ubuntu snaps is that it is designed not to allow users to have complete control over software updates. With snaps, the developer controls the update process, not the user.
Some people believe that the user should have the final say in what his or her system does. Snap goes against this. It's a great project otherwise.
I'd add to that a general dislike of the "splitter" attitude taken by Ubuntu. Unity vs Gnome, Mir vs Waylaid, now Snap vs Flatpak. The latter works well, the former doesn't improve in any meaningful way. Why fragment?
In terms of technology, it's a dog. Beyond the problems associated with malformed XML, and crazy namespaces (I once went through several hundred thousand feeds and found over 100 different tags), the process of polling for new content is inefficient and wasteful. I recently moved my personal blog from one server to another and was amazed at the amount of bot traffic I get - over 5 years after I stopped blogging regularly.
In terms of business sense - why would a publisher ever want to create an RSS feed in the first place? I'm still surprised they bother. RSS feeds don't drive sufficient traffic to justify their existence, and allows easy copying/republishing. There's zero financial incentive.
I'm a news junkie and loved blogs in their heyday, but those days are over and they aren't coming back.
I don't understand why you would ever want this to be a desktop app. Try FreshRSS[1], it's awesome. It works well on shared hosting and it runs on SQLite.
TTRSS only gave me trouble. Threw all kinds of strange errors at unexpected times. I don't know how many times it died on me after an upgrade. I eventually gave up and found FreshRSS. Been running (and updating) it over a year, without a single problem.
One of the best things about it is escaping the algorithmically curated feeds.
Every and service that I use has an RSS feed, except for Twitter. I use https://twitrss.me/ to follow users. If you don't find a feed, sometimes you just have to dig a little. You learn at which URIs the most commons CMSes presents their Atom/RSS feeds (hello /feed/).
I forgot all about Netvibes.com! I remember setting up a personal dashboard with my emails, news, Digg, etc way back in ~2006. It may very well have been my first foray into RSS, now that I think about it...
100% agree with self-hosting an RSS aggregator. It's awesome.
Personally, I gave tt-rss and FreshRSS a shot, but went back to Miniflux[1]. One binary to run (written in Golang) and
plugs into Postgres. Easy to set up, but I prefer Miniflux for the same reasons I prefer Hacker News' website—simple and functional.
Fun fact, Stream is almost entirely written in Go. Winds is based on Node/React. I think it's nice as it enables more people to contribute. (everyone knows JS)
Since I'm considering to switch from TTRSS to something else, may I drill a bit? (the website is a tad short)
I heavily rely on nested categories in TTRSS (Youtube -> News for news channels for example), while the website says it has categories, can they be nested?
And most importantly, does miniflux handle about 700 feeds well? It would help a lot if I could lower the update rate of some feeds that only update once a month...
No nested categories. They're all flat. Miniflux is ultra minimalist and "opinionated," which I ended up preferring to all the others. YMMV! If you're looking for a ton of features or customization, look elsewhere.
It's also wicked fast, resource-light, and the code is really easy to grok if you want to hack in anything. But, the update rate is a single global setting[1]. I wouldn't be surprised if it could handle far more than 700 feeds... you'll hit bottlenecks from bandwidth or the DB before anything with the app.
>YMMV! If you're looking for a ton of features or customization, look elsewhere.
I don't need much customization, I simply rely on a lot of features for daily convenience. Either way, it seems good enough and I might be able to work around it (or submit a patch if I'm not lazy).
Update rate is merely a concern because I don't want to spam some hosts with repetitive updates for no reason, might be worth another patch.
Way way too complicated, needs a setup and configured postgres install, why use an RDBMS when it could have embedded sqlight and avoided all that sysadmin stuff
Agreed, this seems like a perfect fit for SQLite. It's not like you need massive concurrency, and you would have avoided all this administrative burden. Too bad, that's literally the only reason I chose not to try it. FreshRSS seems very nice too, but is also a hassle to deploy (what with apache/nginx and a bunch of requirements).
Deployment difficulty is why I wrote my own: https://github.com/rcxdude/nobsrss . It's super easy to deploy, but it's super minimal (unlike the way a lot of people seem to use RSS, I just use it for notifications, so all I need is a link to the actual website).
Huh, that's pretty cool, although I'd like it if it marked items as read when I clicked on them. You can easily achieve that by adding a URL route to read an item, and when a user visits that, you mark it as read and redirect to the real URL.
The TwitRSS thing sounds awesome. It would be pretty easy to setup a web hosted version of Winds so people can access it however they want. Anything you particularly like about FreshRSS?
> I don't understand why you would ever want this to be a desktop app.
Perhaps because the vast majority of people in the world have no interest in figuring out web hosting so they can read some news articles. That doesn't seem like a viable way to "bring back RSS".
Exactly. And a lot of people still spend tons of time in what amounts to a standard desktop environment. I switched from cloud audio players to QMMP and have been looking to do the same with RSS.
It seems likely that the average user (that has no interest in figuring out web hosting) will still want to use software/service that works across devices (just like everything else works these days). For those users there's https://newsblur.com/ and similar services.
> I don't understand why you would ever want this to be a desktop app.
I thought you were going to say that it needs to be a website+mobile app for maximum adoption, and I was ready to say that you have a point but full-weight desktop apps still have their place. Then I looked up FreshRSS, and it's an aggregator that you host yourself?
Any answer to the question "how can we get more regular users to adopt a service" that starts "first, they all need to install Apache..." is very doomed.
Isn't Apache installed by default on at least all desktops nowadays? Obviously, people should be expected to tinker with httpd.conf, but something fully automated running on top of Apache isn't beyond imagination - and the installation could even be handled automatically if required.
https://readkitapp.com/ is still a much better client in my opinion. For now Cappuccino can't even load the entire article in cases when feed has only an excerpt.
> TTRSS only gave me trouble. Threw all kinds of strange errors at unexpected times. I don't know how many times it died on me after an upgrade.
Counterpoint: I never had any issues with it and updates are just git pull, maybe login with the admin account for db migration, restart the update daemon, no issues at all.
Same here. Some years ago I switched from Thunderbird on several machines to a self-hosted TT-RSS that vastly improved my (professional) RSS feed browsing. Some minor annoyances with the scrolling when the RSS items are long but overall great experience.
> Every and service that I use has an RSS feed, except for Twitter.
I use https://feedbin.com as a RSS backend to any client I can imagine (Reeder on iOS in my case). Feedbin recently introduced a feature that treats and presents twitter searches/users/tags as RSS feed and extracts media and links in tweets. Right along all your other RSS feeds: https://feedbin.com/blog/2018/01/11/feedbin-is-the-best-way-...
I'm not sure what this non-native application is offering me over plenty of Mac (and presumably Linux & Windows) native versions using way less memory and having platform-native UI controls.
RSS's challenge has never been apps, it's support from publishers to keep using open formats.
I'd also say a large part of its issue is lack of internal consistency of the format itself. Firstly there are the various official RSS versions, then there are all those Atom things and probably others as well, and then there's the thing about how you're supposed to render the things correctly. XML as the content format is also pretty much antiquated.
A modern format would no doubt have to be JSON- or YAML-based and have its human-readable content in plain text or markdown, so it'd have to be pretty much readable with a plain text http client, like curl.
So, just let RSS die the slow death it's been going through for good reasons and bring something consistent and straight-forward into its place. Something that you could easily generate and parse from any modern language without specific libraries.
Bringing RSS back is like trying to bring SOAP as a RPC system back; it just won't fly anymore no matter how much hot air you try to pump into it. We know better now and have better ways to do the things.
Two words: News. Blur. I have been using https://newsblur.com for years now (ever since Google Reader died) and am not switching to anything else soon.
I've also been a happy user of NewsBlur since then. I use the paid option ($36/year), which gives you unlimited RSS feeds. There's also a free option that gives you up to 64 feeds.
They have both a web app and mobile (iOS/Android) apps.
Yea, I'm thrilled with NewsBlur. Significantly happier than I even was with Google Reader, plus it's open source, plus the dev is fairly steadily introducing well-thought-out features (like highlighting articles from infrequent posters).
I did exactly the same thing. I tested quite a few services on the downfall of Google Reader and stuck with Newsblur ever since.
I cannot think of any other service that works as smoothly as Newsblur and provides me with exactly what I need; keyboard shortcuts, good mobile clients, open source, decently priced, constant improvements.
I have far too many feed items to read. I'd like to review ~1,000 items in 20 minutes, as a start. (Review means: Read the headline, possibly read the summary, decide whether to read the full story, do whatever is needed to open full story, move to next item; I'll read the full stories after I've gone through all the feed items.)
* Deduplication: Which might remove ~5% of my feed items
* Grouping: This would be by far the most important feature. I need something to group articles covering the same story (e.g., all the news publications' stories on the big game or big speech or big calamity last night). Then I can quickly choose one and ignore the rest.
* Speed: UI that responds at the speed of thought and maximizes throughput when reviewing feed items. A keyboard interface is essential.
* Complex filters: So I can automatically process items as desired.
* EDIT: Automate handling of broken feeds: On one hand, I want to spend as little time on broken feeds as possible; perhaps the reader can retry for x hours, then try obvious alternative addresses (perhaps Stream can maintain a db of the new addresses, saving each user from redundantly solving the problem themselves), then notify me with an efficient interface for resolving the problem.
* Micropayments: Maybe over-ambitious, but it would be a great way to support the authors. A possibly world-changing feature.
The whole rss is dead -> long live rss narrative has been an eye-opening experience for me in terms of practically illustrating just how powerful and influential the news is on technological development. Engineers can apparantely be a lot more easily manipulated than what I previously thought. (I'd argue we never knew whether or not RSS was dead because it was based on small and skewed sampling biases.)
For websites I want to follow that don't provide an RSS feed I wrote a 30 line python script which runs in daily cronjob and creates me an an XML feed that I can import locally in my reader (newsboat). Easy and it works great.
I'm surprised rss2email (or something similar) has hardly been mentioned. Getting your RSS in your email makes a surprising amount of sense. You can filter, organize and archive it. You can search it. You can mark it read or put flags on it. You can forward it to friends if that's your thing. And it works everywhere you have an email app.
I also have small scripts that run as cron jobs and scrape a few Twitter feeds and a few subreddits and email new items to me.
Having all my updates in one place I can consume in one place when I want is just great.
I'm not sure what I'd get out of Winds looking at it.
The thing I most hated about RSS readers was they treated it like email (or even old-style newsgroups), assuming you cared how many articles you hadn't read.
Nope, most of it's news (whether tech or some other kind), and the social media stream kind of access (where you care about what's current, but if you missed it so what) seems a lot more appropriate.
I mean, if you want to support that kind of view, you could certainly just purge anything more than 10 articles old or whatever from the RSS feed from your inbox.
We probably just use these things differently though. Like, if a product I'm interested in gets reviewed I want to see that -- I don't want to have to go search the website later because maybe it was reviewed but I wasn't hovering over my RSS feed the hour or two it was the top story.
Basically, it completely replaces the website's front page for me, and if I have to go there I've failed.
never used it before but I imagine it wouldn't work well with hundreds of updates everyday? Plus centralized feed management is easier with an RSS service like Feedly. I don't want to scour through all my mails for my feeds, as if it wasn't hard enough keeping with mailing lists already.
It would work fine, mail servers and clients are damn comfortable handling those numbers.
I suppose it'd be easier if you never want to have any files to back up, but I already do (emails themselves, git repos, various databases) so storing the rss2email configuration is nothing extra for me.
You can setup filters to put the stuff from RSS in whatever folders you want. By feed itself. By author. By keyword. Just like any other email. I use Sieve with Dovecot/Pigeonhole but any decent hosted mail service should provide something similar.
Interesting. I'm on the total opposite end... I'd rather have "email2rss" for turning all the spam/newsletters into a feed. I don't want _any_ of that content entering my email.
I recommend Kill the Newsletter[1]. It gives you an email address that you can send all your subscriptions into, and an RSS feed to consume it.
Couldn't you just filter those newsletters into a folder? I'm not sure how making it RSS is materially different.
Hardly anything I described here goes directly into my inbox, to be clear. That would drive me crazy (I rarely have more than a dozen emails in my inbox -- all things that I need to somewhat immediately need to be act on).
Sure. Probably would work well with name+newsletter@example.com type filters.
I just like to keep them separate, I suppose. And, I just naturally prefer to consume news through RSS feeds. Every newsletter or RSS feed I read is ephemeral, disposable, and I probably only ever read 1% of the content (if that). Email (for me) tends to be the near opposite, and anything I can do to keep the noise and cruft out of my email, I'll do.
302 comments
[ 6.6 ms ] story [ 319 ms ] thread> Powered By: Stream, Algolia, MongoDB, SendGrid, AWS
My feed reader is an old PHP script running on a NUC.
For what it's worth, I've been pretty happy with FreshRSS (https://freshrss.org/)
Disclaimer: I work at Stream (but haven't really worked on Winds)
If each of those services has an outage once a year, you'll get to feel all of them.
Compare to tt-rss: if your own web server and database are running (and there's an internet connection), it's working.
Meanwhile, obtaining anything over 99.9% is usually a challenge for the amateur. Even if you are on call on every day of the year, it's very easy to go to sleep with your phone muted and wake up the next morning to discover the service is down for whatever reason.
To me, self-hosting means I can (theoretically) run everything I need, on my bare-metal -- a cloud provider or cloud service (eg, RDS) then becomes a choice, not a requirement.
Suppose you swapped out every piece with a free, local one -- it'd still have the problem of being way overdesigned for what I'd need. Even if the UI looks decent.
It makes me sad to have to settle for Liking a company's FB page, since it's up to FB whether or not I ever see it.
[1]: https://mail.google.com/mail/u/0/feed/atom/
Most blogs that I visit will highlight the RSS ("Subscribe to this page") icon in Firefox's icon bar. (The RSS icon is not present by default, but you can add it via the Customize dialog.)
For Chrome, there might be extensions that implement similar RSS auto-detection functionality.
It was esentially as meaningfull as OPs reply.
Ofcourse, the point of "this app should run in a browser" is very valid. The reply, he can just code it himself is in my eyes a passive aggressive way of saying "no, i said your point is valid, but actually think it isn't and therefore ill ignore it anyway."
Its obvioulsy, that a well developed web app should be runable in a browser and the developers could have thought about it earlier. They know their project better than anyone, so the afford of understanding how this piece of software works for an outsider is way to high.
"Your app runs based on technologies that mean you could easily port it to windows. But it doesn't run on windows? Downvote!"
"Your app runs on windows, but it's built on technologies that allow it to run anywhere else; why does it only run on windows? Downvote!"
See the pattern? Saying "I don't like your entire contribution because it doesn't run on a given platform on which I think it COULD run" is counterproductive and at best pointless; at worst rude.
I'm sure you could have made the point more thoughtfully, in which case it would both have been clearer and not damaged HN in the process.
I quite like desktop programs still, but I expect everything to be stored locally and not to need an account. I had hoped for a KeePass style db file that I could sync on Dropbox or something, but the last thing I need is more accounts and my data on some randoms server that could be taken down when they get bored, or run out of money/motivation.
Do they support RSS in their service, and if so does this product use their service for RSS feed polling, etc.?
Can't display a feed that doesn't exist!
https://api.fwdeveryone.com/user/inbox.atom?username=Alex391...
After that introduction I was hoping Winds would be some kind of proxy that creates an RSS for sites that don't have one. But well, it's just another RSS reader. Those have actually never gone way, I'm using Inoreader every day.
Not aware of any anti-user-made RSS laws, though.
(DMCA doesn't count, it's about circumventing things that prevent you from copying, not change your consumption.)
Note that many/most WordPress RSS feeds aren't that useful because they only show a snippet rather than the entire post. This dreary state of affairs is due in part to the fact that "checking" an RSS just means downloading the entire file containing all posts the author would like to make public, regardless of how many are new to the reader. This insanely unnecessary bandwidth usage penalizes sites that have long (>10) feeds with complete posts. (The single RSS file on my blog takes up the majority of my bandwidth costs.)
RSS needs to be replaced, not revived.
On the other hand, if you want to say that your client supports this supposed RSS-ng standard they need to support those new features because they're part of the protocol.
This is to say, I don't like protocol extensions, but that's just me :)
You'll find your feed readers aren't particularly impressed, though.
The good news is that means you don't have to wait. You can write that now. It will work on existing RSS feeds, just not quite as optimally for your proposed use case as you might personally like, but it will still work. It will work even better on yours, which will also work in conventional RSS readers.
Now, you might have problems getting "the real page content" from your URLs, but that's a separate problem. (History strongly suggests the large-scale content producers would actively fight you if you try, because you'll probably be trying to strip their ad revenue either deliberately or accidentally as part of what you'd be doing. Which is, after all, the reason why RSS is already not terribly favored by that crowd and why they want you in closed gardens of their own devising... unfortunately getting around this problem is a great deal more difficult than hypothesizing that some sort of new standard could somehow deal with it....)
If you want to play semantics, I'm fine with rephrasing my complaint as: "We need to build on the flexible super official RSS standard -- which is little more than an XML file -- and actually agree on a way of delivering blog archives for offline reading. RSS in practice does not currently achieve this very simple goal." This is just different words to describe the same thing.
> You can write that now. It will work on existing RSS feeds, just not quite as optimally for your proposed use case as you might personally like, but it will still work.
Huh? Other website owners who would like me to be able to read their archives can modify their RSS file, but we have no agreement on how to do that in a standard way. Likewise, I could modify my RSS file, but since there isn't a standard my readers won't have software to take advantage of it.
> (History strongly suggests the large-scale content producers would actively fight you if you try,...unfortunately getting around this problem is a great deal more difficult than hypothesizing that some sort of new standard could somehow deal with it....)
The blogs I want to read offline do not have ads and do not care about this. I just want a solution that works for this simple problem, not a way to take content from people who don't want to give it to me without attaching ads.
Still, exceptionally low cost compared to running pretty much any website's massive CSS and JS files. A single image in most cases will take more than the entire RSS feed before compression.
That said, I would like to see a new standard (a new one would be needed [1]) that only gets the difference from what you last read - I think that would really take RSS feeds to new places of usefulness. There's no reason why you couldn't send the server an ID (not timestamp to avoid issues with timezones, clock stretching, forward/backward time setting, etc) of the last request and have it send back everything since (within reason).
[1] https://www.w3schools.com/XML/xml_rss.asp
Passing "the ID of the last piece of content I saw" would allow the server to return just the updated stuff, or abort early like an E-Tag. However, counterintuitively, as is often the way in computer science, I'm not sure it would be that big a win to be able to return partial content. The vast bulk of the win on most blogs will just be the ability to abort at all, provided just fine by E-Tags.
I would say that if your site is getting hammered by HTTP requests for your RSS, do double-check that you've got E-Tags set up and working correctly. It is in the best interests of the big scrapers to support that properly, as they are paying for that bandwidth too. RSS aggregators don't have to get too large before this becomes a top-priority feature request. Unless the feed is literally changing on roughly the same frequency as it is scanned, it shouldn't be the dominant factor in your bandwidth bill.
My blog has both RSS and browser readers, but the bandwidth is dominated by the RSS feed. Since the RSS file has no images (just HTML pointing to the images), I think it's more likely that for my Wordpress blog the CSS/JS overhead is just not that much (as opposed to the alternative hypothesis that I have many many times more RSS readers who never end up downloading the images).
Exceptionally low cost per hit, as opposed to overall bandwidth. Overall bandwidth will probably fair off worse as you say due to the polling nature of RSS. I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.
Also in general, I would be tempted to make an RSS feed more minimalist in terms of content and markup. It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).
>I think it's more likely that for my Wordpress blog the CSS/JS overhead is just not that much
Also, bandwidth is just one resource - potentially each call to a page is a database read, whereas your RSS feed should be static (not sure about the WordPress implementation, but I would hope for static caching with something that doesn't change for long periods of time). I've seen WordPress database lockups with modest amounts of traffic (again, most of the time this could have been easily statically cached - but doesn't appear to be by default).
> Exceptionally low cost per hit, as opposed to overall bandwidth.
I don't understand. I'm telling you that my RSS file literally dominates my bandwidth usage in GB.
> I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.
Yah! Agreed.
> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).
No, I want people to be able to read it offline. I'm not trying to monetize anything.
> Also, bandwidth is just one resource - potentially each call to a page is a database read
I have a simple website. The bandwidth is the dominant cost.
> Yah! Agreed.
You could also reduce the number of `<item>`s you keep in rotation to a more manageable number.
>> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).
> No, I want people to be able to read it offline. I'm not trying to monetize anything.
It should still be much more lightweight than it's HTML counterpart. Should be almost nothing to it, next to no markup, no styling, no scripts and a highly compressible piece of data.
I don't understand how you're racking up massive bandwidth. Can you put some numbers to it:
* Bandwidth usage for RSS
* Bandwidth usage for webpage
* Hits to RSS
* Hits to webpage
* Links for both
WRT scraping, it is getting harder because funny websites w/ no static content where everything is generated via Angular or Perpendicular or sth. are really hard to deal with. Recently my uni switched from an army of Wordpress websites to an homegrown AJAX-MVC-Reactive abomination where the links are reimplemented via some funny black magic where the actual link items (which are not anchors btw) don't have encoded in them the link targets, but only an onclick event that knows somehow where to go. And because they just killed all the RSS feeds, I wrote up sth. to revive them for me via phantomjs, but could not figure how to find the link targets, I cannot link the RSS items to anywhere but the main announcements page, and I can't add any description from the link target.
RSS should be kept, those who don't know the job they are doing should be replaced.
But people who don't use the right aggregators will not be able to read past 10 posts. And if everyone was using aggregators, I wouldn't have such a high bandwidth bill.
> WRT scraping, it is getting harder because funny websites w/ no static content.
But sites that can have an RSS feed necessarily need to deliver their content in a static form. What surprises me is that we don't have a tool for even those cases.
I do not think such aggregators exist, and you can just ignore people using software that do not comply to widespread conventions.
> And if everyone was using aggregators, I wouldn't have such a high bandwidth bill.
I don't understand this sentence. All RSS client software is called aggregator.
> But sites that can have an RSS feed necessarily need to deliver their content in a static form.
Not really. Many websites which are essentially blogs are transforming themselves into single-page web apps. My uni's websites included. Some do it for the $$$, some for reasons that I can not know (jumping the bandwagons with minds toggled off).
You can just set your blog software to truncate your feeds to a reasonable number w/o any worries. And I suggest you look at your logs, because some silly bots might be consuming your bandwith along with your normal traffic; there are some that like RSS feeds.
I'm trying to distinguish between (1) people using software the directly downloads the RSS feed from my website to their device and (2) people who use services that download the RSS feed to a server which can then serve a cached copy of the posts to many users. If everyone used (2), then I would only have my RSS file downloaded as many times as there are separate services, which is not very many. So apparently many people are doing (1), and if my feed is short then they are limited in the blog history they can read to how long they've personally been subscribed (or less, if they need to clear their device and can't re-download my old posts).
> Not really. Many websites which are essentially blogs are transforming themselves into single-page web apps
That's why I specified "But sites that can have an RSS feed...". If you have an RSS feed with useful posts in the feed, then you must be delivering static pages. (If you're just delivering snippets with links to a dynamic page, then there is no way for any service to cache the page either.) So my question is: why isn't there software to scrape webpages of blogs that offer an RSS feed with complete posts? This would enable me to comveneiently read post history going back more than 10 posts.
> And I suggest you look at your logs, because some silly bots might be consuming your bandwith along with your normal traffic; there are some that like RSS feeds.
All the bots put together make up 27% of my bandwidth. It's a lot, but it's not the root cause.
RSS is a means for people to follow new posts from you, in order to read new posts they are supposed to come to your blog and use your archives.
> it remains incredibly difficult to scrape a well-organized blog and turn it into something I can consume like RSS or a kindle book.
> Note that many/most WordPress RSS feeds aren't that useful because...
I don't think so, but maybe I missed. It is not the purpose of RSS anyways, though. RSS is for me to know when you post something new.
FTFY ;)
FTFY
Since rss is text only the sizes are very small and compress well. Considering the average web page is 3M[0], pulling down 10-100k of every post ever doesn’t matter. And http takes care of not pulling the same file over and over.
It’s certainly a downside, but completely useable as is, and better than any viable alternative.
As far as standards go, I prefer simple, static file, over something requiring dynamic response.
There’s also nothing stopping the site from limiting the RSS feed to only 5 posts with a link for full.
[0] https://speedcurve.com/blog/web-performance-page-bloat/
My web pages are 100k and my RSS feed is 500k.
> It’s certainly a downside, but completely useable as is, and better than any viable alternative.
It doesn't fulfill the need I originally mentioned: making blog archives readable offline.
> As far as standards go, I prefer simple, static file, over something requiring dynamic response.
I agree static is better, but a dynamic response isn't necessary. You could just have a static file that listed all the blog posts, with a link to another static file for each post. This avoids having the user download 10 blog posts each time they want to poll if something new has happened.
I use rss-bridge in combination with rss2email to follow instagram feeds after leaving instagram.
Custom feeds can even be created for dynamic content, utilizing Chrome for full-rendering, and many other tweaks & techniques under the hood for seamless & scalable indexing.
https://www.kill-the-newsletter.com/
(I think a fellow HN user made it? Can't remember)
http://example.com/?feed=rss2
https://chrome.google.com/webstore/detail/rss-subscription-e...
It can be configured to send the selected feed URL to your (online) aggregator of choice.
Plus Blogger [1]: blogname.blogspot.com/feeds/posts/default?alt=rss
[0]: https://help.medium.com/hc/en-us/articles/214874118-RSS-feed...
[1]: https://support.google.com/blogger/answer/97933?hl=en
If you want to read everything in your feed reader, those "incomplete" feeds are disappointing, but I just use it as a kind of newsletter to get notified of updates. I even use Thunderbird's built-in feed support.
[0] https://daringfireball.net/feeds/main
* Has a feed a la RSS readers
* Allows items on that feed (from all the sources) to be earmarked
* At the end of reviewing the unread items of the feed, summarise a 'checkout' of earmarked items
* Sends a payment to each of the publications for the content earmarked
* Compiles the content into a consumable format such as kindle, PDF or download for mobile
I can only think of instapaper/pocket type services that don't allow for payment, or for browsers like Brave that use blockchainy things that seem new and scary. Or are just RSS readers.
I use feedly now. Which is pretty good. For me having it has a web site is most useful, rather than a device oriented thing that manages feeds.
Edit: It's tailored to marketing people so I think that's why.
(I remember trying Feedly when Google Reader died, but ended up going with NewsBlur instead.)
I tried Feedly but gave up when their nginx LB timed out after a minute because my OPML import was a big file. Plus, the interface does not feel like an RSS reader, as somebody else points out.
(Not the same code path, just that a tool to work with RSS will usually end up also supporting ATOM and vice-versa.)
[0]: http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared
https://wiki.openssl.org/index.php/Libssl_API
> libssl is the portion of OpenSSL which supports TLS
It's for TLS support yet they call it "libssl".
So yeah, you can just mentally replace "RSS" with "RSS/Atom" and most of the time it'll be fine.
Some people believe that the user should have the final say in what his or her system does. Snap goes against this. It's a great project otherwise.
See: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
In terms of technology, it's a dog. Beyond the problems associated with malformed XML, and crazy namespaces (I once went through several hundred thousand feeds and found over 100 different tags), the process of polling for new content is inefficient and wasteful. I recently moved my personal blog from one server to another and was amazed at the amount of bot traffic I get - over 5 years after I stopped blogging regularly.
In terms of business sense - why would a publisher ever want to create an RSS feed in the first place? I'm still surprised they bother. RSS feeds don't drive sufficient traffic to justify their existence, and allows easy copying/republishing. There's zero financial incentive.
I'm a news junkie and loved blogs in their heyday, but those days are over and they aren't coming back.
TTRSS only gave me trouble. Threw all kinds of strange errors at unexpected times. I don't know how many times it died on me after an upgrade. I eventually gave up and found FreshRSS. Been running (and updating) it over a year, without a single problem.
One of the best things about it is escaping the algorithmically curated feeds.
Every and service that I use has an RSS feed, except for Twitter. I use https://twitrss.me/ to follow users. If you don't find a feed, sometimes you just have to dig a little. You learn at which URIs the most commons CMSes presents their Atom/RSS feeds (hello /feed/).
[1] https://freshrss.org
Personally, I gave tt-rss and FreshRSS a shot, but went back to Miniflux[1]. One binary to run (written in Golang) and plugs into Postgres. Easy to set up, but I prefer Miniflux for the same reasons I prefer Hacker News' website—simple and functional.
[1] https://miniflux.net/
I heavily rely on nested categories in TTRSS (Youtube -> News for news channels for example), while the website says it has categories, can they be nested?
And most importantly, does miniflux handle about 700 feeds well? It would help a lot if I could lower the update rate of some feeds that only update once a month...
It's also wicked fast, resource-light, and the code is really easy to grok if you want to hack in anything. But, the update rate is a single global setting[1]. I wouldn't be surprised if it could handle far more than 700 feeds... you'll hit bottlenecks from bandwidth or the DB before anything with the app.
[1]: http://docs.miniflux.net/en/latest/configuration.html
I don't need much customization, I simply rely on a lot of features for daily convenience. Either way, it seems good enough and I might be able to work around it (or submit a patch if I'm not lazy).
Update rate is merely a concern because I don't want to spam some hosts with repetitive updates for no reason, might be worth another patch.
This is the big reason I chose FreshRSS. PHP and SQLite works great on cheap/shared hosting and is portable.
Perhaps because the vast majority of people in the world have no interest in figuring out web hosting so they can read some news articles. That doesn't seem like a viable way to "bring back RSS".
I thought you were going to say that it needs to be a website+mobile app for maximum adoption, and I was ready to say that you have a point but full-weight desktop apps still have their place. Then I looked up FreshRSS, and it's an aggregator that you host yourself?
Any answer to the question "how can we get more regular users to adopt a service" that starts "first, they all need to install Apache..." is very doomed.
Also, regular users tinkering with httpd.conf? Really?
* Interface is native,
* Free, with some (paid) premium options,
* 3 visualization options (preview, web, browser),
* Import and export your OPML configuration,
* Native desktop notifications,
* Premium daily email summaries,
* Premium push notifications.
It was also recently released on May 7, 2018.
[1] http://cappuccinoapp.com
Not free, but no subscription either.
Counterpoint: I never had any issues with it and updates are just git pull, maybe login with the admin account for db migration, restart the update daemon, no issues at all.
To me Twitter is an RSS feed—at least this is the way I use it.
I use https://feedbin.com as a RSS backend to any client I can imagine (Reeder on iOS in my case). Feedbin recently introduced a feature that treats and presents twitter searches/users/tags as RSS feed and extracts media and links in tweets. Right along all your other RSS feeds: https://feedbin.com/blog/2018/01/11/feedbin-is-the-best-way-...
I think it's a brilliant addition to the service.
RSS's challenge has never been apps, it's support from publishers to keep using open formats.
A modern format would no doubt have to be JSON- or YAML-based and have its human-readable content in plain text or markdown, so it'd have to be pretty much readable with a plain text http client, like curl.
So, just let RSS die the slow death it's been going through for good reasons and bring something consistent and straight-forward into its place. Something that you could easily generate and parse from any modern language without specific libraries.
Bringing RSS back is like trying to bring SOAP as a RPC system back; it just won't fly anymore no matter how much hot air you try to pump into it. We know better now and have better ways to do the things.
RSS is not dead.
They have both a web app and mobile (iOS/Android) apps.
Glad to pay for it to keep it running.
I cannot think of any other service that works as smoothly as Newsblur and provides me with exactly what I need; keyboard shortcuts, good mobile clients, open source, decently priced, constant improvements.
What other problems do you currently have with your RSS readers and Podcast apps?
Anything in particular that you're missing?
* Deduplication: Which might remove ~5% of my feed items
* Grouping: This would be by far the most important feature. I need something to group articles covering the same story (e.g., all the news publications' stories on the big game or big speech or big calamity last night). Then I can quickly choose one and ignore the rest.
* Speed: UI that responds at the speed of thought and maximizes throughput when reviewing feed items. A keyboard interface is essential.
* Complex filters: So I can automatically process items as desired.
* EDIT: Automate handling of broken feeds: On one hand, I want to spend as little time on broken feeds as possible; perhaps the reader can retry for x hours, then try obvious alternative addresses (perhaps Stream can maintain a db of the new addresses, saving each user from redundantly solving the problem themselves), then notify me with an efficient interface for resolving the problem.
* Micropayments: Maybe over-ambitious, but it would be a great way to support the authors. A possibly world-changing feature.
It’s such an unfornutate trand.
I also have small scripts that run as cron jobs and scrape a few Twitter feeds and a few subreddits and email new items to me.
Having all my updates in one place I can consume in one place when I want is just great.
I'm not sure what I'd get out of Winds looking at it.
Nope, most of it's news (whether tech or some other kind), and the social media stream kind of access (where you care about what's current, but if you missed it so what) seems a lot more appropriate.
We probably just use these things differently though. Like, if a product I'm interested in gets reviewed I want to see that -- I don't want to have to go search the website later because maybe it was reviewed but I wasn't hovering over my RSS feed the hour or two it was the top story.
Basically, it completely replaces the website's front page for me, and if I have to go there I've failed.
I suppose it'd be easier if you never want to have any files to back up, but I already do (emails themselves, git repos, various databases) so storing the rss2email configuration is nothing extra for me.
You can setup filters to put the stuff from RSS in whatever folders you want. By feed itself. By author. By keyword. Just like any other email. I use Sieve with Dovecot/Pigeonhole but any decent hosted mail service should provide something similar.
I recommend Kill the Newsletter[1]. It gives you an email address that you can send all your subscriptions into, and an RSS feed to consume it.
[1]: https://www.kill-the-newsletter.com/
Hardly anything I described here goes directly into my inbox, to be clear. That would drive me crazy (I rarely have more than a dozen emails in my inbox -- all things that I need to somewhat immediately need to be act on).
I just like to keep them separate, I suppose. And, I just naturally prefer to consume news through RSS feeds. Every newsletter or RSS feed I read is ephemeral, disposable, and I probably only ever read 1% of the content (if that). Email (for me) tends to be the near opposite, and anything I can do to keep the noise and cruft out of my email, I'll do.