@tiddlywiki/mws 0.1.8 → 0.1.11

package/editions/mws-docs/tiddlers/$__StoryList.tid

@@ -1,2 +1,5 @@
-list: HelloThere Installation Usage Reference
-title: $:/StoryList
+created: 20250901000936475
+list: [[Server Routes]]
+modified: 20250901003004551
+title: $:/StoryList
+type: text/vnd.tiddlywiki

package/editions/mws-docs/tiddlers/$__config_RelinkOnRename.tid

@@ -0,0 +1,6 @@
+created: 20250717212338113
+modified: 20250717212338113
+title: $:/config/RelinkOnRename
+type: text/vnd.tiddlywiki
+
+yes

package/editions/mws-docs/tiddlers/2025-05-06 - syncer design.md

@@ -12,4 +12,8 @@ There also isn't a good way to move tiddlers between levels. Admins will need to
 
 I'm not good at wikitext, but I can provide the endpoints for all of these operations as well as the client-side adapters and actions to use them. 
 
--- Arlen22
+-- Arlen22
+
+## Update 2025-07-09
+
+I've come up with a solution for this and opened a PR on GitHub [#9117](https://github.com/TiddlyWiki/TiddlyWiki5/pull/9117). I've also included the changes in the client plugin so MWS wikis can make use of them already. This is temporary and only allowed because the current version of MWS is still considered experimental. 

package/editions/mws-docs/tiddlers/2025-05-06 - syncer design.md.meta

@@ -1,5 +1,5 @@
 created: 20250507031006573
-modified: 20250624130310879
+modified: 20250709174613734
 tags: Notes Roadmap
 title: 2025-05-06 - syncer design
 type: text/markdown

package/editions/mws-docs/tiddlers/Bag.md

@@ -0,0 +1 @@
+A bag is an [[Entity]] that stores tiddlers.

package/editions/mws-docs/tiddlers/Bag.md.meta

@@ -0,0 +1,4 @@
+created: 20250717034520360
+modified: 20250717035423554
+title: Bag
+type: text/markdown

package/editions/mws-docs/tiddlers/Bags and Recipes Complex Example.md

@@ -0,0 +1,11 @@
+A more complex example might be for a teacher working with a group of students:
+
+- **student-{name}** bag for each students work
+- **teacher-course** bag for the coursework, editable by the teacher
+- **teacher-tools** bag for custom tools used by the teacher
+
+Those bags would be exposed through the following hosted wikis:
+
+- **student-{name}** hosted wiki for each students work, including the coursework material
+- **teacher-course** hosted wiki for the coursework, editable by the teacher
+- **teacher** hosted wiki for the teacher, bringing together all the bags, giving them an overview of all the students work

package/editions/mws-docs/tiddlers/Bags and Recipes Complex Example.md.meta

@@ -0,0 +1,4 @@
+created: 20250718011700377
+modified: 20250718031126481
+title: Bags and Recipes Complex Example
+type: text/markdown

package/editions/mws-docs/tiddlers/Bags and Recipes Model.md

@@ -0,0 +1,14 @@
+The bags and recipes model is a reference architecture for how tiddlers can be shared between multiple wikis. It was first introduced by TiddlyWeb in 2008.
+
+The principles of bags and recipes can be simply stated:
+
+1. Tiddlers are stored in named "bags"
+2. Bags have access controls that determines which users can read or write to them
+3. Recipes are named lists of bags, ordered from lowest priority to highest
+4. The tiddlers within a recipe are accumulated in turn from each bag in the recipe in order of increasing priority. Thus, if there are multiple tiddlers with the same title in different bags then the one from the highest priority bag will be used as the recipe tiddler
+5. Wikis are composed by splicing the tiddlers from the corresponding recipe into the standard TW5 HTML template
+
+[[Bags and Recipes Simple Example]]
+
+[[Bags and Recipes Complex Example]]
+

package/editions/mws-docs/tiddlers/Bags and Recipes Model.md.meta

@@ -0,0 +1,4 @@
+created: 20240309135835396
+modified: 20250718012016047
+title: Bags and Recipes Model
+type: text/markdown

package/editions/mws-docs/tiddlers/Bags and Recipes Simple Example.md

