@tiddlywiki/mws 0.0.21 → 0.1.1

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

@@ -1,3 +1,2 @@
 list: HelloThere Installation Usage Reference
-title: $:/StoryList
-type: text/vnd.tiddlywiki
+title: $:/StoryList

package/editions/mws-docs/tiddlers/2025-02-18 - User Management.md.meta

@@ -1,5 +1,5 @@
 created: 20250507122308262
-modified: 20250507123125166
-tags: Notes
+modified: 20250624124256654
+tags: Notes Roadmap
 title: 2025-02-18 - User Management
 type: text/markdown

package/editions/mws-docs/tiddlers/2025-04-14 - client plugins /342/234/224/357/270/217.md"

@@ -0,0 +1,31 @@
+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. 
+
+----
+
+### Add a tiddler cache folder and render the tiddlers on startup
+
+- Store them either in-memory or in the file-system, depending on user preference.
+- The core tiddler and boot tiddlers could be stored in memory regardless because they are always served. 
+- Would it save some memory to store them as a buffer?
+- The stored content would be read directly onto the wire, optionally checking the hash. 
+
+### Add a plugin selector to the recipes form
+
+- The loading order needs to be changeable. 
+- It would just be an array of titles, and possibly other describing fields. 
+
+### Add a plugin field to the recipes table
+
+- Not sure if I need to create a plugins table but I probably just need a string array of plugin names. Titles tend to be authoritative in TiddlyWiki so the plugin title should be enough. Plugin titles which cannot be found would be somehow marked as not found, probably with a custom disabled plugin tiddler in the client and logging a warning in the server. 
+
+### What about SQL Filters?
+
+- I don't know, but we would be caching plugins either way. Everything about it is handled differently, so no matter what, there is almost guaranteed to be a clear separation between the two kinds of bags anyway. We'll worry about that when we get there.
+
+## Retrospective - 2025-06-24
+
+I ended up caching it according to the file path. The tiddlywiki file path works fine for those plugins. Third-party plugins will need to declare their own folder name somehow. The files are compressed and stored on disk. The cache is built on startup. The cache stores a `json`, `js`, and `js.gz` version of each plugin. 

package/editions/mws-docs/tiddlers/2025-04-14 - client plugins /342/234/224/357/270/217.md.meta"

@@ -0,0 +1,5 @@
+created: 20250624124545657
+modified: 20250624130605815
+tags: Roadmap
+title: 2025-04-14 - client plugins ✔️
+type: text/markdown

