I started blogging in 2002 using Radio Userland. Radio was designed an built by Dave Winer. Dave's roots are in outliners and so is his most recent project, Fargo. Fargo is clean, simple, and easy to use. In Dave's words:

Fargo is a simple idea outliner, notepad, todo list, blogging tool, project organizer.

It's an HTML 5 application, written in JavaScript, runs in any compatible browser, including Chrome, Safari, Firefox, Microsoft IE 10.

Files are stored in Dropbox, using the Dropbox API. They are accessible anywhere Dropbox is. You can share files with other users, or publicly.

From What is Fargo?
Referenced Mon Feb 24 2014 09:11:22 GMT-0700 (MST)

Yeah, Fargo is a Web application with no backend. Or, more precisely, Fargo is a Web application that uses Dropbox as it's backend. Take a minute and go link Fargo to your Dropbox account and create an outline. Then go look at Dropbox and find your Fargo files (they're in Dropbox/Apps/Fargo). If you're syncing your Dropbox account with a folder on your computer, they're right there, on your hard drive—completely under your control. Wrapping your head around this idea is important.

Want to export the data from Fargo? No need, it's already on your hard drive.

Want to wipe it out for some reason? Go ahead, just delete it from Dropbox. It's all yours.

Want to remove Fargo's access, but keep the data? No problem. Just unlink Fargo from your Dropbox account. The data's still there on your hard drive.

I've been calling this programming model the personal cloud application architecture (PCAA). Others call these applications "unhosted". PCAA apps use a "back-end as a service" (BaaS) system of one type or another to provide storage and other services for the application. Because of its API, Dropbox is a simple BaaS system that provides storage under user control. Other examples include remoteStorage and usergrid. For the last several years, I've been working on CloudOS, with similar goals.

A traditional web application looks something like this:

The browser talks to the Web application on a server that fronts a data store where user data is stored. Not surprisingly, many Web 2.0 business models follow this same architecture, deriving their revenue from the fact that they have "captured" their customers.

In contrast, a PCAA application looks like this:

In a PCAA app, the application and storage (at least for user data) are separate. Ideally, the user can pick where the application data is stored, even self-host if they like. In a PCAA app, users are not captured. Rather, they are free-range customers.

There are several advantages to PCAA applications:

• User control—as we discussed above, this architecture gives users a lot more control over their data. This is why I call it a "personal cloud" application architecture, because the backend infrastructure is under the user's control—it's their personal cloud.
• Less developer overhead—Developers can forget about the hassles involved in operating complex server to store and manage user data. They get to concentrate on the application.
• Less expense—Running backend infrastructure is expensive. PCAA apps use someone else's infrastructure.

The hassle and expense of designing, building, and running backend infrastructure keeps a lot of interesting applications from being built.

One objection I sometimes hear is that with a HTML5 application, like Fargo, there's nothing to keep someone else from stealing the application. That's true, if that bothers you. On the other hand, one of the reasons for the viral adoption of the Web was that developers could view the source of any Web site and understand how it works. But if you're not in a sharing mood, there's nothing about PCAA apps that requires HTML5 and Javascript. You could just as easily build one in Ruby or Python and run it on a server. What makes it a PCAA app isn't the language it's written in, but how it treats user data.

We've written a number of applications using the PCAA style with CloudOS providing the backend infrastructure including Forever, an evergreen contact application, a simple Todo application that I use for demonstrations, and a Guard Tour application.

One of the interesting things about PCAA apps is they don't have accounts as we've come to understand them. I don't have an account at Fargo. Fargo has users, but no accounts. You could, of course, add them if needed, but most of the time, they're simply not needed.

In a world of APIs and services, creating common backend services makes sense. One of the key drivers of innovation in computers has always been modularity. Making storage and other common services (like subscriptions, notifications, configuration management, calendaring, application support, etc.) modular will further accelerate the growth of applications by making them easier and cheaper to build.