Roadmap

(sort of)

Features

• Bag & Recipe system for storing tiddlers.
• User and Role management with ACL.
• Attachment system for storing binary tiddlers on the file system.
• Various import and export commands (currently still in development).

Planned (hopefully) for the future

• AuthJS or a similar integration that supports third-party OAuth (you can already write your own).
• Compiling filters to SQL to optimize memory on both the client and server.
• Support for other database and storage systems. Most likely MariaDB and Postgres.
• Additional recipe strategies with features like prefixed bags and namespaces.
• Server rendering of pages, for a more wikipedia-like experience.
• Some kind of plugin system which provides a level of server-side access into the request path

Plugin system

We need the MWS server to be as modular as possible. Obviously certain things, like the route implementations, are difficult to make modular. But various sections are much more self-contained, or interact with the rest of the codebase in a small, well-defined way, and these can be turned into pluggable services.

Server routes for various sections of the UI can be kept separate, so the recipe/bag manger, user manager, and actual wiki routes can be put in separate modules so that one of them can easily be rewritten without affecting the others.

All of them interact with the database via the prisma adapter, which can be modified to handle different databases. We should support mariadb, sqlite, and postgresql to cover the main ones. Making sure the prisma client covers all three is probably important. There may be small differences between the prisma client for different database types, although this will be reflected in the types, so we should be able to figure that out pretty easily.

The attachment store isn't something I've taken a close look at.

The tiddlywiki instance on the server might stay. At this point I don't think we actually need it for anything besides rendering the index wiki. That might be moved to the start command instead of being part of the mws runtime. But it's also used for various import and export commands which still need to be available on the cli. We could make loading optional, or unload it after commands have completed, or once mws-listen starts.

I don't think things are quite where they should be with the client either. Currently we're adding recipe tiddlers into the wiki page dynamically, which is expected, but there are like six tiddlers that are being rendered statically, which doesn't really make sense. It also doesn't make sense that we're dumping some plugins into the database but rendering core from tiddlywiki, since this results in a version mismatch.

At the same time, we really don't want to be rendering plugins every time. They do need to be cached somewhere so they can be loaded quickly. I wonder if it would work to cache them in the wiki folder, per tiddlywiki version, so if you upgrade it would just create a new folder. The boot tiddlers would be cached in the folder as well. If we do it right, we wouldn't even have to parse the file, just read it onto the wire. We'd probably need an index file to keep everything straight. We could add plugins/themes/languages support to the wiki folder as well, which would also get cached in the same way. We could make a way for caching to be disabled, perhaps by adding a field to plugin.info.

It would be useful if the plugin syntax could specify NPM modules. We already have the + and ++ syntax. I'm not sure exactly how it'd work, but the NPM package would need to determine it's own path, which is fairly simple, and then export that so it can be imported via the standard import mechanism. Obviously the package would need to be installed, and it should probably be imported into the run file and then added as an absolute path to the list of imports. Actually, I guess that's already possible, so I just need to add the list of imports part of it.

-- 2025/04/13 - Arlen22