package/editions/mws-docs/tiddlers/{2025-05-04.md → 2025-05-04 - event hooks /342/234/224/357/270/217.md" }

@@ -10,4 +10,10 @@ I probably need a startup state object, which basically has the site config and
 
 I guess this is actually a significant rewrite, so once I get some of the initial pieces done, it should be more obvious. 
 
--- Arlen22
+-- Arlen22
+
+## Retrospective - 2025-06-24
+
+It was a significant rewrite. I separated MWS into three packages, one package for the events, one package for generic web server stuff, and one package for all the MWS logic. Getting config from the database is pretty simple. We do it on startup and then if a setting can be changed live, we just update the config property. For those settings, we store the value in the request state to make sure each request uses the same setting for the duration of the request.
+
+The only downside is that we have to make sure we import all the files that use the server events, but that's a small price to pay for the much higher flexibility. I'm sure there's a lint rule we could create somehow, but I haven't gotten to that yet. 

package/editions/mws-docs/tiddlers/2025-05-04 - event hooks /342/234/224/357/270/217.md.meta"

@@ -0,0 +1,5 @@
+created: 20250507122508552
+modified: 20250624130052652
+tags: Notes Roadmap
+title: 2025-05-04 - event hooks ✔️
+type: text/markdown

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

@@ -12,8 +12,4 @@ 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. 
 
-I also don't know why we aren't using the wiki mount point for the API, and putting the react UI under admin, since then it would free up the entire path space to use for a tree path structure. 
-
-I'm working on simplifying the internal code structure yet again, still focusing on getting everything up to speed with my latest ideas. 
-
 -- Arlen22

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

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

package/editions/mws-docs/tiddlers/Allowed Methods.tid

@@ -0,0 +1,8 @@
+created: 20250513222435866
+modified: 20250513222701838
+title: Allowed Methods
+type: text/vnd.tiddlywiki
+
+`OPTIONS, GET, HEAD, POST, PUT, DELETE`
+
+HTTP allows any methods so I have no idea why I should only allow these. We could really go all out. 

package/editions/mws-docs/tiddlers/Application Access & Security.md

@@ -1,98 +1,28 @@
 
-Users can be administered through two interfaces:
-
-1. Web-based Administrative Interface
-   - Accessible to all users.
-   - Provides graphical interface for user operations
-   - Real-time validation and feedback
-1. Command-line Interface (CLI) Tools
-   - Only available to server owner.
-   - Suitable for automation and scripting
-   - Enables batch operations
-   - Useful for system initialization
-
-Each user account contains the following essential components:
-
-- **Username**
-  - Must be unique across the system
-  - Case-sensitive
-  - Used for authentication and audit trails
-- **Password**
-  - Stored using secure hashing algorithms
-  - Never stored in plaintext
-  - Subject to complexity requirements
-- **Email**
-  - Eventually used for the obvious password reset.
-- **Role Assignments**
-  - Multiple roles can be assigned
-  - Inherited permissions from all assigned roles
-  - Dynamic permission calculation based on role combination
-
-## Access Levels
-
-Conceptually, there are 6 access levels.
+## Permissions
 
-- **Site owner** - has file system access to the server, and can run CLI commands. Presumably they also have a site admin account. 
-- **Site admin** - Users with the admin *role*. They can assign owners and change permissions, and have full read and write access. Most ACL checks are skipped for the admin role. 
-- **Entity owner** - Users who "own" an entity (bag or recipe). They can change permissions for that entity, and have full read and write access. *Entity admins* cannot change the owner.
-- **Entity admin** - Users granted the admin *permission* on an entity. They cannot change the owner, but they can change the permissions of other users for that entity. 
-- **Entity write** - Users granted the write *permission* on an enitity. They can list, read, create, update, and delete tiddlers, but cannot change permissions. 
-- **Entity read** - Users granted the read *permission* on an entity. They can list and read tiddlers, but cannot do anything else. 
+- **READ** - Read tiddlers from an entity.
+- **WRITE** - Write tiddlers to an entity.
+- **ADMIN** - Update ACL for an entity.
 
 ## Entities
 
 - **Bag** - A collection of tiddlers with unique titles
 - **Recipe** - A stack of bags in a specific order. Bags may inherit the ACL of a recipe they are included in. 
 
-## Roles
+## Roles (aka Groups)
 
 - Roles have names and descriptions
 - Multiple users can be assigned to a role
+- Roles are given *permissions* on *entities*
 
-## Permissions
-
-- **READ** - Read tiddlers from an entity.
-- **WRITE** - Write tiddlers to an entity.
-- **ADMIN** - Update ACL for an entity.
-
-## Admin
-
-- There is an admin *role* and an admin *permission*. 
-- Roles are given specific permissions for specific entities (bags and recipes).
-- The admin *role* has automatic admin *permission* for everything.
-
-## ACL
-
-- Grants the **Permission** for an **Entity** to a **Role**. 
-- Entities without an ACL are either public or private (configurable).
-
-## Ownership
-
-- Ownership of an entity grants the "admin" *permission*.
-- Only site admins can change the owner of an entity. 
-- Users with "admin" *permission* **cannot** change ownership.
-
-## User Types
-
-#### Administrator (ADMIN) Role
-
-- Full system access and configuration rights
-- Most access checks are skipped
-- Can create, modify, and delete user accounts
-- Manages role assignments and permissions
-- Has full permissions on all recipes and bags
-
-#### Regular Users
-
-- Created by administrators
-- Permissions determined by assigned roles
-- Access limited to specific recipes based on role permissions
-- Access to recipes without an ACL is based on recipe config
+## Access Levels
 
-#### Guest Users
+Conceptually, there are 6 access levels.
 
-- Users not logged in.
-- No inherent permissions
-- Can access recipes which allow it
-- Read/write can be enabled by server config
-- Useful for public wikis or documentation sites
+- **Site owner** - has file system access to the server, and can run CLI commands. Presumably they also have a site admin account and they can always create one via the CLI.
+- **Site admin** - Users with the admin *role*. They can assign owners and change permissions, and have full read and write access.
+- **Entity owner** - Owner of an entity (bag or recipe). They can change permissions for that entity, and have full read and write access.
+- **Entity admin** - Granted admin *permission*, they can manage permissions for the entity. 
+- **Entity write** - Granted write *permission*, they can list, read, create, update, and delete tiddlers, but cannot change permissions. 
+- **Entity read** - Granted read *permission* on an entity. They can list and read tiddlers, but cannot do anything else. 

package/editions/mws-docs/tiddlers/Application Access & Security.md.meta

@@ -1,5 +1,5 @@
 created: 20250428144431745
-modified: 20250428152640317
+modified: 20250613001943111
 tags: Reference
 title: Application Access & Security
 type: text/markdown

package/editions/mws-docs/tiddlers/Body Format.md

@@ -0,0 +1,19 @@
+
+`ignore`
+: `state.data` will be undefined. `state.reader` will be draining or already closed. 
+
+`stream`
+: `state.data` will be undefined. You must call `state.reader` to get the request. 
+
+`buffer`
+: `state.data` will be a Buffer. 
+
+`string` 
+: `state.data` will be a string.
+
+`json`
+: `state.data` will be read as a string, same as `string` and then parsed as JSON, with some sanity checks. If the string is zero-length, undefined will be returned without attempting to parse. This is the only case where undefined can be returned. If the JSON fails to parse, a `400 INVALID` response will be sent. `__proto__` and `constructor.prototype` are also checked. 
+
+`www-form-urlencoded` and `www-form-urlencoded-urlsearchparams`
+: Parse the body using `URLSearchParams` optionally calling `Object.entries` on it.
+: <div style="color: rgb(212, 212, 212); background-color: rgb(30, 30, 30); font-family: &quot;Fira Code&quot;, &quot;Cascadia Code&quot;, Consolas, &quot;Courier New&quot;, monospace, Consolas, &quot;Courier New&quot;, monospace; font-size: 15px; line-height: 20px; white-space: pre;"><div><span style="color: #569cd6;">const</span> <span style="color: #4fc1ff;">data</span> = <span style="color: #4fc1ff;">state</span>.<span style="color: #9cdcfe;">data</span> = <span style="color: #569cd6;">new</span> <span style="color: #4ec9b0;">URLSearchParams</span>((<span style="color: #c586c0;">await</span> <span style="color: #4fc1ff;">state</span>.<span style="color: #dcdcaa;">readBody</span>()).<span style="color: #dcdcaa;">toString</span>(<span style="color: #ce9178;">"utf8"</span>));</div><div><span style="color: #c586c0;">if</span> (<span style="color: #4fc1ff;">state</span>.<span style="color: #9cdcfe;">bodyFormat</span> === <span style="color: #ce9178;">"www-form-urlencoded"</span>) <span style="color: #4fc1ff;">state</span>.<span style="color: #9cdcfe;">data</span> = <span style="color: #4ec9b0;">Object</span>.<span style="color: #dcdcaa;">fromEntries</span>(<span style="color: #4fc1ff;">data</span>);</div></div>

package/editions/mws-docs/tiddlers/Body Format.md.meta

@@ -0,0 +1,4 @@
+created: 20250513231403024
+modified: 20250514014327153
+title: Body Format
+type: text/markdown

package/editions/mws-docs/tiddlers/Checklists and Features.md

@@ -10,6 +10,3 @@
 - Verify that all admin permissions are based on the admin role, not the first user.
 - Verify that admin's cannot remove the admin role from themselves. 
 
-## Recipes
-
-- 

package/editions/mws-docs/tiddlers/Checklists and Features.md.meta

@@ -1,5 +1,5 @@
 created: 20250505141032240
-modified: 20250505145404612
+modified: 20250613003924069
 tags: Reference
 title: Checklists and Features
 type: text/markdown

package/editions/mws-docs/tiddlers/Client Plugins.md

@@ -0,0 +1,17 @@
+[[Client Plugins]] are normal [[TiddlyWiki]] plugins. They are cached on the server and served directly to the client as needed. [[Server Plugins]], perhaps acting as third-party plugin libraries, may register additional [[Client Plugins]] and either add them to the cache immediately (if it's some small built-in plugin) or only when a recipe requires them (like a plugin library would). 
+
+On startup, all server plugins are called to generate their client plugins. The client plugins are saved in `cache/${path}/plugin.*`, using a relative path of the plugin's choosing. The same thing happens when a recipe's list of plugins changes.
+
+The wiki index file itself is also rendered with an empty store and saved at `cache/tiddlywiki5.html`.
+
+When a wiki page is opened, the index file is loaded and parsed. Plugins are either read directly into the store area, or script tags are inserted which point to the location of the cache folder. 
+
+MWS saves a hash of the plugin in memory so it can be served as an external JavaScript file with the script integrity attribute. The advantage of external JavaScript files is that the browser can cache them on subsequent page loads, reducing bytes transferred. Plugins can also be served directly in the index file, just like a normal single-file TiddlyWiki would. Regardless of which option is used, MWS optimizes memory usage by piping the file directly into the response (and onto the network) rather than reading everything into memory first. 
+
+
+
+
+
+
+
+

package/editions/mws-docs/tiddlers/Client Plugins.md.meta

@@ -0,0 +1,5 @@
+created: 20250513192622877
+modified: 20250613004524168
+tags: Architecture
+title: Client Plugins
+type: text/markdown

package/editions/mws-docs/tiddlers/HTTP API.md

@@ -3,15 +3,16 @@ The MultiWikiServer HTTP API provides management and tiddler endpoints.
 The design goals of the API are:
 
  - Connect the client and server as transparently as possible. 
- - Be easy to understand and use via Javascript. 
+ - Be easy to understand and use via JavaScript. 
  - Have strict validation of incoming requests.
 
 ## Management
 
 - On the client, most request paths are defined by a single adaptor function which accepts the input for the server and returns a promise which resolves to the server's parsed response.  
 - The server may throw a user error (or a string), which is expected to return to the client. It should give them an actionable understanding of what went wrong. 
-- The API essentially forwards a function call from the client to the server, using `fetch`. It expects a Javascript client, and is not intended to support form submissions directly.
 
 ## Tiddler
 
-The tiddler API was based on [the API of TiddlyWeb](https://tank.peermore.com/tanks/tiddlyweb/HTTP%20API), first developed in 2008 by Chris Dent, but is more oriented around JSON and Typescript. The concept of resources remains and in the future it will hopefully be adapted to serve static versions of tiddlers. 
+The tiddler API was based on [the API of TiddlyWeb](https://tank.peermore.com/tanks/tiddlyweb/HTTP%20API), first developed in 2008 by Chris Dent, but is more oriented around JSON and Typescript. 
+
+The concept of resources is central to the API and in the future it will hopefully be adapted to serve static versions of tiddlers. 

package/editions/mws-docs/tiddlers/HTTP API.md.meta

@@ -1,5 +1,5 @@
 created: 20250428152532763
-modified: 20250428152617476
+modified: 20250613003613708
 tags: Reference
 title: HTTP API
 type: text/markdown

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

@@ -1,5 +1,5 @@
 created: 20250417170314382
-modified: 20250417170403098
+modified: 20250612222324438
 tags: TableOfContents
 title: HelloThere
 type: text/vnd.tiddlywiki
@@ -19,4 +19,4 @@ Planned features include:
 * Instantaneous synchronisation of changes between the server and all connected clients
 * Workflow processing on the server, for example to automatically compress images, or to archive webpages
 
-MWS is currently [[under development at GitHub|https://github.com/TiddlyWiki/MultiWikiServer]] but it is already functional and usable.
+MWS is currently [[under development at GitHub|https://github.com/TiddlyWiki/MultiWikiServer]] but it is already functional and usable, [[except for user security|Security]]. 

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

@@ -1,5 +1,5 @@
 created: 20241105133737778
-modified: 20250428144159846
+modified: 20250612235731394
 tags: TableOfContents
 title: Installation
 type: text/vnd.tiddlywiki
@@ -25,9 +25,8 @@ To update your copy of MWS in the future with newer changes will require re-down
 
 !!! Git repo
 
-It is optionally recommended to save a history of your project configuration using git. 
+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. 
 
-If you decide to do this, you should move the wiki folder out of the project folder, and change the `wikiPath` setting accordingly. 

package/editions/mws-docs/tiddlers/MWS Architecture.tid

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

package/editions/mws-docs/tiddlers/Multi-user Trust.md

@@ -0,0 +1,12 @@
+
+If a user can write to a bag in a recipe, they can insert wiki-text which exports all the tiddlers in all recipes which contain that bag. 
+
+There are no real mitigations to this which can mitigate this completely, but there are some partial solutions which may help. 
+
+- Only allow loading modules from some bags.
+- Partitioned bags which only allow each user to write tiddlers prefixed with their username.
+- Use Content-Security-Policy headers to make the webpage read-only and block network requests. 
+
+I think what it really comes down to is that if you can't trust your users, don't give them write access. 
+
+Don't add untrusted bags to your recipes. 

package/editions/mws-docs/tiddlers/Multi-user Trust.md.meta

@@ -0,0 +1,5 @@
+created: 20250525173734256
+modified: 20250528202138460
+tags: Security
+title: Multi-user Trust
+type: text/markdown

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

@@ -1,5 +1,7 @@
 created: 20250507122827955
-modified: 20250507122829535
-tags: TableOfContents
+modified: 20250624125741539
+tags: 
 title: Notes
-type: text/vnd.tiddlywiki
+type: text/vnd.tiddlywiki
+
+<<toc>>

package/editions/mws-docs/tiddlers/Oracle Attacks.md

@@ -0,0 +1,29 @@
+Oracles are clues that give information about a response without revealing the actual response.
+
+Obviously none of this matters if your data isn't encrypted with HTTPS, since it's all open for everyone to read. But if it's encrypted, there are still ways of determining content. 
+
+## Compression Oracles
+
+A compression oracle is when an attack takes advantage of the deduplication that compression attempts to do by somehow managing to get their own plaintext inserted into the compression stream and then checking whether the compressed output increases in size or not. If it doesn't, then obviously that particularly plaintext was already in the response for that request. 
+
+## Length Oracle
+
+A similar attack involves inspecting the request length to determine whether a request returned any results. This is especially true of search features. A very big response implies returned results and a very tiny response implies no results. But there are also other ways to use the length which can come down to determining the exact number of bytes returned. 
+
+### Mitigations for normal oracles
+
+The attacks are usually done based on the timing of the response, so even if the response itself is opaque, the timing can usually still be inferred. 
+
+- Disable compression (ultimate mitigation but there are better solutions)
+- Disable third-party cookies (SameSite=strict) so cookies are only sent for requests that originate from a loaded webpage. However, this prevents the cookie from being sent to the initial page load. 
+- We could set two cookies and only enable compression if the cookie with SameSite=strict is present. Any code which can make a SameSite=strict request is normally considered privelaged code anyway, so we have bigger problems if an attacker can do that. 
+
+## MWS-specific oracles
+
+A cross-bag compression oracle would allow an attacker with write access in one bag to infer the contents of a different bag in the recipe which they do not have access to by somehow attacking someone who does have access to that recipe and watching how the browser compresses various things. Without directly reading the bag's contents, they can write to the bag they have access to and watch the responses being sent to the other user to infer the contents of the recipe overall. 
+
+If batching is enabled, and if updates have side effects which trigger a save which is then loaded by other browsers, and if the attacker manages to add a second save with the correct timing to load in the same batch as the update of the side effect, an oracle attack can occur.
+
+## MWS mitigations
+
+- The simplest mitigation is to never compress the contents of two bags together. 

package/editions/mws-docs/tiddlers/Oracle Attacks.md.meta

@@ -0,0 +1,5 @@
+created: 20250522165353915
+modified: 20250525173758686
+tags: Security
+title: Oracle Attacks
+type: text/markdown

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

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

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

@@ -1,5 +1,5 @@
 created: 20250428144428969
-modified: 20250428152626286
+modified: 20250612170354797
 tags: TableOfContents
 title: Reference
 type: text/x-markdown

package/editions/mws-docs/tiddlers/Request Handling.md

@@ -0,0 +1,53 @@
+
+1. **Entry Point**: `Router.handle()`
+   - Takes HTTP/HTTP2 request and response objects
+   - Wraps `handleRequest()` in error handling
+
+2. **Main Request Processing**: `Router.handleRequest()`
+   - Emit middleware event
+   - Apply Helmet middleware
+   - Create Streamer instance
+   - Call `handleStreamer()`
+
+3. **Stream Processing**: `Router.handleStreamer()`
+   - Emits streamer event
+   - Finds matching route using `findRoute()`
+   - Performs security checks (CSRF protection)
+   - Processes request body based on `bodyFormat`
+   - Creates `ServerRequest` instance
+   - Calls `handleRoute()`
+
+4. **Route Matching**: `Router.findRoute()` and `findRouteRecursive()`
+   - Recursively matches URL path against defined routes
+   - Handles nested routes
+   - Matches HTTP methods
+   - Returns array of matched route segments
+
+5. **Route Handling**: `Router.handleRoute()`
+   - Executes handlers for matched routes in sequence
+   - Emits handle event
+   - Falls back to 404 if no handler sends response
+
+## Body Format Processing
+
+The router supports multiple body formats:
+- `stream`: Raw streaming data
+- `string`: UTF-8 string
+- `json`: Parsed JSON data
+- `buffer`: Raw buffer
+- `www-form-urlencoded`: Parsed form data as object
+- `www-form-urlencoded-urlsearchparams`: Form data as URLSearchParams
+- `ignore`: Ignores request body (default for GET/HEAD)
+
+## Security Features
+
+- Built-in Helmet middleware for security headers
+- CSRF protection via `x-requested-with` header checks
+- JSON security parsing (protects against prototype pollution)
+- Method matching validation
+- Path validation
+
+
+The routes are hierarchical, allowing for nested routes with inherited properties and progressive URL path matching.
+
+It is important that the entire request path be awaited and eventually resolve or reject. A promise should never be left hanging. The Router class takes care of making sure every request has finished with some response, but if the promise never resolves or rejects, the request will eventually time out. 

package/editions/mws-docs/tiddlers/Request Handling.md.meta

@@ -0,0 +1,5 @@
+created: 20250601093342424
+modified: 20250613012220446
+tags: Architecture
+title: Request Handling
+type: text/markdown

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

@@ -0,0 +1,7 @@
+created: 20250624123955289
+modified: 20250624124015029
+tags: TableOfContents
+title: Roadmap
+type: text/vnd.tiddlywiki
+
+<<toc>>