@@ -0,0 +1,13 @@
+A very simple example of the recipe/bag model might be for a single user who maintains the following bags:
+
+- **recipes** - tiddlers related to cooking recipes
+- **work** - tiddlers related to work
+- **app** - common tiddlers for customising TiddlyWiki
+
+Those bags would be used with the following recipes:
+
+- **recipes** --> recipes, app - wiki for working with recipes, with common custom components
+- **work** --> work, app - wiki for working with work, with common custom components
+- **app** --> app - wiki for maintaining custom components
+
+All of this will work dynamically, so changes to the app bag will instantly ripple into the affected hosted wikis.

package/editions/mws-docs/tiddlers/Bags and Recipes Simple Example.md.meta

@@ -0,0 +1,4 @@
+created: 20250718011135237
+modified: 20250718031933624
+title: Bags and Recipes Simple Example
+type: text/markdown

package/editions/mws-docs/tiddlers/Code Layout.md

@@ -0,0 +1,94 @@
+
+The MWS repo is divided into separate projects in the `packages` folder. The entry point is in `packages/mws/src/index.ts`. The entry point imports the `server`, `commander`, and `events` projects. 
+
+The entire server uses Promises and async functions for pretty much everything. Synchronous file system calls should be avoided as much as possible. 
+
+The `events` project is the foundation of MWS. It contains an `EventEmitter` instance that everything else subscribes to. 
+
+Events are emitted asyncly. Event listeners are awaited with `Promise.all`, and rejections throw back to the event emit call. This is intentional because it is the heart of the entire server, not just a public event bus, and errors shouldn't be ignored. Errors that come from things like attempting to send SSE events to other clients, however, should not be thrown because they aren't relevent to the source of the event. 
+
+There should be no singleton references other than the event emitter and event handlers should be as pure as possible, so that in theory it would be possible to run multiple completely separate MWS servers in the same process.
+
+The `commander` project handles the CLI parsing code. It exports a default function which MWS calls to execute the CLI. Commander emits several events during execution, which MWS hooks into to scaffold the rest of the server. 
+
+It also exports the base class for commands to inherit from, and because it instantiates the commands, commands should not specify their own constructor. Additional instance properties may be added to commands in the `cli.execute.before` event. 
+
+The `server` project handles all web related stuff, but in an MWS-agnostic way. It only requires the `events` project, so it could be used as the foundation for unrelated webservers. Its internal API is directly inspired by the TiddlyWiki server API, with routing and centralized handling of the request body. 
+
+The `mws` project is the application layer of MWS and ties everything else together. It defines all the commands and web server routes and handles the database connection. 
+
+The `react-admin` package is the Admin UI. It's based on react, and is built automatically when the dev server is enabled. You can find the server route in `packages/mws/src/services/setupDevServer.ts`
+
+## Events
+
+If this all sounds a bit confusing, here are the events that are emitted on a normal startup. 
+
+- `zod.make`  - Emitted by `server` to extend the zod global.
+- `cli.register`  - Emitted by `commander` to register commands.
+- `cli.commander` - Emitted by `commander` after routes are registered, but before help is printed. 
+- `cli.execute.before` - Emitted by `commander` right before the command is executed. This allows adding properties to the command instance for use later in the application. 
+
+These next ones are attachment points for further extension of MWS. They are emitted in the main `cli.execute.before` listener that MWS attaches.  
+
+- `mws.cache.init.before`
+- `mws.cache.init.after`
+- `mws.adapter.init.before`
+- `mws.adapter.init.after`
+- `mws.config.init.before`
+- `mws.config.init.after`
+
+Next, these are emitted by the listen command, either by `mws` or by `server`. 
+
+- `listen.router.init`
+- `mws.router.init`
+- `mws.routes.important`
+- `mws.routes`
+- `mws.routes.fallback`
+
+And finally the event emitted after the command ends. 
+
+- `cli.execute.after`
+
+## Event nesting
+
+Some of them are nested. For instance, if I log the event name when it is emitted, and then how long it took when it completes, this is the output (indented for clarity).
+
+```
+zod.make
+zod.make: 0.123ms
+
+cli.register
+cli.register: 0.088ms
+
+cli.commander
+cli.commander: 0.019ms
+
+cli.execute.before
+  mws.cache.init.before
+  mws.cache.init.before: 0.014ms
+  mws.cache.init.after
+  mws.cache.init.after: 0.013ms
+  mws.adapter.init.before
+  mws.adapter.init.before: 0.007ms
+  mws.adapter.init.after
+  mws.adapter.init.after: 0.006ms
+  mws.config.init.before
+  mws.config.init.before: 0.008ms
+  mws.config.init.after
+  mws.config.init.after: 0.009ms
+cli.execute.before: 1.171s
+
+listen.router.init
+  mws.router.init
+  mws.router.init: 0.012ms
+  mws.routes.important
+  mws.routes.important: 0.006ms
+  mws.routes
+  mws.routes: 2.754ms
+  mws.routes.fallback
+  mws.routes.fallback: 0.054ms
+listen.router.init: 4.002ms
+
+cli.execute.after
+cli.execute.after: 0.015ms
+```

