@colmjude asked in email:

Oh and out of interest, you may have answered this somewhere else already but if not, if someone asked what the main differences or benefits of tank over tiddlyspace were what would you say?

He then went on to summarize my answer (below) as:

So in summary you are saying Tank has learnt from the experiment that is TS. It is less reliant or associated with tiddlywiki and the wikitext it uses, using the more widely adopted markdown. It has greater unity across the platform and is more suited to being used on a variety of devices. By not including some of the more complex (but useful for certain use cases) concepts that TS has it has greater focus on Hypertextuality and is likely to have a lower barrier to entry.

I haven't answered it very well, if at all. So:

It would be interesting to do a full on retrospective on TiddlySpace (with tsretro!) because I'm certain there is a great deal that could be learned from it. It's definitely the case that development of Tank has been far easier simply because TiddlySpace established the frontier for tiddlyweb working at scale.

The main difference is in clarity of intent and implementation. As TiddlySpace was being built there were effectively two conflicting forces that reacted to each, reinforcing the entrenched positions rather than leading to compromise. On one side was "everything must be in TiddlyWiki" on the other was "the API is the most important thing". Neither position was best for the system and you can see the results now: TiddlySpace is a rather bizarre hybrid of TiddlyWiki hosting service and people playing with SPAs (both of which "hide" the API) and not very good wikis living on top of the API (e.g. my space).

Tank is something of a reaction to that, merged with a combo of my long standing love of "get your shit on the web, please" and "real" hypertext, as embodied by thoughtful wikis. It wants to be:

• a good wiki that is relatively simple
• but can be powerful with extensions and API
• is capable of hosting diverse types of content
• can cook that content in a variety of ways

Some differences:

• TiddlyWiki is not central to the experience. Yes, you can make a comp with TiddlyWiki¹ but that's an option not a default. My hope is that this moves creating narrative human content to the fore, rather than "making your TiddlyWiki do stuff" (which is a fine activity, but not the focus).

• Policy handling is both more hidden and more exposed. My feeling is that the public/private thing in TiddlySpace, though a valiant attempt at accomplishing something cool, never quite worked. It has too many ambiguities and conditionals that make it hard to understand. Combined with inclusion it gets all kinds of wacked out when all you really want to know is: "can I get stuff done here?" and "who else can get stuff done here?". Tank tries to address this by making a single bag the focus for any given permissions management situation, have simple defaults, but offer control (with policymgr).

• Hypertextuality is central to the experience: You follow links that are URIs between entities which have built in extraclusion and transclusion, expose backlinks by default.

• The API is there (it's in <link>s on pages) but not conflated with the UX. While a tank and a page are a bag and a tiddler they each have distinct modes of interaction. When they are conflated harm comes to both types of interaction.

• Because I've been working on this while ill (and thus couldn't really do much else besides type on the computer) and over a fairly compressed period of time, Tank (to me at least) feels fairly unified. The presentation, though rather archaic, is unified. It doesn't feel tacked together. The TiddlySpace system and codebase is too huge and too inconsistently maintained to get that unified feeling (it needed more 100% attention from more people).

Some benefits:

• This is a personal preference, but I think Markdown is a better default syntax, simply because it is becoming something of a de-facto standard. Extended with wiki links, free links and transclusion it makes a fine wikitext. The resulting HTML is tidy, the original text is readable and transferrable to other contexts.

• Using oAuth2 for identity management is handy. Tank runs no risk of exposing users passwords.

• The current installation has been using SSL from the start.

• Though not widely tested, I think the boostrapping mode of loading TiddlyWiki is better than the tiddlywebwiki way. It keeps problems with TiddlyWiki in TiddlyWiki where they belong.

• I believe, but have no real evidence to prove, that comps will be more flexible and powerful than inclusion, once it gets going. I'm not putting much focus on it yet as I think getting the wiki aspects right, first, helps move things ahead.

• Though not perfect, Tank is somewhat responsive throughout.

These, and other, benefits largely exist simply because Tank is newer than TiddlySpace which is pretty much right on its 4th birthday.

I don't think of Tank as the same as or as a replacement for TiddlySpace. They reach different audiences (which would be nice to articulate but I'm not sure I can) and have different affordances. Some of the areas where TiddlySpace is a win are:

• Though it is rough, the concepts in following/replying/sharing/curating are interesting and productive. Tank has @<username> tagging notification, but does not try to enable replying.

• TiddlySpace nails the fractal manual concept (used by AMBIT). It could certainly have better tooling (for managing the fractals and the content within) but the general principle is sound. Tank can do it too (because the API is there) but doesn't yet expose any UI for construction. There's intent to make comps themselves be composable, and to handle multiple tanks, but that's distant.

Hmmm, I suppose I should preserve this somewhere. Any clarifications required?