@tiddlywiki/mws 0.0.21 → 0.1.1

package/editions/mws-docs/tiddlers/Route Definers.md

@@ -0,0 +1,206 @@
+
+
+## Basic Route Definer
+
+The original route definer which I used to type TiddlyWiki server routes, but the types ended up being extremely complicated for what I actually ended up needing.  It is still used internally to actually define the routes, but the JavaScript side of it is very simple. 
+
+
+`method`
+: A subset of the [[Allowed Methods]]. 
+
+`path`
+: A regex starting with `^/` which matches the request. The first route handler which matches is used. Routes may be nested, and the full match is removed from the URL before matching children. If a parent route matches, it will be called, even if it has no child matches. 
+
+`denyFinal`
+: If this route matches, but none of its children do, the server will return `404 NOT FOUND`. Otherwise, its state handler will be called and expected to handle the request, even if none of its children match. 
+
+`pathParams`
+: An array of key names for regex match groups for the pathParams object.
+
+`bodyFormat`
+: The [[Body Format]] which the request wishes to receive. If the method is only GET and HEAD, this is ignored, as no request body is expected. Internally, the request is probably drained early, just in case a body was sent. 
+
+`handler` - a separate callback argument
+: If the route matches, the handler is called. The handler is called at each level in order, so parents may add additional (out of type) properties to the state object or handle some requests and allow others to go through to the matched child.
+
+### Match result
+
+The StateObject has a routePath parameter containing the "path" through the "tree" of route definitions. In other words, it has the first matched route, and then the first matched child of that route, and then the first matched child of that route, and so on. 
+
+It is an array of objects with the following properties. 
+
+`route`
+: an object containing the options for the route listed above
+
+`params`
+: an array of the match groups (`match.slice(1)`)
+
+`remainingPath`
+: The remaining URL to match (if this is zero-length, it will be a `/`)
+
+## Zod Route Definers
+
+The rest of the route definers are used by creating a class with the route definitions as properties, and then calling that class on server startup to register the routes. 
+
+<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;">class</span> <span style="color: #4ec9b0;">RoutesClass</span> { <span style="color: #9cdcfe;">test</span> = <span style="color: #dcdcaa;">zodManage</span>(<span style="color: #9cdcfe;">z</span> <span style="color: #569cd6;">=&gt;</span> <span style="color: #9cdcfe;">z</span>.<span style="color: #dcdcaa;">any</span>(), <span style="color: #569cd6;">async</span> <span style="color: #9cdcfe;">e</span> <span style="color: #569cd6;">=&gt;</span> <span style="color: #569cd6;">null</span>) }</div><div><span style="color: #569cd6;">const</span> <span style="color: #4fc1ff;">RoutesKeyMap</span>: <span style="color: #4ec9b0;">RouterKeyMap</span>&lt;<span style="color: #4ec9b0;">RoutesClass</span>, <span style="color: #4ec9b0;">true</span>&gt; = { <span style="color: #9cdcfe;">test</span><span style="color: #9cdcfe;">:</span> <span style="color: #569cd6;">true</span> }</div><div><span style="color: #dcdcaa;">registerZodRoutes</span>(<span style="color: #4fc1ff;">root</span>, <span style="color: #569cd6;">new</span> <span style="color: #4ec9b0;">RoutesClass</span>(), <span style="color: #4ec9b0;">Object</span>.<span style="color: #dcdcaa;">keys</span>(<span style="color: #4fc1ff;">RoutesKeyMap</span>));</div></div>
+
+`RoutesKeyMap` would have the keys of all the routes in the class, and the type makes sure no routes have been missed, while also allowing the class to have extra properties that are not routes. 
+
+
+## `zodRoute`
+
+The `zodRoute` function creates type-safe route definitions with Zod validation. It takes a single configuration object with the following properties:
+
+`method: string[]`
+: An array of HTTP methods (e.g., `["GET", "POST"]`). Must be a subset of allowed methods.
+
+`path: string`
+: A slash-separated string path with optional parameters prefixed with `:` (e.g., `"/recipes/:recipe_name/tiddlers/:title"`).
+
+`bodyFormat: BodyFormat`
+: The expected body format: `"ignore"`, `"string"`, `"json"`, `"buffer"`, `"www-form-urlencoded"`, `"www-form-urlencoded-urlsearchparams"`, or `"stream"`. For GET and HEAD requests, this is always treated as `"ignore"`.
+
+`zodPathParams: (z: Z2<"STRING">) => Record<string, ZodType>`
+: A function that returns an object defining Zod validations for path parameters. The keys must match the parameter names in the path. If validation fails, returns 404.
+
+`zodQueryParams?: (z: Z2<"STRING">) => Record<string, ZodType>`
+: Optional function defining Zod validations for query parameters. Query params are arrays of strings by default.
+
+`zodRequestBody?: (z: Z2<BodyFormat>) => ZodType`
+: Optional function defining Zod validation for the request body. Only valid for `"string"`, `"json"`, and `"www-form-urlencoded"` body formats. If validation fails, returns 400.
+
+`securityChecks?: { requestedWithHeader?: boolean }`
+: Optional security checks. If `requestedWithHeader` is true, requires the `x-requested-with: fetch` header for non-GET/HEAD/OPTIONS requests.
+
+`corsRequest?: (state: ZodState<"OPTIONS", "ignore", P, Q, ZodUndefined>) => Promise<symbol>`
+: Optional CORS preflight handler for OPTIONS requests. Cannot authenticate but can provide endpoint information.
+
+`inner: (state: ZodState<Method, BodyFormat, PathParams, QueryParams, RequestBody>) => Promise<JsonValue>`
+: The main route handler that receives a fully validated and typed state object.
+
+### Example
+
+```typescript
+const getUser = zodRoute({
+  method: ["GET"],
+  path: "/users/:user_id",
+  bodyFormat: "ignore",
+  zodPathParams: z => ({
+    user_id: z.string().uuid()
+  }),
+  zodQueryParams: z => ({
+    include_roles: z.enum(["yes", "no"]).array().optional()
+  }),
+  inner: async (state) => {
+    const { user_id } = state.pathParams; // typed as { user_id: string }
+    const { include_roles } = state.queryParams; // typed as { include_roles?: ("yes"|"no")[] }
+    
+    return await getUserById(user_id, include_roles?.[0] === "yes");
+  }
+});
+```
+
+## `admin` Helper Function
+
+The `admin` function is a convenience wrapper around `zodRoute` specifically for admin API endpoints. It automatically sets up:
+
+- Method: `["POST"]`
+- Path: `"/admin/$key"` (where `$key` is replaced with the property name)
+- Body format: `"json"`
+- Security: Requires `x-requested-with: fetch` header
+- Database transactions: Automatically wraps the handler in a Prisma transaction
+- Authentication: Provides access to authenticated user state
+
+### Signature
+
+```typescript
+function admin<T extends ZodTypeAny, R extends JsonValue>(
+  zodRequest: (z: Z2<"JSON">) => T,
+  inner: (state: ZodState<"POST", "json", {}, {}, T>, prisma: PrismaTxnClient) => Promise<R>
+): ZodRoute<"POST", "json", {}, {}, T, R>
+```
+
+### Parameters
+
+`zodRequest: (z: Z2<"JSON">) => ZodType`
+: Function defining the expected shape of the JSON request body.
+
+`inner: (state, prisma) => Promise<JsonValue>`
+: Handler function that receives the validated state and a Prisma transaction client.
+
+### Example
+
+```typescript
+const user_create = admin(z => z.object({
+  username: z.string().min(3),
+  email: z.string().email(),
+  role_id: z.string().uuid()
+}), async (state, prisma) => {
+  // state.data is typed based on the zodRequest schema
+  const { username, email, role_id } = state.data;
+  
+  // Create user within the automatic transaction
+  const user = await prisma.users.create({
+    data: { username, email, role_id }
+  });
+  
+  return { user_id: user.user_id, username, email };
+});
+```
+
+## `registerZodRoutes` Function
+
+This function registers multiple Zod routes from a class instance to a parent route. It's the bridge between route definitions and the actual router.
+
+### Signature
+
+```typescript
+function registerZodRoutes(
+  parent: ServerRoute,
+  router: object,
+  keys: string[]
+): void
+```
+
+### Parameters
+
+`parent: ServerRoute`
+: The parent route to register child routes under.
+
+`router: object`
+: An instance of a class containing route definitions as properties.
+
+`keys: string[]`
+: Array of property names to register as routes. Usually `Object.keys(RouterKeyMap)`.
+
+### Usage Pattern
+
+```typescript
+export class UserManager {
+  static defineRoutes(root: ServerRoute) {
+    registerZodRoutes(root, new UserManager(), Object.keys(UserKeyMap));
+  }
+
+  user_create = admin(z => z.object({
+    username: z.string(),
+    email: z.string().email()
+  }), async (state, prisma) => {
+    // Implementation
+  });
+
+  user_list = admin(z => z.undefined(), async (state, prisma) => {
+    // Implementation  
+  });
+}
+
+export const UserKeyMap: RouterKeyMap<UserManager, true> = {
+  user_create: true,
+  user_list: true,
+};
+
+// Register during server startup
+serverEvents.on("mws.routes", (root) => {
+  UserManager.defineRoutes(root);
+});
+``` 
+

