However, I also think that you need to update your faq (http://www.furl.net/faq.jsp). Sentences like “Coming soon is the ability to export all your saved documents (i.e. a big zip file)” imply that the ability is not there today. If it is (I’m not a furl user and wouldn’t know), the FAQ is out of date.

In any case, as you say, different but related problems.

Once in Furl, you can take advantage of the growing number of network services that we provide (i.e. sharing (email, RSS, web), recommended reading based on what you save, access from any computer (or networked device)).

Just to address some of the statements that you made in error towards Furl:

* Furl does not require a rich client. In fact, the current JavaScript client sends the page from the browser to the server (in both IE and Mozilla), allowing you to save any page you see.

* And as for “[your data is] stored on someone else’s server, where you can’t get at it.”, that is just not true. It IS true that it is stored on our server (and backed up hourly between NY and TX). But it is also true that you can access and download your entire content store (with all documents in their original format (i.e. HTML, PDF, etc)) at any time. And as Jon alluded to, the current architecture allows much more offline functionality to be provided in the future.

Thanks to Jon for keeping the discussion going. It will definitely be fun to watch the space develop in the years to come.

Obviously Seruku and Furl chose different points in the design space. Seruku is designed to make it as easy as possible for you to realize, after the fact, that a page you saw was useful (and to easily find it). You can realize today that something you saw last week was important, and easily find it.

That is, the primary mode of operation is mostly unconscious and the key reason for that is, a lot of the time you don’t realize the importance of what you’re seeing (or, even if you know it’s important, you don’t remember to click the button because, after all, you’re thinking about what’s on the page, not thinking about storing the page).

This drives a lot of design decisions, from the fat client (We’re not requiring the user to click a button so we need to listen to the browser’s event model in order to know when pages have been loaded) to the local file system (if we sent every page people viewed over the wire, well, that’s both a *lot* of bandwidth and some potentially huge privacy issues that we’d rather avoid completely).

Furl chose location transparency (storing data on a external server), only storing the pages you click a button for, and a more extensive annotation system. It’s a different model of what the user’s looking for and doing (it requires a lot more conscious thought to use), with a entirely different goal in mind. Which, in my mind, makes using Furl more like using Onfolio or Webstasher than using Seruku.

As a side note, in many scenarios Furl also requires a rich client. The javascript button (the “thin client”) only sends the url to the furl server. Which means that (1) pages that required authentication won’t get stored and (2) pages that relied on personalization (e.g. a cookie) won’t be the same.

Of the remainder, I’m not sure I understood the “proprietary format” comment. To date, no-one’s mentioned this as an issue (and, certainly, I have a hard time understanding how any format could be “more proprietary” than “it’s stored on someone else’s server, where you can’t get at it.”)

On the other hand, I don’t think we’d have a problem either fully documenting the format, or simply switching to a more easily understood format. The value provided by Seruku is entirely independent of the file format we use.

Does a more open file format seem like something of significant value?