It's a great concept. Question - why not just use CouchDB? We've been doing similar app platform stuff with it for years. Check out this wiki that is hosted directly out of CouchDB, with no other server side component: http://couchapp.org

I must admit that I'm not very familiar with CouchDB. From what I have read think there are a lot of similarities - and with the same goal of building complete web apps using only client-side JavaScript.

Pageforest has a focus on building a multi-tenant application hub. I think of it as kind of distributed Google Docs infrastructure:

- Users' data is stored in a unified document store that is owned by the user. They can view and manage all their "documents" created from applications from one place. - They can use their Pageforest account to grant permissions to each application they want to use to write into their document store.

BTW - Pageforest is currently hosted as a Google AppEngine app - so it picks up the scalability benefits of BigTable with a datacenter managed by Google.

I'm surprised to see a suggestion of CouchDB - with the deep integration of BigTable with App Engine, I think it'd be unnecessarily hard to use anything else.

PageForest uses App Engine to provide a key value storage API with user authentication. CouchDB has these out-of-the-box, so a CouchDB version should be much less code than this version. Not to mention all the things Couch supports that would be a major challenge to implement within App Engine.

Er, well CouchDB is kind of a different animal and is very far from supporting the kind of development workflow he's doing. CouchApp is very, very cool but very different and saying that things like this have been done is kind of pointless - web apps have been written in _everything_.

I get ya - sorta. I do think we are running headlong into NoSQL 2.0, where everyone ends up writing very similar but incompatible HTTP accessible key/value stores. Seems like a waste to plow energy into writing web-based key value stores when there are already plenty of good ones.

Pageforest is a pretty thin wrapper on top of a AppEngine's BigTable implementation. It does have to add things like a user accounts, user permissions, and caching layer.

The client library (JavaScript) is also design to make it very easy to write "single-page" web apps. You basically just need to write a setDoc() and getDoc() function to persist your document as a JSON blob in storage.

"single-page", that reminds me of appjet, a cool hosted SSJS by the authors of etherpad.

etherpad was awesome! Difference here is that the app lives client-side - and uses a "generic" server implementation for user authentication, storage, and push notifications.

PageForest looks pretty cool. Anyone want to comment about security concerns of the pageforest model, vs traditional web apps?

As the author, I can tell you how we've designed it (I'd welcome any other critique - it's all open source too, so you can look under the covers).

(1) Users sign in on the www.pageforest.com domain only. Applications are not given access to a users's credentials.

(2) Users must specifically grant access to each application for an app to write data on their behalf.

(3) We create an app-specific authentication token in the app sub-domain you are signed in to.

(4) To protect against cross-side request forgery (CSRF), we require the REFERER to be from the application domain (and NOT from the /docs sub-directory) for authenticated requests.

(5) Our authentication cookies are HTTP-Only. This makes is impossible for injected javascript to access the authentication cookie.

(6) Our app-based authentication cookies expire in 24 hours. Users can get a new cookie by re-authorizing the app from www.pageforest.com.

(7) We don't require ssl use for sign-in. This is probably our biggest security hole. But apps can be used on an SSL domain at https://appid.pageforest.appspot.com.

(8) We never transmit a user's password over the web - we use a challenge/response protocol that hashes the username/password on the client, and only sends the SHA1 of the user's response to a challenge.

I should add that since your application's assets are publicly viewable, there is no way for your app to store a secret key. Also, all your source code is visible to anyone wanting to look at it. This may preclude those that want to keep their code a trade secret.

Thanks.