The tiddler concept, as used in TiddlyWeb and TiddlySpace comes from TiddlyWiki, which was created by Jeremy Ruston in 2004. TiddlyWiki was an early example of quite complex DOM manipulation and JavaScript in the browser. It caused quite a bit of buzz and became a successful open source project.

A few years later BT bought Osmosoft, ostensibly to better understand open source communities and techniques.

Jeremy has said that he created TiddlyWiki as a way to help him write: The tiddlers can operate as separate chunks that can be moved around, re-used, separately edited. Tiddlers started as documents and became many things, including plugins which could impact the behavior of their container, the TiddlyWiki file itself.

In 2002 I co-founded a think tank called Blue Oxen Associates. We were born out of a mailing list devoted to talking about Doug Engelbart's Unfinished Revolution. I found the mailing list because I was a recovering system administrator taking a break to get a masters degree. I studied Engelbart, Information Organization, Knowledge Representation, Human Computer Interaction and related topics. I connected with Eugene Kim, the other founder, because we both had a "let's not just talk, let's also make some stuff" attitude.

The core issues we thought about were:

• Hard stuff is hard.
• Some hard stuff is so hard that we must collaborate to solve it.
• Collaboration itself is hard.
• Collaboration needs to be augumented with tools.

Blue Oxen set out to pursue doing and researching augmented high performance collaboration, establishing what became known as the Blue Oxen Way.

We needed to bootstrap our information processing. We wanted to more effectively access, use and re-use information.

So we built a wiki. Called PurpleWiki. With Purple Numbers. These were a riff on the HIDs and NIDs in Engelbart's various information systems (NLS, Augment, Hyperscope). They provide granular addressability to chunks of content.

Once those addresses become persistent it becomes possible to have granular reuse through transclusion.

At its height Purple Numbers were able to integrate the wiki, multiple blog engines, mailing list archives and an IRC bot into a self referential and transcluding network of granular content. Each system was able to refer to and quote from the other by reference, not by copy.

I eventually had to find a real job and took the purple toolset with me. The new job was software development. We used it to augment our collaboration. It was awesome.

So where's Purple now? It died the death of most interesting software systems: It was cool for the initiated and trained and pretty much inscrutable for the unmotivated. You can see it living on today when ¶ shows up when you mouse over some headlines in documentation (often Python related). That's because Simon Willison spread them around. He got them from Tim Bray who got them from me.

That was in the spring of 2004.

Church of Purple Hymn

In September of 2004 I started work at Socialtext and tried to spread the church of purple, but it didn't take: Too weird, too much work for people.

And then I saw TiddlyWiki, with tiddlers, and started stealing some ideas from there, primarily whole page transclusion: Hacking granularity into Socialtext by being able to assemble complex pages from smaller, simpler parts that could be reused in multiple places.

In summer of 2006 we started on what we called the REST API for Socialtext. It would not have had the Roy Fielding stamp of approval, so it would be better to call it the HTTP API for Socialtext, but we called it REST to highlight that it wasn't SOAP, the other API we had just finished, created to interoperate with Sharepoint and, ew, ick.

We designed the HTTP API with a few very important things in mind:

• We wanted to be sure that it imposed no constraints on what people what might do with it.
• We knew that meant the API itself should be very constrained, very general.
• Therefore it should be of, about and for the web.

Four years later somebody on twitter said:

Best REST API I've developed for? Socialtext, hands down. It just does the right stuff and doesn't complain.

The first client of the HTTP API was TiddlyWiki with which a product called Socialtext Unplugged was created. This allowed a Socialtext wiki to "fill" a TiddlyWiki and be taken offline, edited, and have changes sync back. The API and TiddlyWiki's adaptor mechanism mutually informed one another's development. Jeremy and I got to know one another.