Pinboard (https://pinboard.in) offers archiving for (I believe) $25 a year.

Or Pocket (https://getpocket.com/) which used to be Read-It-Later.

I use Pinboard, and pay for the archiving option. I even periodically request a tarball of the archive for my own backup. Pinboard archives the entire page, not just a readable version of the content. For archival and reference purposes, I like this. It would be nice if Pinboard also provided a readable option. In fact, a number of the apps that work with Pinboard add support for readable versions.

I will look into adding Wallabag into my workflow.

Some interesting reading is Christian Kohlschütter's thesis on this problem, which is framed in academia as "how do we assemble good text corpuses from webpages for data analysis, which means removing junk (boilerplate) from our HTML crawls" (https://code.google.com/archive/p/boilerpipe/wikis/WSDM2010P...). Boilerpipe would probably be the right way to go, but if you're not using Java it could be harder to integrate.

https://github.com/mozilla/readability

Which is a nice API for extracting metadata from a web page, although I understand it might not be worth the cost.

I don't know what is the state of the art for a general content extractor. (I have done a fair amount of one off web scrapers, for data collection, but nothing this generic)

https://readpaperback.com

The demo seems to be broken for me.

>Pocket, I remember. ReadItLater used to exist, maybe still?

there was an obvious reason to name Pocket as "formerly Read It Later"

It does require iCloud but nothing beyond that.

The fact that there's no way to get anything to actively sync between Chrome and iCloud is maddening. Why has nobody reverse-engineered the iCloud API and made a Chrome extension to talk to it?

I still launch Chrome and FF regularly for development, but my tab-hell lives in Safari now.

I find Safari often becomes unusable with 30–50 tabs.

Here's the code, which I have tied to "stc " (send to Chrome). [Ha! In typing the snippet shortcut, of course, I sent this very page to Chrome. :-)]

  property theURL : ""
  tell application "Safari"
  	set theURL to URL of current tab of window 1
  end tell
  if appIsRunning("Google Chrome") then
  	tell application "Google Chrome"
  		make new window
  		set URL of active tab of window 0 to theURL
  		activate
  	end tell
  else
  	tell application "Google Chrome"
  		do shell script "open -a \"Google Chrome\""
  		set URL of active tab of window 0 to theURL
  		activate
  	end tell
  end if
  
  on appIsRunning(appName)
  	tell application "System Events" to (name of processes) contains appName
  end appIsRunning

I also wrote a short AppleScript called Tab Transporter to move tabs between browsers. It's configured to go from Safari to Chrome but you could reverse that easily. I activate it via Alfred.

https://github.com/tedmiston/tab-transporter

http://apple.stackexchange.com/questions/51534/reading-list-...

If you can reverse engineer iCloud and bypass its security there are a lot more lucrative pursuits than making a Chrome extension for your reading list.

This is typically a good thing because syncing is hard enough when you control both ends, having arbitrary programs messing with your data is a recipe for disaster.

Still, even with the way iCloud works, you don't need to directly prod the data. If you want to manipulate Safari's container, you can prod Safari itself into doing so. OSA is no COM, but it works just fine for this sort of thing. (And if you can't manage to make it do so, you can write a Safari plug-in presenting a locally-bound HTTP API that the Chrome extension can talk to.)

Now, the real challenge would be doing this syncing as part of some "syncing service" running on a cloud VM somewhere, that doesn't actually want to run thousands of headless copies of Safari. That's what I really want: the ability to sync Chrome with iCloud even if I currently have no active iCloud-attached devices. Probably the simplest way to do this is to write your own Ubiquity+CoreData client libraries and present yourself as another device that wants to sync against the iCloud account. It'd be up to you from there to safely munge the CoreData object hierarchy in a way resembling the official clients, but at least you'd be able to linearize those updates against iCloud messages.

I also tend to stuff my Instapaper full of hundreds of links which it handles no problem, but Reading List really crumbles adding a bunch at once when it tries to download everything.

"It works, it's nice and fast, and will continue to work the same way for the foreseeable future" is pretty much the highest praise I can give a service like this, and Pinboard nails that aspect.

It might be helpful for you to have a look through there and see if any of them have a stand out 'read it later' experience.

Except a new third party (Pinterest) will sooner or later have access to my Instapaper data. I trusted Instapaper because they had a sustainable business model not based around ads. I do not trust Pinterest because their business model is based around selling my personal information and activity to advertisers.

Basically it's time to stop using Instapaper :(

Anyway, I'm probably going to replace my Instapaper with a self-hosted alternative instead of hoping yet another company stays in business long enough.

I have been using it for three months now, and it works flawlessly. I was using Pocket, but sometimes after I would save links with their iPhone app, I would go into their web interface to view them at a later time, and those links would be gone.

But I have not had one single link disappear from raindrop.io since I have been using it.

The pricing page is blank for me.

Unfortunately the "read at altitude" is a paid feature, at least for tablets and phones (maybe windows/mac too, I don't know). So that might make it not work for you.

It's been puzzling me for a while though: doesn't Google punish the behaviour you mention?

> For you, the Instapaper end user and customer, nothing changes. The Instapaper team will be moving from betaworks in New York City to Pinterest’s headquarters in San Francisco, and we’ll continue to make Instapaper a great place to save and read articles.