package/editions/mws-docs/tiddlers/Code Layout.md.meta

@@ -0,0 +1,5 @@
+created: 20250710211718128
+modified: 20250710211749763
+tags: Architecture
+title: Code Layout
+type: text/markdown

package/editions/mws-docs/tiddlers/Entity Access Control.md

@@ -0,0 +1 @@
+Each [[Entity]] has a list of roles and the [[permissions|Entity Permissions]] they have on that entity. 

package/editions/mws-docs/tiddlers/Entity Access Control.md.meta

@@ -0,0 +1,5 @@
+created: 20250713025613925
+modified: 20250714124428825
+tags: Reference
+title: Entity Access Control
+type: text/markdown

package/editions/mws-docs/tiddlers/Entity Owner.md

@@ -0,0 +1,3 @@
+When a user creates an [[Entity]], they can optionally become the owner of the entity. Owners have full [[permission|Entity Permissions]] over the entity. There can only be one or no owner of an entity. 
+
+Entity owners can not transfer ownership to another user. Only [[site admins|Site Admin]] can change ownership.

package/editions/mws-docs/tiddlers/Entity Owner.md.meta

@@ -0,0 +1,4 @@
+created: 20250713030055363
+modified: 20250714125005911
+title: Entity Owner
+type: text/markdown

package/editions/mws-docs/tiddlers/Entity Permissions.md

@@ -0,0 +1,7 @@
+There are 3 levels of permissions that can be assigned on the [[Entity Access Control]] list.
+
+- **ADMIN** - Update the [[Entity Access Control]] list for this entity. Also granted WRITE and READ.
+- **WRITE** - Create, update, and delete tiddlers. Also granted READ.
+- **READ** -  List and read tiddlers.
+
+The [[Entity Owner]] and the [[site admins|Site Admin]] have full permissions over the [[entity]].

package/editions/mws-docs/tiddlers/Entity Permissions.md.meta

@@ -0,0 +1,4 @@
+created: 20250713025717567
+modified: 20250718013201161
+title: Entity Permissions
+type: text/markdown

package/editions/mws-docs/tiddlers/Entity.md

@@ -0,0 +1,3 @@
+An entity is a [[Bag]] or a [[Recipe]]. 
+
+Configuring what certain roles can do to entities is done with [[Entity Access Control]].

package/editions/mws-docs/tiddlers/Entity.md.meta

@@ -0,0 +1,5 @@
+created: 20250713025508951
+modified: 20250717212511382
+tags: 
+title: Entity
+type: text/markdown

package/editions/mws-docs/tiddlers/HelloThere.tid

@@ -1,5 +1,5 @@
 created: 20250417170314382
-modified: 20250612222324438
+modified: 20250717214743442
 tags: TableOfContents
 title: HelloThere
 type: text/vnd.tiddlywiki
@@ -11,7 +11,7 @@ type: text/vnd.tiddlywiki
 
 Planned features include:
 
-* Hosting multiple wikis at once, using the [[Bags and Recipes]] mechanism for sharing data between them
+* Hosting multiple wikis at once, using the [[Bags and Recipes Model]] for sharing data between them
 * Full support for SQLite, as well as MariaDB/MySQL, Postgres, and Microsoft SQL Server
 * Robust built-in synchronisation handlers for syncing data to the filesystem
 * Flexible authentication and authorisation options

