I can't stop thinking of an online version of Tinderbox, as a web app.
Wihtin my organization, I feel alone with my Tinderbox version on my mac.
So a more collaborative approach to the use and principle of tinderbox will be cool way to increase its potential.

Of course, for Eastgate, that a very different business model. What is Mark point of view and thoughts about this opportunity ?

Two answers.  Summary:

    1) Tinderbox can't be a Web application
    2) Tinderbox 4 *is* a Web application


Tinderbox uses a lot of processing power.

That's the point: you HAVE a lot of processing power.  Most of the time, that processing power is sitting around, twiddling its thumbs.  But it's there: how can we use it?  Tinderbox proposes an answer: let's use some of that processing power to make a personal assistant that helps us analyze and organize.

If Tinderbox ran on a server, you'd need to share a CPU with all the other people who were using Tinderbox.  Imagine: not only do you need to worry about YOUR agents, you need to worry about Mrs. McGillicudy's agents too!  To keep up with the processing demand, we'd need to have LOTS of servers.  

BUT......

Quietly, in Tinderbox 4, we've introduced some very interesting new Web hooks that let your Tinderbox information reside on servers.  

For example, a Tinderbox document can now have its own email address; you can send email to your Tinderbox task list, or email to your research notes!  And Tinderbox documents can send email, too.  Or Twitter!

Another example: Tinderbox 4 makes is much easier to automatically update Tinderbox documents with shared information from a Web server. Yesterday, my ToDo list included a reminder to change the Tinderbox version and price in the Eastgate catalog system, which is a separate Tinderbox document.  But when I got there, the price was already updated!  Magic!  How did this happen?  A few weeks ago, I'd told the catalog Tinderbox that it could find the current price at a specific URL; it was so easy, I'd forgotten all about it until I went to correct the database and discover that Tinderbox had already done the work for me.

In my opinion, the ability to couple Tinderbox event processing with the underlying UNIX shell offers an amazing level of interaction with the rest of the world. With a little knowledge of PHP, Ruby, or some other easily web aware scripting language, you can integrate Tinderbox with your own website---even other web sites that offer external APIs, such as Basecamp, Google Maps, and so on. That's not even counting the extant Tb features already brought up, such as mail integration, and URL fetching.

I have yet to fully explore script coupling myself, but getting my own to-do list roughly synchronised with my company's Basecamp collaboration hub would be fantastic, and it is on my long-term list of things to sort out.

One Tb application that I already have developed facilitates the composition of our monthly newsletter. I get copy from the writers and dump their rich text right into Tinderbox, which it exports to HTML precisely as I configure it to. Tb uses several private APIs I've developed for our web site to pull various bits of data straight out of the site's database, and then I use a series of exporters to produce an email's HTML part, Plain-text part, and web-site archive all from the same source. Revisions can be produced instantly and published directly for collaborative proofing.

I'd say Tb4 is already a web app. Sure, it doesn't have a bunch of stuff out-of-the-box, but Tb out of the box is just an outliner (to be brazenly understated, ha). We have to "program" it to do everything we want it to do with a file. Same goes for integration.