Docs: Move documentation from plugin into multiwikidocs edition

@webplusai future docs updates should go to `editions/multiwikidocs`

By the way, it's worth noting that the recent updates in # 8748 were in Markdown syntax, which is slightly different from TiddlyWiki syntax. See the corrections here.

editions/multiwikidocs/tiddlers/DefaultTiddlers.tid

@@ -2,4 +2,5 @@ title: $:/DefaultTiddlers
 
 HelloThere
 Installation
-Usage
+Usage
+Reference

editions/multiwikidocs/tiddlers/Reference.tid

@@ -0,0 +1,229 @@
+title: Reference
+
+! 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
+
+# Multiple User Accounts
+# Role-based Access Control
+# Granular Permissions
+# Access Control List (ACL)
+
+!! Application Access & Security
+
+!!! Initial Setup
+When you first launch the Multiwiki Server, it operates in an unauthenticated mode to facilitate initial configuration. During this initial state, the system creates a temporary anonymous administrator account. Upon accessing the landing page, you'll receive a prominent security warning with instructions to establish a permanent ADMIN account. It's crucial to create this account immediately to secure your installation.
+
+!!! User Types and Permissions
+
+!!!! Administrator (ADMIN)
+
+* Full system access and configuration rights
+* Can create, modify, and delete user accounts
+* Manages role assignments and permissions
+* Controls global system settings
+* Can configure guest access policies
+* Has complete control over all recipes and tiddlers
+
+!!!! Regular Users
+* Custom accounts created by administrators
+* Permissions determined by assigned roles
+* Access limited to specific recipes based on role permissions
+* Can have READ and/or WRITE permissions
+
+!!!! Guest Users
+* Default anonymous access level
+* No inherent permissions
+* Can only access recipes without Access Control Lists (ACLs)
+* Read/write capabilities configurable by ADMIN
+* Useful for public wikis or documentation sites
+
+!!! Access Control System
+
+!!!! Recipe-Level Security
+* Access control is implemented at the recipe level
+* Each recipe can have its own Access Control List (ACL)
+* Permissions are granular:
+** READ: Allows viewing recipe contents
+** WRITE: Allows modifications to recipe contents
+
+!!!! Role-Based Access Control (RBAC)
+* Administrators can create custom roles
+* Roles can be assigned specific READ/WRITE permissions
+* Users inherit permissions from their assigned roles
+* Multiple roles can be assigned to a single user
+* Provides flexible and scalable access management
+
+!!!! Permission Inheritance
+* Users receive combined permissions from all assigned roles
+* More permissive role takes precedence in conflicts
+* Guest access is overridden by recipe ACLs
+* System automatically enforces most restrictive access when conflicts occur
+
+This security model allows for fine-grained control over content access while maintaining flexibility for both private and public wiki deployments.
+
+!! User Management & Security Architecture
+
+!!! User Account Management
+
+Users can be administered through two interfaces:
+
+# Web-based Administrative Interface
+#* Accessible only to ADMIN users
+#* Provides graphical interface for user operations
+#* Real-time validation and feedback
+# Command-line Interface (CLI) Tools
+#* 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
+* ''Role Assignments''
+** Multiple roles can be assigned
+** Inherited permissions from all assigned roles
+** Dynamic permission calculation based on role combination
+
+!!! Role & Permission Framework
+
+!!!! Role Management
+
+Roles serve as permission containers and provide organized access control. The system includes:
+
+Built-in Roles:
+
+* `ADMIN`
+** Highest privilege level
+** Full system access
+** Cannot be modified or deleted
+** Can create and manage other roles
+** Controls guest access policies
+
+* `USER`
+** Basic access rights
+** Typically limited to specific recipes
+  
+**Custom Roles (Examples):**
+
+* `MANAGER`
+** Intermediate access level
+** Can manage subset of resources
+** Custom roles as needed for specific use cases
+
+!!!! Permission Architecture
+
+Core Permissions:
+
+* `READ` Permission
+** View recipe contents
+** Access tiddler data
+** View metadata
+** Export capabilities
+
+* `WRITE` Permission
+** Create new tiddlers
+** Modify existing content
+** Delete resources
+** Manage recipe contents
+
+**Guest Access:**
+
+* No default permissions
+* Access limited to non-ACL recipes
+* Configurable by ADMIN users
+* Suitable for public wikis
+
+!!! Access Control List (ACL) Implementation
+
+The ACL system provides granular security control through:
+
+!!!! Entity-Level Control
+
+* Recipe-based access control
+* Individual resource protection
+* Hierarchical permission inheritance
+
+!!! Authentication Process Flow
+
+* Initial Authentication
+** User submits credentials
+** System validates username existence
+** Password hash comparison
+** Session token generation
+
+* Session Management
+** Secure session storage
+** Token-based authentication
+** Automatic session expiration
+** Re-authentication requirements
+
+!!! Authorization Workflow
+
+* Request Processing
+** Capture user action request
+** Identify target resource
+** Extract required permissions
+
+* Permission Validation
+** Check user roles
+** Aggregate permissions
+** Verify ACL entries
+** Apply guest policies if applicable
+
+* Access Decision
+** Compare required vs. available permissions
+** Apply most restrictive policy
+** Return access decision
+
+!!! System Extension Guidelines
+
+!!!! Adding New Roles
+
+# Access administrative interface
+# Define role identifier
+# Assign base permissions
+# Configure ACL mappings
+# Test role functionality
+
+!!!! Permission Expansion
+
+# Define new permission type
+# Update ACL structure
+# Implement permission checks
+# Update validation logic
+# Document new permission
+
+!!!! Security Considerations
+
+* Regular permission audits
+* Role assignment reviews
+* Guest access monitoring
+* Security log analysis
+* Access pattern monitoring
+
+This comprehensive security model provides flexible, maintainable, and secure access control while supporting both authenticated and guest users within the Multiwiki Server environment.
+
+! HTTP API
+
+The ~MultiWikiServer HTTP API provides access to resources hosted by the MWS store. It is based on [[the API of TiddlyWeb|https://tank.peermore.com/tanks/tiddlyweb/HTTP%20API]], first developed in 2008 by Chris Dent.
+
+The design goals of the API are:
+
+* To follow the principles of REST where practical
+* To present resources as nouns, not verbs
+
+General points about the design:
+
+* In MWS there are no resources that end with / (except for the root path which is /)

plugins/tiddlywiki/multiwikiserver/docs/docs.tid

@@ -1,14 +0,0 @@
-title: $:/plugins/tiddlywiki/multiwikiserver/docs
-
-! HTTP API
-
-The ~MultiWikiServer HTTP API provides access to resources hosted by the MWS store. It is based on [[the API of TiddlyWeb|https://tank.peermore.com/tanks/tiddlyweb/HTTP%20API]], first developed in 2008 by Chris Dent.
-
-The design goals of the API are:
-
-* To follow the principles of REST where practical
-* To present resources as nouns, not verbs
-
-General points about the design:
-
-* In MWS there are no resources that end with / (except for the root path which is /)

plugins/tiddlywiki/multiwikiserver/docs/readme.tid

@@ -2,238 +2,4 @@ title: $:/plugins/tiddlywiki/multiwikiserver/readme
 
 This plugin extends the TiddlyWiki 5 server running on Node.js to be able to host multiple wikis that can share content or be independent.
 
-!! Installation
-
-```
-# Clone the repo into ./TiddlyWiki5
-git clone https://github.com/Jermolene/TiddlyWiki5.git --branch multi-wiki-support
-cd TiddlyWiki5
-
-# Install dependencies
-npm install
-
-# Start the server
-npm start
-```
-
-Then visit the administration interface in a browser: http://127.0.0.1:8080/
-
-The `npm start` command is a shortcut for the following command:
-
-```
-node ./tiddlywiki.js ./editions/multiwikiserver --mws-listen
-```
-
-Note that changes are written to the topmost bag in a recipe.
-
-Note that until syncing is improved it is necessary to use "Get latest changes from the server" to speed up propogation of changes between users.
-
-To run the tests:
-
-```
-./bin/test.sh
-```
-
-# 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
-2. Role-based Access Control
-3. Granular Permissions
-4. Access Control List (ACL)
-
-## Application Access & Security
-
-### Initial Setup
-When you first launch the Multiwiki Server, it operates in an unauthenticated mode to facilitate initial configuration. During this initial state, the system creates a temporary anonymous administrator account. Upon accessing the landing page, you'll receive a prominent security warning with instructions to establish a permanent ADMIN account. It's crucial to create this account immediately to secure your installation.
-
-### User Types and Permissions
-
-#### Administrator (ADMIN)
-- Full system access and configuration rights
-- Can create, modify, and delete user accounts
-- Manages role assignments and permissions
-- Controls global system settings
-- Can configure guest access policies
-- Has complete control over all recipes and tiddlers
-
-#### Regular Users
-- Custom accounts created by administrators
-- Permissions determined by assigned roles
-- Access limited to specific recipes based on role permissions
-- Can have READ and/or WRITE permissions
-
-#### Guest Users
-- Default anonymous access level
-- No inherent permissions
-- Can only access recipes without Access Control Lists (ACLs)
-- Read/write capabilities configurable by ADMIN
-- Useful for public wikis or documentation sites
-
-### Access Control System
-
-#### Recipe-Level Security
-- Access control is implemented at the recipe level
-- Each recipe can have its own Access Control List (ACL)
-- Permissions are granular:
-  - READ: Allows viewing recipe contents
-  - WRITE: Allows modifications to recipe contents
-
-#### Role-Based Access Control (RBAC)
-- Administrators can create custom roles
-- Roles can be assigned specific READ/WRITE permissions
-- Users inherit permissions from their assigned roles
-- Multiple roles can be assigned to a single user
-- Provides flexible and scalable access management
-
-#### Permission Inheritance
-- Users receive combined permissions from all assigned roles
-- More permissive role takes precedence in conflicts
-- Guest access is overridden by recipe ACLs
-- System automatically enforces most restrictive access when conflicts occur
-
-This security model allows for fine-grained control over content access while maintaining flexibility for both private and public wiki deployments.
-
-## User Management & Security Architecture
-
-### User Account Management
-
-Users can be administered through two interfaces:
-1. Web-based Administrative Interface
-   - Accessible only to ADMIN users
-   - Provides graphical interface for user operations
-   - Real-time validation and feedback
-2. Command-line Interface (CLI) Tools
-   - 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
-- **Role Assignments**
-  - Multiple roles can be assigned
-  - Inherited permissions from all assigned roles
-  - Dynamic permission calculation based on role combination
-
-### Role & Permission Framework
-
-#### Role Management
-Roles serve as permission containers and provide organized access control. The system includes:
-
-**Built-in Roles:**
-- `ADMIN`
-  - Highest privilege level
-  - Full system access
-  - Cannot be modified or deleted
-  - Can create and manage other roles
-  - Controls guest access policies
-
-- `USER`
-  - Basic access rights
-  - Typically limited to specific recipes
-  
-**Custom Roles (Examples):**
-- `MANAGER`
-  - Intermediate access level
-  - Can manage subset of resources
-- Custom roles as needed for specific use cases
-
-#### Permission Architecture
-
-**Core Permissions:**
-1. `READ` Permission
-   - View recipe contents
-   - Access tiddler data
-   - View metadata
-   - Export capabilities
-
-2. `WRITE` Permission
-   - Create new tiddlers
-   - Modify existing content
-   - Delete resources
-   - Manage recipe contents
-
-**Guest Access:**
-- No default permissions
-- Access limited to non-ACL recipes
-- Configurable by ADMIN users
-- Suitable for public wikis
-
-### Access Control List (ACL) Implementation
-
-The ACL system provides granular security control through:
-
-#### Entity-Level Control
-- Recipe-based access control
-- Individual resource protection
-- Hierarchical permission inheritance
-
-
-### Authentication Process Flow
-
-1. Initial Authentication
-   - User submits credentials
-   - System validates username existence
-   - Password hash comparison
-   - Session token generation
-
-2. Session Management
-   - Secure session storage
-   - Token-based authentication
-   - Automatic session expiration
-   - Re-authentication requirements
-
-### Authorization Workflow
-
-1. Request Processing
-   - Capture user action request
-   - Identify target resource
-   - Extract required permissions
-
-2. Permission Validation
-   - Check user roles
-   - Aggregate permissions
-   - Verify ACL entries
-   - Apply guest policies if applicable
-
-3. Access Decision
-   - Compare required vs. available permissions
-   - Apply most restrictive policy
-   - Return access decision
-
-### System Extension Guidelines
-
-#### Adding New Roles
-1. Access administrative interface
-2. Define role identifier
-3. Assign base permissions
-4. Configure ACL mappings
-5. Test role functionality
-
-#### Permission Expansion
-1. Define new permission type
-2. Update ACL structure
-3. Implement permission checks
-4. Update validation logic
-5. Document new permission
-
-#### Security Considerations
-- Regular permission audits
-- Role assignment reviews
-- Guest access monitoring
-- Security log analysis
-- Access pattern monitoring
-
-This comprehensive security model provides flexible, maintainable, and secure access control while supporting both authenticated and guest users within the Multiwiki Server environment.
+See https://mws.tiddlywiki.com/ for more information.

plugins/tiddlywiki/multiwikiserver/plugin.info

@@ -2,7 +2,7 @@
 	"title": "$:/plugins/tiddlywiki/multiwikiserver",
 	"name": "Multi Wiki Server",
 	"description": "Multiple Wiki Server Extension",
-	"list": "readme docs",
+	"list": "readme",
 	"dependents": [],
 	"stability": "STABILITY_1_EXPERIMENTAL"
 }