Yes, I finally understood that, and the fact that when creating a recipe, the last bag listed is the one on top of the pile, that is not absolutely obvious and could be explained somewhere…
What I would love to know now is how to serve those wiki in a small LAN for private or local usage at home or at work from my machine to the others on the same LAN. In both windows and Mac environnements…
I think you did misunderstand the whole thing. It is more like a “common” client server setup. Where there is one server instance, which can manage several users.
The MWS directory structure is like this:
wiki/
+-- store/
| +-- files/
| | + <hash>/<binary large files>
| + database.sqlite
| + database.wal
| + database.sqlite-shm
|
+-- tiddlers/
+ admin tiddlers
+ temporary tiddlers
The tiddlers directory is not intended to be synced.
SQLite was designed to be used as a “single file database”. It was designed as a “file access” replacement with indexing capabilities for faster access. See the story behind SQLite
IMO it is not a new mode. It is a completely different approach to store the data in a single file database, instead of single tiddler files. The main advantage will be speed. The MWS plugin provides a conventional server, that can handle several users.
It is intended to work in anonymous mode from the start. But IMO you can “forget” git. It is not intended to work that way.
IMO that’s not how MWS is designed at the moment. If you extract your content from the database into files and you want to sync on a file, per file bases you will create a lot of synchronisation problems, that will be impossible to manage.
There seems to be an SQLite version, which allows sync on the database level. But that’s not officially supported.
Just my thoughts.
@jeremyruston can provide more details.
Some interesting Links
Could it be usefull to pack all the requirements for MWS into a dockerfile that can be downloaded somewhere?
Okay, Seems MWS is not suitable to build local-first app like TidGi-Desktop. I will find another way to utilize “bag” and “recipe” concept in it, maybe write a new plugin, and try to reuse as much of things as possible.
I’m already using SQLite in TidGi-Mobile, and the speed improvment is not big, the main cost is still index building, so I mainly want MWS’s bag-recipe feature, and want to conbine it with filesystemPath feature.
Hi @linonetwo, I have recently started using tiddlyserver on node.js to set up multiple wikis that each have a shared source which contains all my custom system tiddlers and common config, as well as a tiddlers directory which contains the actual data of each wiki. This is configured via the tiddlywiki.files file.
Changes to system files are stored in the shared source, new tiddlers are saved into each wiki’s folder. This is coordinated via the $:/config/FileSystemPaths tiddler. If I want to share a tiddler between wikis then I just copy it from the original wiki’s folder to the shared folder.
All tiddlers are stored as single files. You could sync each wiki’s folder separately, just like the shared one.
The only drawback is that you have to restart tiddlyserver after making changes to the files (either manually or through syncing) and refresh the wikis in the browser, because changes to the files are only detected upon server startup.
If you are interested, I can make a longer wiki post here in the forum that explains this in more detail.
Have a nice day
Yaisog
PS: You could probably also use multiple instances of tiddlywiki instead of tiddlyserver – I use the latter mainly for its file-serving capabilities, to load external fonts (as having a bunch of fonts embedded can lead to enormous StyleRefresh durations).
This might explain something I saw when trying to share “common” stuff among different wikis.
I’m definitely interested.
Which version of TS are you using? I believe I’m 2.0.
Thanks, I understand what you said, the problem is I’m trying to make a user friendly product based on TiddlyWiki and plugins, but FileSystemPaths is difficult to config, and it is very verbose to write folder path using addprefix filter.
This is the biggest problem I want to solve with bag-recipt.
That is also not a big problem, I tried to make GitHub - tiddly-gittly/watch-fs: Let TiddlyWiki to watch the change in your disk, and if you edit one of your tiddler using editor likes VSCode and save it on the disk, the change will immediately reflected in the browser. years ago, and it is working when no renaming/deletion is happened (not implemented for some cases like this).
I’m not currently using this due to several bugs, but TidGi app will auto reload when file changed from disk.
Tiddlywiki web also supports file serving via /file path, TidGi and Tiddlywiki Desktop app also support file:// protocol, via ability of Electron and nwjs.
I’m mainly interested in making an app, because most of users don’t own a server and can’t use cli. I want to make things that works for more users.
I will try to find the time for it in the very near future.
I use tiddlyserver v2.2.1.
Actually, I only use FileSystemPaths to make a cleaner directory structure instead of dumping it all in one folder:
[removeprefix[$:/patches]addprefix[patches/]]
[is[draft]search-replace:g:regexp[/|\\],[_]addprefix[drafts/]]
[removeprefix[$:/tiddler-todos]addprefix[tasks/]]
[removeprefix[$:/tracking]addprefix[tracking/]]
[!field:source[shared]removeprefix[$:/mwi]addprefix[system/mwi/]]
[!field:source[shared]removeprefix[$:/core]addprefix[system/core/]]
[!field:source[shared]removeprefix[$:/config]addprefix[system/config/]]
Patches (differential backups), to-dos and time-tracking tiddlers go into their own subfolders, and some others is are sorted into subfolders for better findability. Except for maybe the drafts rule, none of these are required. The field source is set to shared by a tiddlywiki.files rule for the shared source folder, because I would like to avoid that edits to a shared tiddler get saved into the local wiki folder due to a file naming rule. If you have no such naming rules then this does not apply.
Essentially, each top-level folder is a bag, and the recipes are configured via one or more subfolders containing a tiddlywiki.files file. Maybe it becomes clearer when I get around to make a “wiki” forum post.
Also, just to be clear: I absolutely like the idea of MWS and its improved storage. But as @linonetwo noted, this is not ideal for backup and synchronization between multiple machines. The sync problem and the difficulty of the associated conflict management is the main reason why I changed from a single-file wiki to node.js in the first place - sync conflicts now affect only easily identifiable single tiddlers, not the wiki as a whole.
I am syncing my wikis between 3 machines which are not all on the same network, so I cannot use a central server.
I’m now stop thinking using MWS in personal wiki app. Instead I’m thinking if MWS can be used to setup forum like this talk forum?
Or simply use it as doc site that everyone can edit, without Github PR and Github account, which is not familiar to most of users.
Hi @linonetwo the SQLite database file is stored in the store subfolder of the wiki folder. This folder is currently ignored by the .gitignore file and so you won’t see the changes in GitHub Desktop.
At the moment all data is stored in the database apart from file attachments which are stored in the file system directly.
We will have the ability to sync to external, individual tiddler files, just as we do at the moment with the “filesystemadaptor”. The way to think about SQLite in TiddlyWiki is that it is a drop in replacement for the wiki object. The wiki object is already a kind of custom database implementation, with indexes and triggers. Now we’re replacing that engine with SQLite because it is faster and more efficient.
MWS is currently configured to store the SQLite database in the filesystem, but in practice I expect many people will prefer to run SQLite as an in-memory database, and rely on sync for IO.
I’ll make some updates to the docs to try to clarify these points.
We are certainly not stuck with the codename “MWS”. I think you are right that MWS should be presented as an optional add-on to the basic TW product, and so the name should ideally be a qualification we can add to “TiddlyWiki”, like “TiddlyWiki Plus”.
In that situation the user would be able to import their existing wikis into their MWS instance.
Add the option host=0.0.0.0 to the --mws-listen command:
tiddlywiki editions/multiwikiserver --mws-listen host=0.0.0.0
I don’t have enough experience of Docker myself, but I would welcome any contributions in this area.
Please see my clarification above.
That is certainly one of the longer term goals. I hope we’ll have a community instance of MWS for us to experiment with quite soon.
If I understand well, this command needs to be along with
npm start
and the IP adress should be change to whichever I need ?
Or Can I write it down in a file to set it at normal startup?
And, also, which command is used to upgrade to the lastest version of MWS ?
This will listen on your ip. And you can access it on 127.0.0.1:8080 or some other port.
Usually we write it in package.json, and use npm script to run it.
MWS is not released yet so I think you can only copy latest version from TiddlyWiki Github repository. When it is offically released, you can one-click upgrade it via CPL or official plugin library.
It would be really great to have an Integration of TiddlyWiki MultiUserWiki in Nextcloud. I just saw this Video on the NextCloud’s OCS (Open Collaboration System) which is a very welcoming invitation.
As many organisations (like my own school) already have a nextcloud this would open TW to a broader audience. On the other Hand, it would be very practical to be able to use the tools Nextcloud offers in TW. @well-noted . For example, they just enriched their ecosystem with a pretty straight forward way to run localAI on the same server. (Exeptionally I only found a good instructional video for this in German ) .
I opened an xtra thread for this here: Adding a TiddlywikiApp to the Nextcloud-Ecosystem
I’m likely missing something – how does one delete bags or recipes when running MWS?
Earlier I speculated this was a bug that would be fixed with the release of 5.3.6, but, though the selection screen looks more put-together, it’s still not clear to me how to do so
Also, is it possible/planned to easily move tiddlers between bags?
Bag and recipe deletion is not yet implemented. It might actually make a good PR for a new contributor.
MWS is very much at the MVP stage at the moment: there’s enough there to be able to try it out, but if it was a building there would still be walls and floors missing, and the odd staircase that doesn’t lead anywhere…
For the moment there is no direct API to move tiddlers between bags; as is common is REST APIs it is necessary for clients to read the entities and then write them back to the server. Eventually we’ll need a more efficient way to do it.
I have resumed my experiments with the plugin, now I have a functional delete button for Bags and Recipes.
I assumed that I would be able to shuffle contents between bags simply by changing the value of the bags field, but had inconsistent results with that. When I was about to give up, I realized something that might be noteworthy – it seems that bag names with hyphens, e.g “All-tiddlers,” will not successfully populate the index page for that particular bag, whereas “All_tags” works fine.
There’s no mechanism in place to prevent a bag from being titled with a hyphen, nor any documentation on the index page about this, so it’s at least something to consider if someone is attempting something similar and experiencing difficulty.
In this case, it was rather lucky of me to have not settled on a consistent name styling, that I was able to notice it. 
EDIT:
Actually, I am still experiencing pretty inconsistent results with this and have not tracked down a common thread as to why. Sometimes when I change the bag value, the change will be reflected in the bag index, but other times it will not, even though the field value itself is being accepted and persists through reloads. Does this mean that the bag field is not entirely reflective of the sorting?
Will continue to document as I toy with it.
So far I have had mixed results both with changing the bag value manually (from edit) and in bulk.
Sound like MWS needs a kind of “orphans” function…
I think something like that would be reasonable… though I suppose realistically that would just be an “orphans” bag. At current, my general impression is that they default to whichever tiddler is top of the recipe they are imported into, if you are using the traditional import features. I hesitate to think that deleting a bag necessarily deletes all tiddlers in that bag: I think it makes sense to have some kind of default “catch” where tiddlers end up if they are not explicitly deleted.
I don’t know if I was really having success changing bags by changing the field values, or if I was given that false impression because I was resorting the recipe.
I personally am a big fan of the idea of moving from one bag to another by changing the field value, but after some experimentation yesterday I am not so sure that will be possible, and I think pursuing direct changes to the database is going to be the strategy. This leads me to wonder if the bag field is truly vestigial at this point.
Instead I have modified the post-bag-tiddlers.js to also handle move operations and added a form to the bottom of get-bag.tid which allows the user to move tiddlers from one bag to another:
It currently requires the user to add the title manually and does not accept arrays – once I figure out how to make the checkbox functionality work with it and implement arrays, I’ll make a PR.
