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).

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

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