@tiddlywiki/mws 0.0.15 → 0.0.17

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

@@ -1,5 +1,3 @@
-created: 20250426194618683
-list: [[MWS and SQLite]] HelloThere Installation Usage Reference
-modified: 20250426194618683
+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/Access Control.md

@@ -0,0 +1,17 @@
+Access Control is implemented separately for both recipes and bags, but bags can inherit the ACL of recipes they are added to. 
+
+### Permission Inheritance
+- Users receive combined permissions from all assigned roles
+- When roles grant different permission levels for the same resource, the higher access level is granted. For example, if one role grants "read" and another grants "write" access to a recipe, the user receives "write" access since it includes all lower-level permissions. If a role grants "admin", it inherits both "read" and "write". 
+
+### "Readonly" permission
+
+If this were reversed, and users with explicit "read" access were forbidden from writing, it would significantly complicate roles. 
+
+Imagine a group of engineers working on several projects. Each project has people who are responsible for editing the documentation for everyone else. So everyone needs to be granted the read permission on all projects, but only a few people are granted the write permission on each project. 
+
+The easiest approach is to maintain one role which grants "read" access to all users, and then maintain additional roles to grant "write" access to the users responsible for each project. 
+
+If granting read access explicitly prevented a user from writing, we would need to create two roles for each project, one which which grants write access for the project, and another which grants read access to all other projects. 
+
+Every time a new project is added, all other projects would need to grant "read" access to that new "all projects but one" role on every single wiki for every single project in the entire organization. 

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

@@ -0,0 +1,5 @@
+created: 20250428145509001
+modified: 20250428174641314
+tags: Architecture
+title: Access Control
+type: text/markdown

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

@@ -0,0 +1,98 @@
+
+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.
+
+- **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. 
+
+## 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 have names and descriptions
+- Multiple users can be assigned to a role
+
+## 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
+
+#### Guest Users
+
+- 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

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

@@ -0,0 +1,5 @@
+created: 20250428144431745
+modified: 20250428152640317
+tags: Reference
+title: Application Access & Security
+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/HTTP API.md

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

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

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

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

@@ -1,5 +1,5 @@
 created: 20241105133737778
-modified: 20250417165800863
+modified: 20250428144159846
 tags: TableOfContents
 title: Installation
 type: text/vnd.tiddlywiki
@@ -20,5 +20,14 @@ See [[Troubleshooting]] if you encounter any errors.
 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 my_folder">>
-# 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">>
+# 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">>
 # Start the server. 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. <<.copy-code-to-clipboard "npm start">>
+
+!!! Git repo
+
+It is optionally 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.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/Moduler Design.md

@@ -22,3 +22,8 @@
 
 - Maps route definitions into service handlers
 - HTTP, Websockets
+
+### Database Connector
+- Prisma handles query translation (wasm or native addon)
+- Prisma supports custom adapters, and also provides standard ones
+- Connector classes in MWS take care of database setup and schema updates

package/editions/mws-docs/tiddlers/Moduler Design.md.meta

@@ -1,5 +1,5 @@
 created: 20250418140335465
-modified: 20250418183050517
+modified: 20250428143321351
 tags: Architecture
 title: Moduler Design
 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/Reference.md

@@ -1,149 +0,0 @@
-# Authentication & Authorization
-
-## Overview
-
-Our application has transitioned from a conventional username/password authentication system to a more robust Authentication and Authorization implementation. This new system supports multiple user accounts, roles, permissions, and a comprehensive access control list.
-
-## Key Features
-
-1. Multiple User Accounts
-1. Role-based Access Control
-1. Granular Permissions
-1. Access Control List (ACL)
-
-## Application Access & Security
-
-### Access Levels
-
-Conceptually, there are 6 access levels.
-
-- **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.
-- **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 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. 
-
-### Initial Setup
-
-When you first launch the Multiwiki Server, it creates a default admin user. The username is `admin` and the password is `1234`. To secure your installation you should change this immediately. 
-
-### 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 have names and descriptions
-- Multiple users can be assigned to a role
-
-### Permissions
-
-- **READ** - Read tiddlers from an entity.
-- **WRITE** - Write tiddlers to an entity.
-- **ADMIN** - Update ACL for an entity.
-
-### 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
-
-#### Guest Users
-
-- 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
-
-### Access Control
-
-Access Control is implemented separately for both recipes and bags, but bags can in inherit the ACL of recipes they are added to. 
-
-#### Permission Inheritance
-- Users receive combined permissions from all assigned roles
-- When roles grant different permission levels for the same resource, the higher access level is granted. For example, if one role grants "read" and another grants "write" access to a recipe, the user receives "write" access since it includes all lower-level permissions.
-
-If this were reversed, and users with explicit "read" access were forbidden from writing, it would significantly complicate roles. 
-
-Imagine a group of engineers working on several projects. Each project has people who are responsible for editing the documentation for everyone else. So everyone needs to be granted the read permission on all projects, but only a few people are granted the write permission on each project. 
-
-The easiest approach is to maintain one role which grants "read" access to all users, and then maintain additional roles to grant "write" access to the users responsible for each project. 
-
-If granting read access explicitly prevented a user from writing, we would need to create two roles for each project, one which which grants write access for the project, and another which grants read access to all other projects. 
-
-Every time a new project is added, all other projects would need to grant "read" access to that new "all projects but one" role on every single wiki for every single project in the entire organization. 
-
-## User Management & Security Architecture
-
-### User Account Management
-
-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
-
-# HTTP API
-
-The MultiWikiServer HTTP API provides management and tiddler endpoints. It 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 design goals of the API are:
-
- - Connect the client and server as transparently as possible. 
- - Follow the principles of remote procedure calls.
- - Be easy to understand and use via Javascript. 
- - Have strict validation of incoming requests.
-
-General points about the design:
-
-- 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, which is expected to return to the client. It should give them an actionable understanding of what went wrong. 
-

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

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