package/editions/mws-docs/tiddlers/Route Definers.md.meta

@@ -0,0 +1,5 @@
+created: 20250513220517586
+modified: 20250513231340117
+tags: Reference
+title: Route Definers
+type: text/markdown

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

@@ -0,0 +1,75 @@
+## Use Cases
+
+The primary use cases for MWS are 
+
+- Internal corporate information tools
+- Public TiddlyWiki hosting
+- Classroom scenarios
+- Unrestricted trusted collaboration
+
+## Still in Development
+
+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. 
+
+## Protection strategies
+
+I just needed some place to list all the different things we could do to secure a site. Some of these would be optional depending on the level of mitigation required. 
+
+1. Obvious, "tie your shoes" security precautions.
+2. Reasonable prevention of normal attack vectors.
+3. Optional hardening to prevent targeted attacks.
+4. Pedantic defenses against advanced attackers with full read-only access to the system or a backup.
+
+### HTTPS
+
+- Enable HTTPS site-wide using let's encrypt or another free certificate service.
+
+### Cookies
+
+[MDN - SetCookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie)
+
+- Secure, HttpOnly, SameSite=strict, attributes
+- Setting separate session cookies for the admin and wiki paths doesn't work because it's based on the request path, not the page path.
+- Having a separate login subdomain and using oauth is a more complicated option.
+
+### `no-cors`
+
+- JavaScript `no-cors` mode allows `GET`, `HEAD`, and `POST` and sends relevant cookies. 
+- **`no-cors` prevents most headers, including custom headers, from being set.**
+- Our standard `x-requested-with` header cannot be set.
+
+### CORS headers
+
+- Set CORS header to only allow expected origins. This doesn't prevent external CLI tools from accessing the site, only browser-based tools. This could also be set for certain endpoints or recipes to only allow specific bags to receive external requests. 
+
+### `Referer` header
+
+- Only allow a wiki to access its own recipe endpoints for extra tight security. It is difficult to predict when a specific request might be malicious if tools are allowed to make requests from one recipe to another on a user's behalf. Specific referer headers could be white-listed as approved tool wikis. 
+- Don't allow wiki pages to access admin APIs.
+
+### `Content-Security-Policy` header
+
+- Able to block the page from making network requests, putting it in mostly read-only mode. This doesn't stop JavaScript from setting `location.href` nor prevent the user from clicking on `a href` links. This is more of a quick and dirty read-only, since it prevents ALL requests, including requests that might not actually change anything on the server. 
+
+### Other site configuration
+
+- Don't allow admins to edit a wiki unless they are added to the ACL. The CSP header could be used to disable all network requests if the admin role does not have read permission, thus giving them true read-only access to the wiki. 
+- If compression is used, do not compress two bags in the same compression stream. This is a fairly extreme precaution with a limited likelihood. 
+
+## Other ideas
+
+When you visit a page, you visit with page permissions only, and the page has to ask permission to use your full account permissions. The request could also be granular, where the page has to request the specific bag or wiki it wants access to. 
+
+

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

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

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

