[HN Gopher] Built to Last - RSS, HTTP (2015)
___________________________________________________________________
Built to Last - RSS, HTTP (2015)
Author : mrzool
Score : 96 points
Date : 2021-09-08 15:04 UTC (7 hours ago)
(HTM) web link (blog.theoldreader.com)
(TXT) w3m dump (blog.theoldreader.com)
| jcelerier wrote:
| > It is a single, elegant standard for distributed systems.
|
| is this some elaborate parody
| gego wrote:
| tiny-tiny RSS ftw
| pletnes wrote:
| Are there even any great RSS readers anymore? I sure would like a
| nice win+linux FOSS reader with a snappy keyboard based UI. Or
| something.
| tomjen3 wrote:
| I used Thunderbird for a while, then I switched to newsblur
| (paid, but cheap) so that it would fetch articles even when my
| computer wasn't on and so that I could access it on my phone.
| cpach wrote:
| NetNewsWire and Vienna are two nice options but unfortunately
| only for macOS. Here are some other suggestions for Linux,
| haven't tried them though:
| https://alternativeto.net/software/vienna/?platform=linux
| pletnes wrote:
| I felt like I lost RSS altogether after my macbook died,
| years ago - Vienna is one of the greatest macos apps out
| there. Or was, >5 y ago.
| divbzero wrote:
| Feedbin, which is currently a backend option for NetNewsWire,
| also has a web-based UI that works on any OS. [1]
|
| [1]: https://feedbin.com/
| CarelessExpert wrote:
| These days the best-of-breed are all web-based, which is fine
| by me since it's web-based content I'm reading, anyway.
|
| I personally run tt-rss and I quite like it precisely because
| it's light, fast, has good keyboard shortcuts, and has a solid
| Android app.
|
| I used to use Feedly and it's also an excellent option if
| you're not into hosting your own infrastructure.
| asdff wrote:
| I've used almost all of the readers, web and software based,
| and ended up settling on newsboat. You can set up a url
| handler script that throws links at appropriate viewers (like
| mpv for youtube videos, rtv for reddit threads) and it ends
| up being pretty seamless and fast. No mobile of course which
| I don't mind, but you could just export your feed list and
| use another rss reader for that if you really needed your
| feeds on your phone too.
| netghost wrote:
| I wrote an RSS reader named Brook that's open source, runs on
| Firefox, and keeps all your data local, so you don't need to
| rely on a service that might disappear.
|
| There's little or no keyboard support at the moment, but if
| you're interested in helping to either develop or make some
| suggestions, I'd be up for improving it! Plugin:
| https://addons.mozilla.org/en-US/firefox/addon/brook-feed-re...
| Source:
| https://outgoing.prod.mozaws.net/v1/08a450f6d21388f6bfc51f2b...
| mrzool wrote:
| I use Miniflux and I'm very happy: https://miniflux.app
|
| There's a paid hosting version that's only $15/year.
| asdff wrote:
| Newsboat
| APock wrote:
| I use InoReader, its essentially google reader in all the ways
| that (used to) matter
| stepri wrote:
| If you are on Mac / iOS, try https://reederapp.com. Can sync
| with several RSS services or sync with iCloud
| h0p3 wrote:
| You should try https://fraidyc.at/. It's a unique tool.
| def_true_false wrote:
| The article is literally from someone who makes one?
| lwhsiao wrote:
| I used to use InoReader and Miniflux, but have since moved to
| newsboat (https://newsboat.org/) and love it.
| mercutio2 wrote:
| If you're an Apple user, NetNewsWire [0] is back, open source,
| with iOS and macOS clients that sync with a variety of servers,
| now including zero-configuration iCloud sync (which is what I
| was waiting for).
|
| Works great, fast, clean, simple. Highly recommended.
|
| Disjoint set of platforms from the ones you mention in your
| second sentence, though.
|
| [0] https://netnewswire.com
| poetaster wrote:
| Use a plugin in claws mail and another in FF. Linux. I maintain
| Tidings for sfos.
| gumby wrote:
| I haven't found one. The features I really need are: - decent
| filters, portable across all clients (macos + iOS for me) -
| reader mode - shared read/unread/starred (i.e. keep even if
| read) state - ad blocking works
|
| I don't really like in-browser but could tolerate it if it
| could do all of the above
|
| I use ReadKit on the Mac (has filters, but local to the client)
| and Reeder on iOS. I am using FeedWrangler as the back end; its
| filter language (at least as documented) is unfortunately
| inadequate for my needs. Otherwise it's been fine.
| tjohns wrote:
| Personally, I use feedbin.com on the web, and Reeder on the Mac
| destkop (which optionally syncs to Feedbin's API).
|
| Unfortunately neither meet your Win/Linux requirement, but just
| pointing out there are some excellent options out there.
| Isthatablackgsd wrote:
| There are quite a few RSS out there. The list below is
| standalone including self-hosting software.
|
| QuiteRSS (Win,Mac,Linux), RSSOwl (Win,Mac,Linux), RSS Guard
| (Win,Mac,Linux), Ravens.js (electron), TT-RSS (self-hosting),
| FreshRSS (self-hosting), LifeRea (Linux only), Arss (macOS).
|
| If you are fine with self-hosting, then I recommend getting
| FreshRSS over TT-RSS and FreshRSS have support for RSS Bridge
| which will make FreshRSS a powerful tool. I prefers FreshRSS
| because I can set it up in my XAMP easily, TT-RSS moved to
| Docker only. Also FreshRSS provide their RSS feed API for other
| RSS software to hook into it. So you can use mobile app with
| FreshRSS feed directly to it.
| edsimpson wrote:
| I have been looking for a good windows rss reader for a
| while, Ravens.js looks pretty solid. Thanks for the tip.
| russellbeattie wrote:
| Problems with RSS:
|
| 1. Inconsistent implementation of standards: The implemented
| versions of RSS and Atom out there makes parsing more of an art
| than just throwing a library at it as no RSS parsing library out
| there can handle all the edge cases. (The last time I did a test
| a few years ago in an hour long sample from one of the RSS
| firehoses out there pulled up hundreds of custom namespaces and
| tag names.)
|
| 2. XML formatting: Consistently formatted, well formed XML is
| never 100%, even from by major news organizations. Embedded CDATA
| means parsing content is a quagmire of double escaping.
|
| 3. Inconsistent content: A RSS feed could just have the last few
| items that have been updated, with just titles or links, or it
| could be literally all of the content of a blog, jammed into some
| 20MB+ text file, double escaped and simply enlarged after every
| new update.
|
| 4. Inconsistent unique identifiers and HTTP header responses:
| Many sites will respond appropriately to requests with a 304 if
| there are no changes. Many will not. Many sites will give each
| RSS item a globally unique identifier, many will not. This forces
| every Reader to simply request the whole doc over and over again,
| comparing unique items with a blend of logic and magic.
|
| 5. Inconsistent support: Most sites that use RSS have no business
| model attached to it, so it's just sort of an afterthought and
| may be shut down at any time, and often is.
|
| All this leads to: Massive amounts of wasted bandwidth as bots
| poll endlessly for updates, wasted processing time parsing
| unformatted or badly formatted content, wasted storage because of
| bad IDs and URLS, wasted effort on the user's part dealing with
| the inevitable errors, and wasted effort on the admin side
| dealing with an antiquated tech that should have gone away with
| MySpace.
|
| RSS should be scrapped. Killed. Replaced. Forgotten.
| netghost wrote:
| You're entirely right, and yet I think there's still a place
| for it.
|
| It all depends on what you want to use it for. For my use case,
| I built a feed reader that just needs to know the titles, URLS,
| and publication dates of articles. That let me build an
| RSS/Atom reader that lets me curate my own news feeds and
| delegates everything else to the normal browser.
|
| Are there inconsistencies and broken feeds? Sure a few, but for
| my purposes, I can ignore 99% of that. Is it wasteful? Sure,
| it. could be more efficient, but honestly downloading React and
| a hundred dependencies every time I visit a webpage is as well.
|
| Fear not though, many sites built with tools like Gatsby aren't
| including RSS feeds, so your wishes may still come true.
| pvtmert wrote:
| imo DNS is much more capable world wide database.
|
| also BGP...
| notriddle wrote:
| Anything built on domain names cannot be described as "built to
| last." Not HTTP, not SMTP, not Gopher, not DNS, not the
| Fediverse. This is because domain names are rented out, and have
| expiration times attached to them, so obviously they can only
| last as long as the organization behind both the domain and the
| registrar keeps it there.
|
| IRC and USENET were built to last. Names in either network
| weren't tied to anyone but the collective "network." Neither
| network gets used much today, since names aren't tied to anyone
| in particular. It turns out that globally writable data stores
| are great vehicles for spam and fraud.
|
| Content-addressed systems like BitTorrent and I2P can
| theoretically maintain content availability for as long as
| _anybody_ wants to keep it available, not just whoever originally
| published it. BitTorrent is also pretty secure, but it 's not
| truly fair since it's an immutable data store, and all the spam
| and fraud is just _outsourced_ to HTTP instead of being
| eliminated entirely.
| david_draco wrote:
| Dude, you're not supposed to admit you like XML!
| remram wrote:
| > I'd argue that the web, more specifically http, offered up the
| last truly new paradigm in computing. It is a single, elegant
| standard for distributed systems. We should all take the time
| every now and then to think about the beauty, power, and
| simplicity of this standard.
|
| What is really funny about that sentence is that the word "http"
| links to the wikipedia article through href.li, in order to hide
| the referer, a built-in feature of HTTP 1.1 and the web. So much
| for elegance and simplicity when I am staring at a workaround
| using an external system for something as simple as a link.
| quonn wrote:
| So? There is an attribute to control that. Sure, the default
| has less privacy but that has little to do with the transport
| and is a property of the document spec.
| notriddle wrote:
| A feature of the HTML spec that's so new even IE11 doesn't
| implement it? That hardly seems like a glowing recommendation
| for HTTP/1.
| superkuh wrote:
| Too bad that browsers are depreciating both RSS (ie, firefox
| removed feed rendering support) and HTTP (ie, firefox pushing
| HTTPS _only_ ). And HTTP3 isn't even tcp anymore it uses the
| google-mostly QUIC on udp.
|
| For the corporate web RSS and HTTP are dead. But as a non-
| corporate human person I'll be sure to keep RSS and HTTP alive on
| my webservers.
| anderspitman wrote:
| I think that QUIC and HTTP/3 are great, but I worry that
| HTTP/1.1 will eventually be abandoned. I think it's important
| to be able to implement basic HTTP functionality with a few
| lines of code.
| masklinn wrote:
| > I worry that HTTP/1.1 will eventually be abandoned.
|
| HTTP/2? Sure HTTP/1.1? Not a chance. It's too widespread and
| too valuable, and the floor is too low. Unless Google starts
| a singular effort against it and manages to pull in the other
| big cos while avoiding the ire of the liberal states, which
| seems unlikely.
| vbezhenar wrote:
| HTTP 1 is magical. It's so simple to generate or parse.
| It'll never be abandoned just because of that reason.
| divbzero wrote:
| Yes, headers in text plus body in any content type is
| incredibly simple and flexible. It's hard to imagine
| redesigning HTTP/1 to be any more straightforward.
| anderspitman wrote:
| I sincerely hope you're right. I certainly intend to always
| support it on my services. But it's all too easy for me to
| imagine a world where Chrome/Blink drops support.
| tootie wrote:
| RSS is still the predominant format for syndicating podcasts. I
| think it's to come under attack by big players looking to build
| a walled garden (Spotify and Apple in particular) but it's
| hanging on.
| lucideer wrote:
| On RSS I'd agree, but I think you've missed the mark on HTTPS.
|
| HTTP-over-TLS works fine across all "versions" of HTTP, HTTPS
| has been supported by browsers since 1994; over half a decade
| before RSS was even a thing.
|
| Your criticisms of HTTPS seem more targeted at HTTP3, but
| that's actually a separate topic (HTTP3 may be HTTPS-only in
| practice but that's not the specific aspect you're critiquing).
|
| RSS/Atom also work fine over HTTPS.
| selfhoster11 wrote:
| HTTP over TLS does not work fine for all versions of HTTP. A
| fully updated install of Windows XP is essentially incapable
| of establishing a modern TLS connection because everyone
| removed support for older crypto. It follows that modern TLS
| is a crypto treadmill that ejects older devices as soon as
| they cannot keep up with security updates.
| xfer wrote:
| You mean older devices running unsupported proprietary
| code? I am sure openssl will work fine on your windows XP.
| georgyo wrote:
| Windows XP... I cannot tell if you are trolling or not.
|
| It hasn't received patches in 10 years, so having it
| connected to the internet at all is a bigger problem than
| it's lack of tls1.3 support.
| 0des wrote:
| Don't ever go into manufacturing.
| selfhoster11 wrote:
| I'm absolutely not trolling. I regularly have to use an
| old XP machine for various tasks, and as long as it's
| firewalled properly (preferably only allows traffic to a
| pre-set list of servers) and the security surface is
| reduced by removing unused services, it shouldn't be too
| risky to use for special-purpose tasks.
|
| General-purpose browsing is a whole different matter. I
| wouldn't advise anyone to do that unless on a patched, up
| to date and supported machine.
| Karrot_Kream wrote:
| I take it that it may be difficult to build for Windows,
| but that's what stunnel [1] is for. If you can do that
| and proxy your outbound traffic you should at least be
| able to communicate with modern crypto. Opening up an old
| XP install to the general internet though... is an
| endeavor one should probably be very careful about.
|
| [1]: https://www.stunnel.org/
| gsich wrote:
| There is a Firefox version that works I guess.
| soperj wrote:
| Can I ask what the various tasks are? There's gotta be a
| way to do these things on a modern operating system no?
| roywashere wrote:
| If you go on using a pre-set list of servers, you also
| would be able to do reverse HTTP proxies.
|
| Using a pre-set list of servers with many sites is not
| easy, because they'd use CDNs and such.
|
| So basically you can only use it for your 'own' websites
| and then you can control crypto on server side.
| anderspitman wrote:
| Wouldn't a forward proxy that speaks XP's level of crypto
| be easier?
| lucideer wrote:
| Setting up a firewall with a small strict set of servers
| to allow traffic to seems a lot more restrictive and
| complicated to set up than simply installing Firefox or
| some other solution that supports modern TLS.
|
| Either way though, I do personally think it's fairly
| reasonable for server admins to maintain webservers that
| target "General-purpose browsing" without also having to
| include support for odd individual long-tail edge-cases
| of people running restrictively firewalled instances of
| outdated insecure OSes.
| lucideer wrote:
| You're talking about implementations, I'm talking about
| specs.
|
| HTTP/1x != Windows XP.
|
| Advocating for older specs doesn't mean advocating for old
| insecure implementations.
| selfhoster11 wrote:
| If I can't establish a TLS connection, I can't get at the
| HTTP that's flowing over the encrypted pipe. It's
| pointless to split up HTTP and TLS/SSL when they were
| always deployed in lockstep anyway (unless you were happy
| with plaintext, or BYO encryption).
|
| If we imagine the HTTP+plaintext at one extreme, and
| HTTP+TLSv$latest at the other, a whole bunch of specs in
| the middle have effectively died out because nobody
| deploys them any more.
|
| Therefore, it's unfair to claim that "HTTP-over-TLS works
| fine across all versions of HTTP" (because it doesn't,
| unless you also support modern crypto), or that "HTTPS
| has been supported by browsers since 1994" (because the
| 1994 HTTPS is not even partly forwards-compatible with
| the 2022 HTTPS).
| AshamedCaptain wrote:
| No, it is the standards/specs which are changing.
|
| E.g. today SSL/TLS almost universally means TLS 1.2 or
| 1.3. The SSL specs are no longer accepted by practically
| any server.
| lucideer wrote:
| I guess I should be more specific in my wording: I should
| have said "advocating for _specific_ older specs " (i.e.
| HTTP).
|
| Not all older specs are worth advocating for.
|
| Security is unfortunately an arms race, which means that
| broadly speaking software-updates are important for
| anything network-connected. Using old hardware is
| thankfully still possible, but the idea of expecting a
| 12-year-old piece of software to securely connect you to
| the internet today is disconnected from the reality of
| the threat landscape we live in.
| themodelplumber wrote:
| Windows XP deserves to be on a nice comfortable LAN with
| other technology with which it can speak outdated crypto.
| :-)
| AshamedCaptain wrote:
| HTTP still works practically as-is on devices from about 25
| years ago.
|
| HTTPS does not even work on devices from 5 years ago.
|
| After non-removeable batteries, SSL/TLS implementations have
| been the single largest headache when you want to keep using
| a device for more than a couple of years.
| lucideer wrote:
| I presume when you say "device" you actually mean software.
| HTTPS can absolutely run on devices from 25 years ago.
|
| Expecting network-connected clients to work securely
| without software updates for even a few months these days
| though isn't really possible, but that's down to the
| externalities of the world and has nothing to do with spec
| design.
| Brian_K_White wrote:
| The mechanism by which https rendered the old device
| inoperable does not change the fact that https rendered
| the old device inoperable.
|
| One may argue that the problem is essentially unavoidable
| because the alternative is untenable (delivering any sort
| of communication without both encryption and
| authentication to ensure the veracity of the data) but
| that doesn't make the observation any less true. https is
| in fact a pain in the ass and introduces a lot of
| overhead and grief and shortened the useful life of
| countless things, relative to the time before https.
| nightpool wrote:
| Chrome on Android just trialed a new RSS-based "follow" feature
| a few months ago:
| https://www.theverge.com/2021/5/20/22445284/google-rss-chrom...
| themodelplumber wrote:
| Wow! Didn't expect that. I guess I had better check what's
| even available in my feeds, and where it's coming from...
| jedimastert wrote:
| RSS is just an XML format, and I don't think in-browser support
| was what was holding it together. There's still plenty of
| readers, and there's nothing stopping other readers from
| popping up.
|
| It'd be like saying Firefox is deprecating JSON because it
| doesn't have a nice viewer for it...
| thaumasiotes wrote:
| Firefox has an _excellent_ JSON viewer.
| ocdtrekkie wrote:
| HTTP 1 will outlive the death of HTTP 3, QUIC, and Google. New
| standards come and go, old standards exist forever. RSS will
| probably make a comeback eventually: The ability to
| automatically process information is a common wheel we
| reinvent.
| forgotmypw17 wrote:
| It's true, and especially HTTP/1.1 has a whole 25 years worth
| of browsers which are still usable today!
|
| I think as the nostalgia/retro factor kicks in, it will
| become cool again to support "Any Browser".
|
| A few common questions about this are:
|
| Security exploits: Yes, you do have to do this on a safe
| network, but at least over where I am, the Internet is safe
| enough for me to visit un-malicious websites, perhaps using a
| VM.
|
| The difficulty of it: It's moderately difficult, but quite
| doable, with certain constraints combined with progressive
| enhancement.
|
| (HTTP/1.0 browsers are slightly more difficult to support,
| because you need a dedicated IP address, as there is no Host:
| header yet. Netscape 1.x, IE 1.x and 2.x, Mosaic are quite
| usable if you can get this set up.)
___________________________________________________________________
(page generated 2021-09-08 23:01 UTC)