Background on apps and files, how to structure TW

Apps TiddlyWiki
1

Note: this is not fully baked yet

I’ve created a background diagram on apps and the user file system – comments are enabled, also embedded below:

This is a continuation talking about how to structure a TiddlyWiki app, saver, syncer, etc..

I think this is how this can work today. I am handwaving over syncer vs saver. @Jermolene can you explain the difference between the two approaches?

Note: Fission saver / syncer in core – so TWs wherever they are deployed in the world can save / sync back to Fission – is a topic that should get handled separately.

Users visit the TiddlyWiki app on Fission. This is statically published, and we can include whatever setup / default tiddlers / etc. we want with it. It has the Fission saver / syncer included with it.

The landing page displays a TW and describes what it is, and has a big “Sign in with Fission” button. The user signs in / grants permission to the app to write to their file system,

The app is like TiddlyDesktop – the next step is to launch or create a new TW.

The user chooses “new private” → a new TW is created in /private/Apps/Jermolene/TiddlyWiki/[NewPrivate]/index.html. The user visits TW.fission.app and launches into their private TW whenever they like. It is only visible to them and only when they are logged in. It is available on other devices and synced there when they are logged in. Saves are written directly to that file path by the saver.

The user chooses “new public” → a new Fission app is created / published on behalf of the current user. We can have them choose a type of public TW edition, pick a subdomain, fill out a name, whatever we want to gather. Then, mynewtw.fission.app is created, we check DNS until it exists, and then present the link to the user.

The user visits MyNewTW, is prompted for permission, and is asked for access to their public tree, /public/TiddlyWiki/MyNewTW. They are logged in, the saver / syncer is pre-configured by the new app launch to write to user Bob’s public path. Bob, being logged in, can write to their own public path – “saving” the entire index.html or syncing tiddlers.

Alice, another user, visits the public TW at mynewtw.fission.app, and can browse it, but edits aren’t saved. Future opportunity for App Cloning, if TW owner has this enabled.

Bob can go back to the main TW app on Fission, which keeps track of all the private and public TWs that Bob owns. Different Editions live at the main TW app, and it’s also the main hub where Private TWs are accessed and edited.

We can maintain the TW “Desktop” app as a community github repo. We’ll use a maintainer process of including different Editions, plugins, run updates, and so on, which get deployed.

1 Like
2

TiddlyWiki has two ways of persisting changes:

  • “saver” modules are given the new HTML text of the file and save it somehow. We have savers that POST via HTTP, use the GitHub HTTP API, use DOM messaging to talk to a helper browser extension, use Beaker Browser’s file APIs, there’s even one that uses an ancient ActiveXObject hack for IE. The core currently ships with 16 savers
  • “syncadaptor” modules are given CRUD operations on individual tiddlers to save somehow. We have a syncadaptor in the browser that uses TiddlyWiki’s serverside HTTP API to sync changes, and a syncadaptor for Node.js to save tiddlers to and from individual files

So, using savers implies using the single file configuration, and using syncadaptors implies saving wikis as individual tiddler files.

The vast majority of TiddlyWiki users seem to use the single file configuration, which has always been kind of a surprise, but I’ve come to understand that for most people the practical advantages of all-in-one-ness trumps the theoretical flexibility of separate files. That has turned out to be true even for technically sophisticated users. I interpret it to mean that people value the way that TiddlyWiki provides the user experience of a web application, but has the management semantics of a document file.

I’m really interested in this capability. It would enable a bunch of practices that have evolved in the community to be smoothly applied to Fission. Even if aren’t able to tackle it first, I’d like to understand how it would work, and get it on a public roadmap.

That all makes sense, and is very helpful. A first tentative way of splitting the implementation might be:

  1. Make a template for hosting an arbitrary TiddlyWiki as a Fission app that maintains its data in the users private app data storage. We could make a simple example of a TW for todo lists
  2. Use that template to build a TiddlyWiki app that enables users to register, open and save TiddlyWiki files stored anywhere in the users Fission drive (duplicating the functionality of TiddlyDesktop, as you note)

I found the same pattern with TiddlyDesktop: it uses nw.js, an unholy mashup of Chromium and Node.js. The first step was to build the scaffolding to allow TiddlyWikis to be hosted in nw.js, and the second was building a TiddlyWiki app that permits other wikis to be opened and saved.

Circling back to the saver vs syncer debate, in the case of TiddlyDesktop, the mother wiki uses a syncadaptor to save changes to individual tiddlers, while the child wikis use one of the core savers to save changes.

I hope we can do the same with Fission because it’s a convenient pattern for end users. If things go wrong with the configuration of TiddlyDesktop they can navigate to the folder containing the configuration tiddlers and delete or modify them as needed to get things working again.

By the, Whimsical Diagrams was new to me, very nice!