@@ -0,0 +1,7 @@
+Server Plugins are a concept which has yet to be built but essentially involves subscribing to events and then taking (or not taking) a series of defined actions in response to the event. 
+
+For instance, on server startup, all plugins are asked to register any client plugins they may have. They would probably do this by adding that data to the tiddler cache, or returning the corresponding key-value pairs.
+
+Server plugins should not expect the TiddlyWiki node instance to be available or pluggable. The TiddlyWiki instance is used to render plugins which are the equivalent of those available for single-file wikis. It is also used by the `load-wiki-folder` command, which uses the equivalent of `boot.js` code only. 
+
+The [[MWS routing system|Routing]] is directly borrowed from TiddlyWiki. Plugins may declare arbitrary routes (preferably namespaced) and the definitions try to be reasonably typed and have helpful utilities for handling incoming data. 

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

@@ -0,0 +1,5 @@
+created: 20250513200927797
+modified: 20250513220607698
+tags: Architecture
+title: Server Plugins
+type: text/markdown

package/editions/mws-docs/tiddlers/Startup Cache.md

@@ -0,0 +1,28 @@
+The startup cache records all the information about the TiddlyWiki plugin cache. 
+
+`pluginFiles`
+: list of **key:** plugin title, **value:** cache-relative path to the plugin folder
+
+`pluginHashes`
+: list of **key:** plugin title, **value:** sha384 hash (prefixed with `sha384-`)
+
+`filePlugins`
+: `pluginFiles` with the key and value reversed. It should only be used for importing existing data folders which have path references to TiddlyWiki plugins (such as found in `tiddlywiki.info` files).
+
+`requiredPlugins`
+: the list of plugins that the site considers essential. Every wiki is always loaded with these plugins. Server Plugins can add or remove plugins from this list. It does not include the TiddlyWiki core, as that one is even more essential and can only be disabled with a setting on the recipe.
+
+`cachePath`
+: absolute path to the cache directory
+
+## SHA-384 Hash options
+
+`prefix`
+: a Buffer to add to the hash before the plugin itself
+
+`suffix`
+: a Buffer to add to the hash after the plugin itself.
+
+The hash is used for the integrity attribute when serving plugins externally. The exact file byte contents, along with `prefix` and `suffix`,  must be hashed in the correct encoding. Presumably this is always UTF-8. When a plugin is served as an external JS file, it is wrapped with `prefix` and `suffix`.
+
+The plugin itself is a [[tiddler fields object|TiddlerFields]] encoded with `JSON.stringify(tiddler.getFieldStrings())`.

