Note: this was originally written as an “App Idea”. We’re moving ahead with TiddlyWiki on Fission, so have moved this post to the dedicated App category for it
TiddlyWiki is a fascinating note taking / wiki project with a long history. Content is composed of “tiddlers”, and tiddlers, tags, and custom fields can be added, as well as many plugins. It started off as a single page HTML / JS file that would save back to itself.
Recently, it has a number of different “Savers”, including Git savers
Good old TiddlyWiki . I used mGSD, formerly MonkeyGTD (now all abandonware but still accessible through the Web Archive), based on TiddlyWiki, as my personal task manager for a few years. Almost a decade ago now. Just checking my Dropbox… yes, everything I wanted to do in 2011 is still there
It was good, but a bit obscure. Can’t remember what made me move on to something else, maybe the lack of a good mobile experience.
Expanding on this. I used the fake phrase “would be more scalable”, and I really should explain myself
The default mode of TiddlyWiki is working in single file mode, where code + content is all in one html file.
The individual tiddler mode is most often used in various server configurations: each tiddler is an actual file. I think this might even be able to be mixed and matched, which could be interesting. Will look this up.
With Fission, where we have a user account and both private file storage as well as public storage, I was thinking that one could take advantage of that to seamlessly have both private, encrypted tiddlers – in a user’s /private/Apps/Jermolene/TiddlyWiki space, as well as public tiddlers in /public/SomePath/TiddlyWiki.
Looking at this again, this is more complex. There is something interesting in this direction, but it shouldn’t be where we start. “more scalable” for me really was all about future features – multi-user, private encrypted and public mixed, and so on.
So, the initial default TiddlyWiki app should be a sort of launch pad. It can ship with one or more default TiddlyWiki “distros”, all of which will have the Fission saver pre-installed and enabled. We can make a call for distros to include, and check them into the source code of the TiddlyWiki on Fission app.
A user selects one of the distros, chooses whether they are private or public, and then has a new TiddlyWiki single file instance, that lives in the private or public trees as above. Reads/writes get done back to that single file.
When they come back to the TiddlyWiki app, as well as the “Create new TW”, they are presented with a list of their already created, named TiddlyWiki instances.
images / files of any type can be stored in a Fission file system, need to look at a file uploader widget
the main TW fission app – published Fission apps in general – don’t currently have their own writable “app” file system; all writes are done to a per-user file system, so that “list of created TWs” would be at /private/Apps/Jermolene/TiddlyWiki/userTiddlyList.tiddler or similar.
for a TiddlyWiki not hosted on fission, a Fission Webnative saver could still read and write individual tiddlers to a user’s public or private file system; this is a good argument for individual tiddler mode
The single file configuration is actually constrained to be almost entirely self contained, so it’s not really possible to mix and match in the way that one might hope. One can reference external images from a single file wiki, but it’s not possible to reference external tiddler files because we can’t in general use xmlhttprequest()/fetch() (particularly when served from a file:// URI).
Being self contained of course massively simplifies distribution and archiving. (I can open an old single file wiki from 2005 just by double clicking, whereas an archived snapshot of, say, an old WordPress site would take some effort to spin up).
TiddlyWiki provides the means to convert wikis in either direction. For example, most of my personal wikis are maintained as self contained single files on Dropbox, but I’ll occasionally convert one into a wiki folder for certain bulk maintenance tasks, or to save them to Git (which tends to work better with individual tiddler files).
Yes, I think we can come back to that sort of thing later. Perhaps we need a high level abstraction, like pipes connecting wikis to other things that generate or consume tiddlers. The configuration parts of the wiki would be subject to the saving semantics that we’re considering now.
I’m hoping we can make the Fission saver small enough to keep it in the core (rather than a plugin) because that will make things a lot easier for users. But we might need a plugin for the more ambitious ideas.
The TiddlyWiki community doesn’t currently have a good place to share distros (we call them “editions”), so there could be a good opportunity to encourage people to try Fission.
That makes perfect sense.
As a potentially simpler first step, might it be possible to make this workflow work:
Save a TiddlyWiki HTML file to Fission drive
Open it via the https://ipfs.runfission.com/ipfs/bafybeidkgg4lf2ky5nnupsxqr4xua24wzjiebtbj52wqbmsrwnaqhgb6n4/p/index.html-type URL (what do you call those?)
Click the “save changes” button in TiddlyWiki to save changes back to the original file
Presumably the page opened at ipfs.runfission.com doesn’t have access to any credentials, can we do some kind of oauth magic to get credentials there? Even pasting an access token in manually would be OK I guess.
TiddlyWiki currently lacks any UI for uploading attachments to a server, so in the first instance users would use the Drive interface to arrange external images etc., which seems fine.
That sounds like an instance of the “pipe” idea above: within TiddlyWiki, we’d set up a “syncer” to synchronise a subset of tiddlers to and from the webnative filing system.
Thanks @boris I think that’s clear: Editing TiddlyWikis viewed through a permanent file link is equivalent to what we’ve referred to as “saving to my Fission drive from anywhere on the web”; nothing special occurs because the HTML file happens to be hosted in the ipfs gateway.
Checking in, and just learning about Fission. This is really exciting. I did most of the recent update work on the TW Node “Filesystem Sync Adaptor” plugin, which writes changes to the wiki sent by the browser to disk on the server. I hope I can leverage this familiarity with the wiki Syncer logic here to help.
Great to meet you all (Hi Jeremy!).
Thanks @joshuafontany – this is going to be an open source project that anyone can contribute to, and we’ll be opening the Github repo soon.
Jeremy is @Jermolene here, as he is in most places
Aside from the saver, we’ll have tiddlywiki.fission.app (not working right now, but soon!) as a Tiddly Desktop like “launcher”. I’d love to fill it with several different TW Editions if you have any ideas.
Feel free to use this section of the forum for ideas or suggestions. We’ll have Github Issues, but if we can include people beyond developers here, that would be great.
@boris Thanks! Great to meet you as well. I saw your talk with @Jermolene back in October and was intrigued by the Fission things you mentioned but didn’t have the context to see what you all had been working on.
I wrote the TW5 “JsonMangler” plugin, which I consider part of a core “Coder/Dev” edition (allows you to manipulate nested Json & import CVS as one-tiddler-per-row).
I also have my “pie in the sky” edition that all my efforts are working towards:
GMGuild.wiki, a system-agnostic, “own your own data” version of services like D&DBeyond, ObsidianPortal, etc, which are “Game Campaign Managers” (Tabletop RPGs, Skirmish Wargames, LARPs, whatever).
My biggest roadblock there was I am 1 person trying to dev & QA back-end and front-end, figure out logistics for a scalable user-base, a centralized “news” wiki, etc, etc. I am currently doing a re-write of the TiddlyWiki “Bob” multi-user/multi-wiki plugin that was going to serve as the base of this…
Wrapping my head around Fission makes this all seem much more possible and manageable!