package/editions/mws-docs/tiddlers/Installation.md

@@ -0,0 +1,31 @@
+These instructions require minimal knowledge of the terminal and require NodeJS to be installed.
+
+- Open a terminal window and set the current directory to the folder you want to create the project folder in. 
+- The init command creates the project folder and installs the required dependencies and config files. You can change the name to whatever you like. 
+<<.copy-code-to-clipboard """npm init @tiddlywiki/mws@latest "new_folder_name" """>>
+- Set the current directory to the project folder that was just created: 
+<<.copy-code-to-clipboard """cd "new_folder_name" """>>
+- Initialize the database 
+<<.copy-code-to-clipboard "npx mws init-store">>
+- Start MWS: 
+<<.copy-code-to-clipboard "npx mws listen --listener">>
+- Visit [[http://localhost:8080/]] in a browser on the same computer. 
+- When you have finished using MWS, stop the server with <kbd>ctrl-C</kbd>
+
+See [[Troubleshooting]] if you encounter any errors.
+
+### Updating MWS
+
+To update your copy of MWS in the future with newer changes will require re-downloading the code, taking care not to lose any changes you might have made.
+
+- Make a backup: Copy or zip your project folder to a safe backup folder.  <<.copy-code-to-clipboard """tar -cf archive.tar "new_folder_name" """>>
+- Get the latest version. Notice that the second word is `install` instead of `init`. This pulls the latest version from NPM and installs it. <<.copy-code-to-clipboard "npm install @tiddlywiki/mws@latest --save-exact">>
+- Run MWS. On startup, MWS checks the database schema and updates it automatically if there are changes. Normally this works just fine, but it can fail, which is why it's important to save a backup first. 
+
+### Git repo
+
+It is recommended to save a history of your project configuration using git, 
+
+- On Windows you can use [[GitHub Desktop|https://github.com/apps/desktop]]. 
+- On Linux, git is usually preinstalled or available via the default package manager for your distro. 
+

package/editions/mws-docs/tiddlers/Installation.md.meta

@@ -0,0 +1,5 @@
+created: 20241105133737778
+modified: 20250714123715061
+tags: TableOfContents
+title: Installation
+type: text/markdown

package/editions/mws-docs/tiddlers/MWS Architecture_1.md

@@ -0,0 +1,2 @@
+<<toc>>
+

package/editions/mws-docs/tiddlers/{MWS Architecture.tid → MWS Architecture_1.md.meta }

@@ -1,7 +1,5 @@
 created: 20250612170433199
-modified: 20250612170434896
+modified: 20250710211738963
 tags: TableOfContents
 title: Architecture
-type: text/vnd.tiddlywiki
-
-<<toc>>
+type: text/markdown

package/editions/mws-docs/tiddlers/Recipe Bag Priority.md

@@ -0,0 +1,5 @@
+A [[Recipe]] orders its [[bags|Bag]] by priority.
+
+If there are tiddlers with duplicate names in different bags, the tiddler from the bag that is higher in the priority list is used as the recipe tiddler.
+
+New tiddlers are added to the bag at top of the list.

package/editions/mws-docs/tiddlers/Recipe Bag Priority.md.meta

@@ -0,0 +1,4 @@
+created: 20250717213602278
+modified: 20250718012651305
+title: Recipe Bag Priority
+type: text/markdown

package/editions/mws-docs/tiddlers/Recipe.tid

@@ -0,0 +1,6 @@
+created: 20250717212608133
+modified: 20250717213112789
+title: Recipe
+type: text/vnd.tiddlywiki
+
+A recipe is an [[Entity]] that stores a list of bags by [[priority|Recipe Bag Priority]].

package/editions/mws-docs/tiddlers/Security.md

@@ -11,17 +11,17 @@ The primary use cases for MWS are
 
 While these are the goals of MWS, it is still in early development, so none of these security restraints have actually been put in place yet. This is a work in progress, and the direction we're headed. 
 
-## Potential weaknesses
-
-- **Not using HTTPS**
-- **Oracles** that leak information through observable side-effects, such as network traffic, without directly revealing the contents. 
-- **Multi-user**: Users with write access can modify bags to gain access to other tiddlers in a different recipe that are supposed to be private. 
-
 ## Don't add untrusted bags to your recipe. 
 
 Generally speaking, wiki text is quite powerful, almost as powerful as JavaScript. Button clicks can run widget actions, which can read and change any tiddler in the current recipe. Any user could easily cause TiddlyWiki to write tiddlers to other bags via actions. 
 
-A possible protection from this is using the referrer header to restrict edits to from a wiki to only follow the rules for the recipe that is open. In other words, if you have a recipe open, code in that page cannot use your credentials to somehow write to unrelated bags. 
+A user can also modify a bag they have write access to so that when a different user loads that bag in their own recipe it gives the first user access to tiddlers that the second user would consider private. This flaw is almost inherent to the idea of bags and recipes and cannot be avoided. 
+
+## Potential weaknesses
+
+- **Not using HTTPS** is always the number one weakness. If you're on an open WIFI network, your session info can be read by anyone within 100 meters.
+- **Oracles** that leak information through observable side-effects, such as network traffic, without directly revealing the contents. 
+- **Multi-user**: Users with write access can modify bags to gain access to other tiddlers in a different recipe that are supposed to be private. 
 
 ## Protection strategies
 

package/editions/mws-docs/tiddlers/Security.md.meta

@@ -1,5 +1,5 @@
 created: 20250522181107057
-modified: 20250612224336089
+modified: 20250709133857831
 tags: TableOfContents
 title: Security
 type: text/markdown

package/editions/mws-docs/tiddlers/Server Routes.md

@@ -0,0 +1,54 @@
+The routing for the server uses the same concept of routes as the TiddlyWiki core server, but significantly enhanced with TypeScript types and request helpers and primitives, including request validation.
+
+## Server Routing
+
+Routes are registered as a tree. The router starts at the root node and works its way down, using the regex and method of each route to check if the request matches. Once it finds a match, it recursively checks the children of those matches. 
+
+- The request method is "narrowed". Parent routes restrict the methods their child routes can accept. 
+
+Once the full route is determined, it handles the request body based on the options of the matched route, then it calls each handler, starting with the root handler, and continuing down.
+
+- The request body format is determined by the parent routes, and child routes cannot change the body format if a parent route sets it.
+
+In the example below, if the request matches child 2a, the router calls the root handler, then the child 2 handler, then the child 2a handler. 
+
+---
+
+[root] 
+
+- child 1
+  - child 1a
+- child 2
+  - child 2a
+  - child 2b
+
+---
+
+## Server Route Definition
+
+The type definitions for this interface contains comments with more details. Please see that for more info. 
+
+- **path**: A regular expression (must start with `^` to match the start of the path)
+- **pathParams**: Keys for the Regex match params. The object is added to the request state.
+- **method**: Array of methods supported by this route.
+- **bodyFormat**: The desired body format for this route. Ignored if the parent also specifies a body format. 
+- **denyFinal**: Parent routes can set this so the request is rejected if no child routes are matched. 
+- **securityChecks**: additional security checks for the server to perform.
+  - **requestedWithHeader**: requires a custom `X-Requested-With` header to be set to one of the valid values (`fetch`, `XMLHttpRequest`, `TiddlyWiki`) in order to prevent form and `no-cors` requests. 
+
+## Request Validation
+
+The `zodRoute` helper function implements validation checks and additional typing for the request object. See the comments and types in the `zodRoute` file for further information.  
+
+The zod options accept a function which returns a zod schema (or a hashmap of keys to zod schemas). 
+
+- **zodPathParams**: the path params object
+- **zodQueryParams**: the query params object
+- **zodRequestBody**: the request body
+- The **path** is a string instead of a regex. The path is split on the `/` and names starting with a colon become path params. 
+- The **method**, **body format**, and **security checks** are same as above. 
+- **registerError**: An error instance to capture a stack trace in case it's needed for any reason. Note that in most runtimes the performance penalty is incurred when the stack trace is read, not when the error instance is created. 
+
+
+
+

package/editions/mws-docs/tiddlers/Server Routes.md.meta

@@ -0,0 +1,5 @@
+created: 20250831152841666
+modified: 20250901003034562
+tags: Architecture Developers
+title: Server Routes
+type: text/markdown

package/editions/mws-docs/tiddlers/Site Admin.md

@@ -0,0 +1,3 @@
+The "Site Admin" is a role created by MWS. It can do everything on the site. 
+
+It is distinct from the [[admin permission|Entity Permissions]] on entities. 

package/editions/mws-docs/tiddlers/Site Admin.md.meta

@@ -0,0 +1,4 @@
+created: 20250714125009642
+modified: 20250718005750287
+title: Site Admin
+type: text/markdown

package/editions/mws-docs/tiddlers/Wiki.md

@@ -0,0 +1,2 @@
+Wikis are the user interfaces for [[recipes|Recipe]], and are available at <host>/wiki/<recipe>.
+TiddlyWiki 5 is the default wiki for new recipes.

package/editions/mws-docs/tiddlers/Wiki.md.meta

@@ -0,0 +1,4 @@
+created: 20250718020459001
+modified: 20250718022736895
+title: Wiki
+type: text/markdown

package/editions/mws-docs/tiddlers/system/$__palettes_MUI_styles.css

@@ -145,7 +145,7 @@ type: text/css
   /* --------------------------------------------------------------------- */
   /* Typography                                                            */
   /* --------------------------------------------------------------------- */
-  --foreground: var(--color-grey-900);
+  --foreground: var(--color-grey-800);
   /* text.primary */
   --muted-foreground: var(--color-grey-700);
   /* text.secondary */

package/editions/mws-docs/tiddlers/system/$__palettes_MUI_styles.css.meta

@@ -1,6 +1,6 @@
 created: 20250513234032612
 description: Colors reflecting the MWS admin UI, responsive to system settings.
-modified: 20250613012927316
+modified: 20250901002906435
 tags: $:/tags/Stylesheet
 title: $:/palettes/MUI/styles
 type: text/css

package/mws.run.mjs

@@ -19,7 +19,7 @@ if(!pkg?.dependencies?.["@tiddlywiki/mws"] || pkg.name !== "@tiddlywiki/mws-inst
   process.exit(1);
 }
 
-import(`${cwd}/node_modules/@tiddlywiki/mws/dist/mws.js`).then(mws => mws.default()).catch(console.error);
+import(`file://${cwd}/node_modules/@tiddlywiki/mws/dist/mws.js`).then(mws => mws.default()).catch(console.error);
 
 function tryParseJSON(file) {
   try {
@@ -27,4 +27,4 @@ function tryParseJSON(file) {
   } catch(e) {
     return undefined;
   }
-}
+}

package/package.json

@@ -2,7 +2,7 @@
   "name": "@tiddlywiki/mws",
   "description": "TiddlyWiki Multiple Wiki Server",
   "private": false,
-  "version": "0.1.8",
+  "version": "0.1.11",
   "bin": {
     "mws": "./mws.run.mjs"
   },

package/plugins/client/src/multiwikiclientadaptor.ts

@@ -124,6 +124,8 @@ interface SyncAdaptor<AD> {
 
 	isReady?(): boolean;
 
+	registerSyncer?(syncer: Syncer<AD>): void;
+
 	getStatus?(
 		cb: ServerStatusCallback
 	): void;
@@ -190,6 +192,7 @@ interface SyncAdaptor<AD> {
 	displayLoginPrompt?(syncer: Syncer<AD>): void;
 	login?(username: string, password: string, cb: (err: any) => void): void;
 	logout?(cb: (err: any) => void): any;
+
 }
 interface SyncerTiddlerInfo<AD> {
 	/** this comes from the wiki changeCount record */
@@ -249,7 +252,7 @@ class MultiWikiClientAdaptor implements SyncAdaptor<MWSAdaptorInfo> {
 	private serverUpdateConnectionStatus!: string;
 	private isDevMode: boolean;
 	private useGzipStream: boolean;
-	private triggerPoll: (() => void) | null = null;
+	private syncer: Syncer<MWSAdaptorInfo> | null = null;
 
 	name = "multiwikiclient";
 	private supportsLazyLoading = true;
@@ -283,15 +286,21 @@ class MultiWikiClientAdaptor implements SyncAdaptor<MWSAdaptorInfo> {
 	setLoggerSaveBuffer(loggerForSaving: Logger) {
 		this.logger.setSaveBuffer(loggerForSaving);
 	}
+	
 	isReady() {
 		return true;
 	}
-	subscribe(callback: () => void) {
-		// TODO: not working at the moment for some reason
-		console.log("Subscribing to server updates");
-		this.triggerPoll = callback;
-		this.connectRecipeEvents();
+	
+	registerSyncer(syncer: Syncer<MWSAdaptorInfo>): void {
+		this.syncer = syncer;
+		if (this.useServerSentEvents)
+			this.connectRecipeEvents();
+	}
+
+	triggerPoll() {
+		this.syncer?.syncFromServer();
 	}
+
 	private getHost() {
 		var text = this.wiki.getTiddlerText(CONFIG_HOST_TIDDLER, DEFAULT_HOST_TIDDLER), substitutions = [
 			{ name: "protocol", value: document.location.protocol },
@@ -540,9 +549,7 @@ class MultiWikiClientAdaptor implements SyncAdaptor<MWSAdaptorInfo> {
 		// 	this.syncer && this.syncer.enqueueLoadTiddler(title);
 		// }
 	}
-	private get syncer() {
-		if ($tw.syncadaptor === this) return $tw.syncer as Syncer<MWSAdaptorInfo>;
-	}
+
 	async loadTiddlers(options: {
 		syncer: Syncer<MWSAdaptorInfo>;
 		titles: string[];

package/plugins/client/tiddlers/syncer/multiwikiclientadaptor.js

@@ -31,7 +31,7 @@ var CONFIG_HOST_TIDDLER = "$:/config/multiwikiclient/host", DEFAULT_HOST_TIDDLER
 var SERVER_NOT_CONNECTED = "NOT CONNECTED", SERVER_CONNECTING_SSE = "CONNECTING SSE", SERVER_CONNECTED_SSE = "CONNECTED SSE", SERVER_POLLING = "SERVER POLLING";
 class MultiWikiClientAdaptor {
     constructor(options) {
-        this.triggerPoll = null;
+        this.syncer = null;
         this.name = "multiwikiclient";
         this.supportsLazyLoading = true;
         this.error = null;
@@ -66,11 +66,14 @@ class MultiWikiClientAdaptor {
     isReady() {
         return true;
     }
-    subscribe(callback) {
-        // TODO: not working at the moment for some reason
-        console.log("Subscribing to server updates");
-        this.triggerPoll = callback;
-        this.connectRecipeEvents();
+    registerSyncer(syncer) {
+        this.syncer = syncer;
+        if (this.useServerSentEvents)
+            this.connectRecipeEvents();
+    }
+    triggerPoll() {
+        var _a;
+        (_a = this.syncer) === null || _a === void 0 ? void 0 : _a.syncFromServer();
     }
     getHost() {
         var text = this.wiki.getTiddlerText(CONFIG_HOST_TIDDLER, DEFAULT_HOST_TIDDLER), substitutions = [
@@ -295,10 +298,6 @@ class MultiWikiClientAdaptor {
         // 	this.syncer && this.syncer.enqueueLoadTiddler(title);
         // }
     }
-    get syncer() {
-        if ($tw.syncadaptor === this)
-            return $tw.syncer;
-    }
     loadTiddlers(options) {
         return __awaiter(this, void 0, void 0, function* () {
             const { syncer, titles, onNext, onDone, onError } = options;

package/plugins/client/tiddlers/syncer/syncer.js

@@ -139,9 +139,9 @@ function Syncer(options) {
 			self.handleLazyLoadEvent(title);
 		});		
 	}
-	if(this.syncadaptor.subscribe) this.syncadaptor.subscribe(function(){
-		self.syncFromServer();
-	});
+
+	if(this.syncadaptor.registerSyncer)	
+		this.syncadaptor.registerSyncer(this);
 
 	// Get the login status
 	this.getStatus(function(err,isLoggedIn) {