package/editions/mws-docs/tiddlers/Startup Cache.md.meta

@@ -0,0 +1,5 @@
+created: 20250513205526516
+modified: 20250513214414666
+tags: Reference
+title: Startup Cache
+type: text/markdown

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

@@ -0,0 +1,5 @@
+A tiddler fields object is the serializable tiddler exchange format. If in doubt, stringify. Tiddler field values are supposed to be strings but they aren't always. Tiddler field keys could contain the colon, which would break `.tid` files. 
+
+The definitive serializable form of a tiddler in TW5 is obtained by retrieving the tiddler from the wiki, and then calling `tiddler.getFieldString` on each field value. This is the form in which TiddlyWiki saves and loads single file wikis.
+
+`.tid` files are not equivalent because they do not escape the colon character in field names. The official "workaround" is simply to save the tiddler as a JSON file. 

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

@@ -0,0 +1,4 @@
+created: 20250513211721653
+modified: 20250513233302501
+title: TiddlerFields
+type: text/markdown

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

@@ -1,5 +1,5 @@
 created: 20241105133737778
-modified: 20250428144341860
+modified: 20250612223124466
 tags: TableOfContents
 title: Usage
 type: text/vnd.tiddlywiki
@@ -11,4 +11,4 @@ On first start, a default user is created with username `admin` and password `12
 If you intend to make an MWS installation available on the Internet, the server should first be secured with the following steps:
 
 * Change the administrator password
-* Install HTTPS server certificates.
+* Install HTTPS server certificates from an online certificate service like [[Let's Encrypt|https://letsencrypt.org/]].

package/editions/mws-docs/tiddlers/system/$__mws_cssvar-macro.tid

@@ -0,0 +1,10 @@
+created: 20250514011406200
+modified: 20250514012224041
+tags: $:/tags/Macro
+title: $:/mws/cssvar-macro
+type: text/vnd.tiddlywiki
+
+\define cssvar(name)
+\whitespace trim
+`var(--$name$)`
+\end

package/editions/mws-docs/tiddlers/system/$__palettes_MUI

@@ -0,0 +1,143 @@
+alert-background: <<cssvar alert-background>>
+alert-border: <<cssvar alert-border>>
+alert-highlight: <<cssvar alert-highlight>>
+alert-muted-foreground: <<cssvar alert-muted-foreground>>
+background: <<cssvar background>>
+page-background: <<cssvar page-background>>
+foreground: <<cssvar foreground>>
+muted-foreground: <<cssvar muted-foreground>>
+very-muted-foreground: <<cssvar very-muted-foreground>>
+primary: <<cssvar primary>>
+blockquote-bar: <<cssvar blockquote-bar>>
+button-background: <<cssvar button-background>>
+button-foreground: <<cssvar button-foreground>>
+button-border: <<cssvar button-border>>
+code-background: <<cssvar code-background>>
+code-border: <<cssvar code-border>>
+code-foreground: <<cssvar code-foreground>>
+diff-delete-background: <<cssvar diff-delete-background>>
+diff-delete-foreground: <<cssvar diff-delete-foreground>>
+diff-equal-background: <<cssvar diff-equal-background>>
+diff-equal-foreground: <<cssvar diff-equal-foreground>>
+diff-insert-background: <<cssvar diff-insert-background>>
+diff-insert-foreground: <<cssvar diff-insert-foreground>>
+diff-invisible-background: <<cssvar diff-invisible-background>>
+diff-invisible-foreground: <<cssvar diff-invisible-foreground>>
+dragger-background: <<cssvar dragger-background>>
+dragger-foreground: <<cssvar dragger-foreground>>
+dirty-indicator: <<cssvar dirty-indicator>>
+download-background: <<cssvar download-background>>
+download-foreground: <<cssvar download-foreground>>
+dropdown-background: <<cssvar dropdown-background>>
+dropdown-border: <<cssvar dropdown-border>>
+dropdown-tab-background-selected: <<cssvar dropdown-tab-background-selected>>
+dropdown-tab-background: <<cssvar dropdown-tab-background>>
+dropzone-background: <<cssvar dropzone-background>>
+external-link-background: <<cssvar external-link-background>>
+external-link-foreground: <<cssvar external-link-foreground>>
+external-link-background-hover: <<cssvar external-link-background-hover>>
+external-link-foreground-hover: <<cssvar external-link-foreground-hover>>
+external-link-background-visited: <<cssvar external-link-background-visited>>
+external-link-foreground-visited: <<cssvar external-link-foreground-visited>>
+footnote-target-background: <<cssvar footnote-target-background>>
+highlight-background: <<cssvar highlight-background>>
+highlight-foreground: <<cssvar highlight-foreground>>
+message-background: <<cssvar message-background>>
+message-border: <<cssvar message-border>>
+message-foreground: <<cssvar message-foreground>>
+modal-backdrop: <<cssvar modal-backdrop>>
+modal-background: <<cssvar modal-background>>
+modal-border: <<cssvar modal-border>>
+modal-footer-background: <<cssvar modal-footer-background>>
+modal-footer-border: <<cssvar modal-footer-border>>
+modal-header-border: <<cssvar modal-header-border>>
+network-activity-foreground: <<cssvar network-activity-foreground>>
+notification-background: <<cssvar notification-background>>
+notification-border: <<cssvar notification-border>>
+pre-background: <<cssvar pre-background>>
+pre-border: <<cssvar pre-border>>
+selection-background: <<cssvar selection-background>>
+selection-foreground: <<cssvar selection-foreground>>
+select-tag-background: <<cssvar select-tag-background>>
+select-tag-foreground: <<cssvar select-tag-foreground>>
+sidebar-button-foreground: <<cssvar sidebar-button-foreground>>
+sidebar-controls-foreground-hover: <<cssvar sidebar-controls-foreground-hover>>
+sidebar-controls-foreground: <<cssvar sidebar-controls-foreground>>
+sidebar-foreground-shadow: <<cssvar sidebar-foreground-shadow>>
+sidebar-foreground: <<cssvar sidebar-foreground>>
+sidebar-muted-foreground-hover: <<cssvar sidebar-muted-foreground-hover>>
+sidebar-muted-foreground: <<cssvar sidebar-muted-foreground>>
+sidebar-tab-background-selected: <<cssvar sidebar-tab-background-selected>>
+sidebar-tab-background: <<cssvar sidebar-tab-background>>
+sidebar-tab-border-selected: <<cssvar sidebar-tab-border-selected>>
+sidebar-tab-border: <<cssvar sidebar-tab-border>>
+sidebar-tab-divider: <<cssvar sidebar-tab-divider>>
+sidebar-tab-foreground-selected: <<cssvar sidebar-tab-foreground-selected>>
+sidebar-tab-foreground: <<cssvar sidebar-tab-foreground>>
+sidebar-tiddler-link-foreground-hover: <<cssvar sidebar-tiddler-link-foreground-hover>>
+sidebar-tiddler-link-foreground: <<cssvar sidebar-tiddler-link-foreground>>
+site-title-foreground: <<cssvar site-title-foreground>>
+stability-stable: <<cssvar stability-stable>>
+stability-experimental: <<cssvar stability-experimental>>
+stability-deprecated: <<cssvar stability-deprecated>>
+stability-legacy: <<cssvar stability-legacy>>
+static-alert-foreground: <<cssvar static-alert-foreground>>
+tab-background-selected: <<cssvar tab-background-selected>>
+tab-background: <<cssvar tab-background>>
+tab-border-selected: <<cssvar tab-border-selected>>
+tab-border: <<cssvar tab-border>>
+tab-divider: <<cssvar tab-divider>>
+tab-foreground-selected: <<cssvar tab-foreground-selected>>
+tab-foreground: <<cssvar tab-foreground>>
+table-border: <<cssvar table-border>>
+table-footer-background: <<cssvar table-footer-background>>
+table-header-background: <<cssvar table-header-background>>
+tag-background: <<cssvar tag-background>>
+tag-foreground: <<cssvar tag-foreground>>
+testcase-accent-level-1: <<cssvar testcase-accent-level-1>>
+testcase-accent-level-2: <<cssvar testcase-accent-level-2>>
+testcase-accent-level-3: <<cssvar testcase-accent-level-3>>
+tiddler-background: <<cssvar tiddler-background>>
+tiddler-border: <<cssvar tiddler-border>>
+tiddler-controls-foreground-hover: <<cssvar tiddler-controls-foreground-hover>>
+tiddler-controls-foreground-selected: <<cssvar tiddler-controls-foreground-selected>>
+tiddler-controls-foreground: <<cssvar tiddler-controls-foreground>>
+tiddler-editor-background: <<cssvar tiddler-editor-background>>
+tiddler-editor-border-image: <<cssvar tiddler-editor-border-image>>
+tiddler-editor-border: <<cssvar tiddler-editor-border>>
+tiddler-editor-fields-even: <<cssvar tiddler-editor-fields-even>>
+tiddler-editor-fields-odd: <<cssvar tiddler-editor-fields-odd>>
+tiddler-info-background: <<cssvar tiddler-info-background>>
+tiddler-info-border: <<cssvar tiddler-info-border>>
+tiddler-info-tab-background: <<cssvar tiddler-info-tab-background>>
+tiddler-link-background: <<cssvar tiddler-link-background>>
+tiddler-link-foreground: <<cssvar tiddler-link-foreground>>
+tiddler-subtitle-foreground: <<cssvar tiddler-subtitle-foreground>>
+tiddler-title-foreground: <<cssvar tiddler-title-foreground>>
+toolbar-new-button: <<cssvar toolbar-new-button>>
+toolbar-options-button: <<cssvar toolbar-options-button>>
+toolbar-save-button: <<cssvar toolbar-save-button>>
+toolbar-info-button: <<cssvar toolbar-info-button>>
+toolbar-edit-button: <<cssvar toolbar-edit-button>>
+toolbar-close-button: <<cssvar toolbar-close-button>>
+toolbar-delete-button: <<cssvar toolbar-delete-button>>
+toolbar-cancel-button: <<cssvar toolbar-cancel-button>>
+toolbar-done-button: <<cssvar toolbar-done-button>>
+untagged-background: <<cssvar untagged-background>>
+wikilist-background: <<cssvar wikilist-background>>
+wikilist-item: <<cssvar wikilist-item>>
+wikilist-info: <<cssvar wikilist-info>>
+wikilist-title: <<cssvar wikilist-title>>
+wikilist-title-svg: <<cssvar wikilist-title-svg>>
+wikilist-url: <<cssvar wikilist-url>>
+wikilist-button-open: <<cssvar wikilist-button-open>>
+wikilist-button-open-hover: <<cssvar wikilist-button-open-hover>>
+wikilist-button-reveal: <<cssvar wikilist-button-reveal>>
+wikilist-button-reveal-hover: <<cssvar wikilist-button-reveal-hover>>
+wikilist-button-remove: <<cssvar wikilist-button-remove>>
+wikilist-button-remove-hover: <<cssvar wikilist-button-remove-hover>>
+wikilist-toolbar-background: <<cssvar wikilist-toolbar-background>>
+wikilist-toolbar-foreground: <<cssvar wikilist-toolbar-foreground>>
+wikilist-droplink-dragover: <<cssvar wikilist-droplink-dragover>>
+wikilist-button-background: <<cssvar wikilist-button-background>>
+wikilist-button-foreground: <<cssvar wikilist-button-foreground>>

package/editions/mws-docs/tiddlers/system/$__palettes_MUI.meta

@@ -0,0 +1,7 @@
+created: 20250513234253113
+modified: 20250514011241673
+name: Material UI
+description: Responsive colors adapted from Material UI.
+tags: $:/tags/Palette
+title: $:/palettes/MUI
+type: application/x-tiddler-dictionary