@tiddlywiki/mws 0.0.16 → 0.0.18

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

@@ -1,5 +1,3 @@
-created: 20250428174600355
-list: [[Access Control]] [[Moduler Design]] [[MWS and SQLite]] [[Request Server]] Architecture HelloThere Installation Usage Reference
-modified: 20250428174603436
+list: HelloThere Installation Usage Reference
 title: $:/StoryList
 type: text/vnd.tiddlywiki

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

@@ -0,0 +1,56 @@
+Described here is a full blown role-based identity & access management system. However we are unlikely to need this level of sophistication immediately. 
+
+## Logical groupings and definitions
+
+- A user is a logical grouping of logins.
+- An organization ("content space") is a logical grouping of users and the content they interact with.
+- The organization owner is a user who sets the privileges other users have in the organization.
+  - If enabled, every user is the owner of their own personal organization. 
+  - If enabled, they may own extra organizations. 
+  - The organization owner has all privileges in the organization except those they explicitly deny themself. 
+  - They cannot deny themself the ability to change privileges in the organization. 
+  - They may delegate to managers. 
+- Admins are users with site-wide privileges. 
+  - The admin role is separate from the owner role. They are not site-wide owners.
+  - Admins can take various actions on extra orginizations, depending on site settings.
+  - Admins can manage users access to the site and take related actions.
+  - Depending on settings, admins cannot view content that does not belong to them, unless shared (the exact privacy details here aren't important, it's the technical features that I'm including this for).
+- Site admins can define a public content space which everyone can view, and an additional content space which authenticated users can view. These act as implicit organizations with admins given permissions as managers.
+
+Even though it sounds like I'm expecting this to be some kind of public document sharing platform or online collaboration, the setup actually has multiple use-cases within a single organization that are just as complicated.
+
+### To recap the various roles in an organization
+
+- **admin** - Granted site-wide permissions.
+- **owner** - Granted organization level permissions. 
+- **manager** - Delegated permission from owners.
+- **user** - Explicitly invited and added to the organization user list by owners or managers.
+- **auth** - Visitor signed in and not in the user list.
+- **anon** - Visitor not signed into the site.
+
+### There are two permission levels within the wiki
+
+- **writer** - can edit tiddlers, optionally filtered
+- **reader** - can view tiddlers, optionally filtered
+
+Owners can create permission profiles which define reader and writer filters, then assign them to users or groups (or to their access to a specific wiki), and when they update the permission profile the changes apply everywhere. 
+
+I mean look, at some point I'm just implementing an entire Identity Access Management service. 
+
+## JSON settings file
+
+A short list of options in a JSON file alongside the database (or with the database settings) which determines some permanent settings that depend on the use case.
+
+- Whether admins can change user email address or oauth identity and set user passwords (account takeover).
+- Whether admins can view site content unrestricted (account privacy).
+- Sets the max visibility owners and admins can set (since that shouldn't need to change).
+- The default default visibility (before orgs change it).
+
+### settings for content spaces (organizations)
+
+- Whether new users get their own personal content space (personal organization).
+- Whether non-admin users can be given additional content spaces (extra organizations).
+- Whether non-admin users can create their own additional content spaces (extra organizations).
+- Whether additional content spaces created by non-admin users can be removed from them by admins (this will depend on the use case).
+
+

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

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

package/editions/mws-docs/tiddlers/2025-04-03 - Phases of Development.md

@@ -0,0 +1,64 @@
+Welcome to the MultiWikiServer wiki!
+
+## Phases of development
+
+### Phase 1 is to get a fully working system that can be extended.
+
+The features here should cover all of the core requirements.
+
+- Database fully async and concurrent with transactions and row locking.
+- Recipes and bags fully supported.
+  - Support for both server-wide (wiki-like) and per-user (doc-like) recipes.
+  - Shadow bags to hold each user's drafts and customizations for server-wide or shared recipes.
+  - Possible integration of various tiddler namespace behaviors, like private `User:{username}` tiddlers.
+  - Option *on the server* for users to propose edits to existing tiddlers, probably by moving a tiddler to a different bag. 
+- The concept of multiple users fully supported. Auth state has a userID property.
+- Auth with username and password by default, but allowing custom integrations to be built that use third-party auth libraries or services. Several of us already have different ideas in mind, and we need to build all the required mechanisms in phase 1 in order to make sure we're properly supporting them, even if we don't actually support the third-party integrations themselves until phase 2. 
+- Multiple sessions editing the same wiki supported *by the server*, with revision mechanisms to prevent overwriting edits with an old version. 
+- Sharing read or write access with other users via invite links. 
+
+### Phase 2 is to add all the other important features
+
+- [Full integration with popular auth solutions.](https://github.com/TiddlyWiki/MultiWikiServer/issues/1)
+- [Full Identity & Access Management support.](https://github.com/TiddlyWiki/MultiWikiServer/wiki/User-Management-3)
+- Collaborative editing sessions.
+
+## How the server classes work together
+
+This implements a server that abstracts the various HTTP protocols into a single request state object which it then hands out to the routes.
+
+- **Streamer** abstracts away the difference between HTTP/1.1 and HTTP/2 to allow both to be handled transparently. 
+  - Normalizes the request and response into a single class. 
+  - Currently it doesn't support push streams, but we could change that.
+- **Listeners** handle the server listener and send requests they recieve to the router.
+  - ListenerHTTP: Sets up and handles HTTP requests using the http module.
+  - ListenerHTTPS: Sets up and handles HTTPS requests using the http2 module (with http1.1 support).
+- **Router**: The main server instance. Handles route matching and sets up a state object for each request. It also instantiates subsystems.
+  - **AuthState** (subsystem): Contains all authentication logic and is called at various points in the request process. It may throw to abort the request.
+- **StateObject**: Contains everything routes have access to, including a database connection. Subsystems may create their own state classes which take the StateObject as a constructor argument.  
+
+## Thoughts on routing
+
+Routing generally works well, but the current routes are all strictly path based. They mix various concerns into one module based on path similarities. 
+
+I think it would be a lot more streamlined to separate the concerns into different sections. Each of those would operate as their own submodule. 
+
+Why? Because this is how complicated permissions can get:
+
+- **Auth** determines who the user is.
+  - Auth adapters that connect third-party auth services, with fields like profile pic, display name, email, etc.
+  - Auth strategies like session cookies or access tokens.
+  - Login and registration forms, email and phone interactions, etc.
+- **Users** contains all the code for changing what the user is allowed to do.
+  - List of users, with tabs for pending, roles, etc.
+  - Handle user registrations and initial setup.
+  - Manage sharing and collaboration permissions: [Roles](https://github.com/Arlen22/TW5-MWS/wiki/Roles) (eventually)
+- **Recipes** shows the user their available recipes and lets them create or modify.
+  - (Phase 1): Users create their own recipes and bags and specify read/write permissions for those recipes and bags.
+  - (Phase 2): Admins can define scoped bags which are added to recipes based on the user's role.
+- **Wikis** contains all the code that runs when accessing the wiki itself.
+  - Tiddler saving and loading based on the recipe instructions.
+  - Uploads and other third-party integrations requiring server support.
+
+
+

package/editions/mws-docs/tiddlers/2025-04-03 - Phases of Development.md.meta

@@ -0,0 +1,5 @@
+created: 20250507122347077
+modified: 20250507123211745
+tags: Notes
+title: 2025-04-03 - Phases of Development
+type: text/markdown

package/editions/mws-docs/tiddlers/2025-04-13 - Plugins.md

@@ -0,0 +1,18 @@
+
+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. 
+
+-- Arlen22

package/editions/mws-docs/tiddlers/2025-04-13 - Plugins.md.meta

@@ -0,0 +1,5 @@
+created: 20250507122423829
+modified: 20250507123538275
+tags: Notes
+title: 2025-04-13 - Plugins
+type: text/markdown

package/editions/mws-docs/tiddlers/2025-05-04.md

@@ -0,0 +1,13 @@
+We need a way to add hooks at most significant points of the process. Maybe all code should just be hooks. Plugins need to be able to hook in and change what they need. I'm still trying to figure out how to put all the pieces together. 
+
+I want routes to call the register function, rather than being called by setup code. But then I have to figure out where to put the register functions. 
+
+Plugins need to hook into a whole bunch of points in the setup process, but they aren't bootstrapped until after the database is connected. 
+
+I think the biggest problem is that I was originally planning to architect it with everything in the config file (similar to how a build system or server works), but it seems everyone wants to use the UI and store config in the database as much as possible, so I'll probably end up with something a lot more like WordPress. Once I rearrange everything more logically using imports, it should be fairly obvious how to use plugins. 
+
+I probably need a startup state object, which basically has the site config and `rootRoute`. I also need to setup the CLI listen command [as outlined here](https://talk.tiddlywiki.org/t/mws-how-simple-can-we-make-the-cli-for-mws/12460). 
+
+I guess this is actually a significant rewrite, so once I get some of the initial pieces done, it should be more obvious. 
+
+-- Arlen22

package/editions/mws-docs/tiddlers/2025-05-04.md.meta

@@ -0,0 +1,5 @@
+created: 20250507122508552
+modified: 20250507123527942
+tags: Notes
+title: 2025-05-04
+type: text/markdown

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

@@ -0,0 +1,19 @@
+There have been several different posts complaining about the long wait times when importing huge volumes of tiddlers. I took a look at the syncer and syncadaptor this evening, and realized that most of this is caused by the designed of the syncer itself, not the syncadaptor. The syncer only saves tiddlers one at a time. There's no batching. I'm not even sure if there is an option for batching. 
+
+It's probably going to be a good idea to redesign the syncer from the ground up. The syncer hooks directly into the change events on the wiki. From there it calculates which tiddlers need to be synced. I think it would be good to get as close to the wiki as possible, so hooking directly into the change events is probably a good idea. 
+
+For the purposes of MWS, the syncer is actually pretty basic, and most of the features are probably not used, however, the syncer presents a standard API surface between the UI internals and the sync adapter. If I can modify it to handle more bulk updates, that would help.
+
+I think the syncer also needs to be updated to be more aware of the recipe. Being able to understand the recipe is kind of important in understanding how to deal with deletions efficiently. It needs to be aware of read-only tiddlers. 
+
+Speaking of recipes, I keep bouncing this idea around in my mind of recipes which are multi-layered. Each level of the recipe could be opened by admins in order to easily make changes to the bag without creating a separate recipe. You can't just edit an individual bag because you need the bags below it in order to make sense out of it. 
+
+There also isn't a good way to move tiddlers between levels. Admins will need to be given some extra tools to do this with. 
+
+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.md.meta

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

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

@@ -0,0 +1,15 @@
+## ACL
+ 
+- Verify that anonymous users only have the access defined by allowAnon.
+  - No access to owned bags.
+  - No access to bags with ACL defined.
+- Verify that logged in users only have the access expected
+  - No access to bags owned by other users.
+  - Unless they are in the ACL for the bag.
+  - No more access than what is granted by the ACL.
+- 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

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

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

@@ -0,0 +1,15 @@
+### 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

package/editions/mws-docs/tiddlers/MWS Architecture.md.meta

@@ -0,0 +1,5 @@
+created: 20250507123414588
+modified: 20250507123420776
+tags: TableOfContents
+title: Architecture
+type: text/markdown

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

@@ -0,0 +1,5 @@
+created: 20250507122827955
+modified: 20250507122829535
+tags: TableOfContents
+title: Notes
+type: text/vnd.tiddlywiki

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

@@ -0,0 +1,173 @@
+/* generated by ChatGPT o3 */
+alert-background:   #ffb74d  /* warning.light   */
+alert-border:       #ff9800  /* warning.main    */
+alert-highlight:    #c66900  /* warning.dark    */
+alert-muted-foreground: rgba(255,255,255,0.70)
+
+background:        #121212  /* background.default / paper */
+page-background:   #121212
+
+foreground:        rgba(255,255,255,0.87)  /* text.primary   */
+muted-foreground:  rgba(255,255,255,0.70)  /* text.secondary */
+very-muted-foreground: rgba(255,255,255,0.50)
+
+primary:           #90caf9  /* primary.main     */
+
+blockquote-bar:    <<colour muted-foreground>>
+button-background: #90caf9
+button-foreground: #000000
+button-border:     #42a5f5
+
+code-background:   #1e1e1e
+code-border:       #424242
+code-foreground:   #ff8a80  /* error.light      */
+
+diff-delete-background: #b71c1c
+diff-delete-foreground: #ffffff
+diff-equal-background:  #424242
+diff-insert-background: #2e7d32
+diff-insert-foreground: #ffffff
+diff-invisible-foreground: <<colour very-muted-foreground>>
+
+dirty-indicator:   #ff1744
+download-background: #66bb6a
+download-foreground: #000000
+
+dropdown-background: <<colour background>>
+dropdown-border:    rgba(255,255,255,0.12)
+dropdown-tab-background-selected: #1e1e1e
+dropdown-tab-background: #333333
+dropzone-background: rgba(76,175,80,0.70)
+
+external-link-foreground:       #90caf9
+external-link-foreground-visited: #ce93d8
+
+footnote-target-background: #1565c0
+
+highlight-background: #ffff00
+highlight-foreground: #000000
+
+message-background: #0277bd
+message-border:     #0288d1
+message-foreground: #ffffff
+
+modal-backdrop: rgba(0,0,0,0.5)
+modal-background: #1e1e1e
+modal-border: #666666
+modal-footer-background: #242424
+modal-footer-border: #333333
+modal-header-border: #333333
+
+network-activity-foreground: #66bb6a
+
+notification-background: #424242
+notification-border: rgba(255,255,255,0.12)
+
+pre-background:  #2d2d2d
+pre-border:      #424242
+
+selection-background: #004ba0
+selection-foreground: #ffffff
+
+select-tag-background: #90caf9
+select-tag-foreground: #000000
+
+sidebar-button-foreground: <<colour foreground>>
+sidebar-controls-foreground-hover: #ffffff
+sidebar-controls-foreground: #aaaaaa
+sidebar-foreground-shadow: rgba(0,0,0,0.80)
+sidebar-foreground: #8c8c8c
+sidebar-muted-foreground-hover: #dddddd
+sidebar-muted-foreground: #9e9e9e
+sidebar-tab-background-selected: #1e1e1e
+sidebar-tab-background: #333333
+sidebar-tab-border-selected: #90caf9
+sidebar-tab-border: rgba(255,255,255,0.12)
+sidebar-tab-divider: rgba(255,255,255,0.12)
+sidebar-tab-foreground-selected: <<colour foreground>>
+sidebar-tab-foreground: <<colour tab-foreground>>
+sidebar-tiddler-link-foreground-hover: #90caf9
+sidebar-tiddler-link-foreground: #bbbbbb
+
+site-title-foreground: #bbdefb
+
+stability-stable:        #66bb6a
+stability-experimental:  #ffb74d
+stability-deprecated:    #ff5252
+stability-legacy:        #82b1ff
+
+static-alert-foreground: #bbbbbb
+
+tab-background-selected: #1e1e1e
+tab-background: #333333
+tab-border-selected: #333333
+tab-border: rgba(255,255,255,0.12)
+tab-divider: rgba(255,255,255,0.12)
+tab-foreground-selected: <<colour foreground>>
+tab-foreground: #bbbbbb
+
+table-border: #424242
+table-footer-background: #2d2d2d
+table-header-background: #1e1e1e
+
+tag-background: #ff9800
+tag-foreground: #000000
+
+testcase-accent-level-1: #003c8f
+testcase-accent-level-2: #8d6e63
+testcase-accent-level-3: #2e7d32
+
+tiddler-background: <<colour background>>
+tiddler-border:     #333
+
+tiddler-controls-foreground-hover: #bbbbbb
+tiddler-controls-foreground-selected: #ffffff
+tiddler-controls-foreground: #888888
+
+tiddler-editor-background: #1e1e1e
+tiddler-editor-border-image: <<colour background>>
+tiddler-editor-border: #424242
+tiddler-editor-fields-even: #1b5e20
+tiddler-editor-fields-odd:  #263238
+
+tiddler-info-background: #1e1e1e
+tiddler-info-border: #424242
+tiddler-info-tab-background: #1e1e1e
+
+tiddler-link-background: <<colour background>>
+tiddler-link-foreground: <<colour primary>>
+tiddler-subtitle-foreground: rgba(255,255,255,0.50)
+tiddler-title-foreground: #bbdefb
+
+toolbar-new-button:   #90caf9
+toolbar-options-button: #90caf9
+toolbar-save-button:  #66bb6a
+toolbar-info-button:  #64b5f6
+toolbar-edit-button:  #ffb74d
+toolbar-close-button: #ff1744
+toolbar-delete-button: #ff1744
+toolbar-cancel-button: #757575
+toolbar-done-button:   #66bb6a
+
+untagged-background: #757575
+
+wikilist-background: #2d2d2d
+wikilist-item:       #1e1e1e
+wikilist-info:       <<colour foreground>>
+wikilist-title:      #bbbbbb
+wikilist-title-svg:  <<colour wikilist-title>>
+wikilist-url:        #9e9e9e
+
+wikilist-button-open:          #66bb6a
+wikilist-button-open-hover:    #388e3c
+wikilist-button-reveal:        #90caf9
+wikilist-button-reveal-hover:  #1565c0
+wikilist-button-remove:        #ff5252
+wikilist-button-remove-hover:  #d32f2f
+
+wikilist-toolbar-background: #424242
+wikilist-toolbar-foreground: #bbbbbb
+wikilist-droplink-dragover: rgba(255,192,192,0.5)
+
+wikilist-button-background: #8c8c8c
+wikilist-button-foreground: #000000

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

@@ -0,0 +1,6 @@
+created: 20250507121016927
+modified: 20250507121857749
+name: MUI Dark
+tags: $:/tags/Palette
+title: $:/palettes/MUI-Dark
+type: application/x-tiddler-dictionary

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

@@ -0,0 +1,172 @@
+/* generated by ChatGPT o3 */
+alert-background: #fff8e1   /* warning.light (amber 100)  */
+alert-border:      #ff9800  /* warning.main               */
+alert-highlight:   #c66900  /* warning.dark               */
+alert-muted-foreground: rgba(0,0,0,0.60)
+
+background:        #ffffff  /* background.paper           */
+page-background:   #fafafa  /* background.default         */
+
+foreground:        rgba(0,0,0,0.87)  /* text.primary  */
+muted-foreground:  rgba(0,0,0,0.60)  /* text.secondary*/
+very-muted-foreground: rgba(0,0,0,0.38) /* text.disabled*/
+
+primary:           #1976d2  /* primary.main               */
+
+blockquote-bar:    <<colour muted-foreground>>
+button-background: #1976d2
+button-foreground: #ffffff
+button-border:     #1565c0  /* primary.dark               */
+
+code-background:   #f5f5f5
+code-border:       #e0e0e0
+code-foreground:   #d32f2f  /* error.main                 */
+
+diff-delete-background: #ffcdd2  /* error.light   */
+diff-delete-foreground: <<colour foreground>>
+diff-equal-background:  #e0e0e0
+diff-insert-background: #c8e6c9  /* success.light */
+diff-invisible-foreground: <<colour muted-foreground>>
+
+dirty-indicator:   #d32f2f
+download-background: #4caf50  /* success.main  */
+download-foreground: <<colour background>>
+
+dropdown-background: <<colour background>>
+dropdown-border:    #e0e0e0   /* divider       */
+dropdown-tab-background-selected: #ffffff
+dropdown-tab-background: #eeeeee
+dropzone-background: rgba(76,175,80,0.70)
+
+external-link-foreground:       #1976d2
+external-link-foreground-visited: #551a8b
+
+footnote-target-background: #bbdefb  /* info.light  */
+
+highlight-background: #ffff00
+highlight-foreground: #000000
+
+message-background: #e3f2fd   /* info.light  */
+message-border:     #90caf9   /* info.main   */
+message-foreground: #0277bd   /* info.dark   */
+
+modal-backdrop: rgba(0,0,0,0.5)
+modal-background: <<colour background>>
+modal-border: #9e9e9e
+modal-footer-background: #f5f5f5
+modal-footer-border: #e0e0e0
+modal-header-border: #e0e0e0
+
+network-activity-foreground: #2e7d32 /* success.dark */
+
+notification-background: #fffde7  /* warning.50  */
+notification-border: #e0e0e0
+
+pre-background:  #f5f5f5
+pre-border:      #cccccc
+
+selection-background: #bbdefb /* primary.100 */
+selection-foreground: #000000
+
+select-tag-background: #1976d2
+select-tag-foreground: #ffffff
+
+sidebar-button-foreground: <<colour foreground>>
+sidebar-controls-foreground-hover: #000000
+sidebar-controls-foreground: #aaaaaa
+sidebar-foreground-shadow: rgba(255,255,255,0.80)
+sidebar-foreground: #acacac
+sidebar-muted-foreground-hover: #444444
+sidebar-muted-foreground: #c0c0c0
+sidebar-tab-background-selected: #e3f2fd
+sidebar-tab-background: #d6d6d6
+sidebar-tab-border-selected: #90caf9
+sidebar-tab-border: #cccccc
+sidebar-tab-divider: #e4e4e4
+sidebar-tab-foreground-selected: <<colour foreground>>
+sidebar-tab-foreground: <<colour tab-foreground>>
+sidebar-tiddler-link-foreground-hover: #1976d2
+sidebar-tiddler-link-foreground: #666666
+
+site-title-foreground: #0d47a1 /* primary.deep‑dark */
+
+stability-stable:        #2e7d32
+stability-experimental:  #ed6c02
+stability-deprecated:    #d32f2f
+stability-legacy:        #303f9f
+
+static-alert-foreground: #aaaaaa
+
+tab-background-selected: #ffffff
+tab-background: #d8d8d8
+tab-border-selected: #d8d8d8
+tab-border: #cccccc
+tab-divider: #d8d8d8
+tab-foreground-selected: <<colour foreground>>
+tab-foreground: #666666
+
+table-border: #dddddd
+table-footer-background: #eeeeee
+table-header-background: #f0f0f0
+
+tag-background: #ff9800
+tag-foreground: #ffffff
+
+testcase-accent-level-1: #c1eaff
+testcase-accent-level-2: #e3b740
+testcase-accent-level-3: #5fd564
+
+tiddler-background: <<colour background>>
+tiddler-border:     <<colour background>>
+
+tiddler-controls-foreground-hover: #888888
+tiddler-controls-foreground-selected: #444444
+tiddler-controls-foreground: #cccccc
+
+tiddler-editor-background: #f8f8f8
+tiddler-editor-border-image: <<colour background>>
+tiddler-editor-border: #cccccc
+tiddler-editor-fields-even: #e8f5e9
+tiddler-editor-fields-odd:  #f1f8e9
+
+tiddler-info-background: #f8f8f8
+tiddler-info-border: #dddddd
+tiddler-info-tab-background: #f8f8f8
+
+tiddler-link-background: <<colour background>>
+tiddler-link-foreground: <<colour primary>>
+tiddler-subtitle-foreground: rgba(0,0,0,0.38)
+tiddler-title-foreground: #0d47a1
+
+toolbar-new-button:   #1976d2
+toolbar-options-button: #1976d2
+toolbar-save-button:  #2e7d32
+toolbar-info-button:  #0288d1
+toolbar-edit-button:  #ed6c02
+toolbar-close-button: #d32f2f
+toolbar-delete-button: #d32f2f
+toolbar-cancel-button: #9e9e9e
+toolbar-done-button:   #2e7d32
+
+untagged-background: #9e9e9e
+
+wikilist-background: #e5e5e5
+wikilist-item:       #ffffff
+wikilist-info:       <<colour foreground>>
+wikilist-title:      #666666
+wikilist-title-svg:  <<colour wikilist-title>>
+wikilist-url:        #757575
+
+wikilist-button-open:          #4caf50
+wikilist-button-open-hover:    #388e3c
+wikilist-button-reveal:        #1976d2
+wikilist-button-reveal-hover:  #0d47a1
+wikilist-button-remove:        #d32f2f
+wikilist-button-remove-hover:  #b71c1c
+
+wikilist-toolbar-background: #d3d3d3
+wikilist-toolbar-foreground: #888888
+wikilist-droplink-dragover: rgba(255,192,192,0.5)
+
+wikilist-button-background: #acacac
+wikilist-button-foreground: #000000

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

@@ -0,0 +1,6 @@
+created: 20250507120914164
+modified: 20250507121908782
+name: MUI Light
+tags: $:/tags/Palette
+title: $:/palettes/MUI-Light
+type: application/x-tiddler-dictionary