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.
3 Likes
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.
1 Like
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
1 Like
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.
1 Like
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.
In a multiuser-wiki, I guess also a tool to identify orphaned bags could be useful.
That is to say bags now wiki refers to anymore or to wikis of users that are gone.
Does something like that exist?
In this case, you mean to say “Bags which belong to no Recipes.”
No, that doesn’t exist currently, but it’s an interesting idea. Perhaps a more elegant solution would be, for each bag, a list of all recipes to which a bag belongs?
Great, it would be cool to have a filter on top to see which bag is assosiated with which recipe… and which is not used at all.
And should/could there be a tool to see which recipe is owned resp shown to which user?
Maybe an admin panel would be better suited for this? I would be concerned about cluttering up this main page too much – and I don’t think it would be necessary for all users to have this knowledge. Thoughts?
Can you clarify what you mean by this?
Recipes already show the bags that are in them
And I am proposing recipes with which a bag are associated should be listed beneath them
So what additional filtering would you like to see?
-
"Show me only bags that are associated with this recipe?"
Is there any reason why this would be superior than just looking at the recipe list? -
"Show me only recipes that are associated with this bag?"
Why would this be superior to just checking the associated recipes list?
The only thing I could imagine might be beneficial would be filtering for multiple bags in a recipe, like, show me only recipes that contain A and B but not C – though I’d be interested in hearing more about the scenario this would be called for which could not be handled better with administrative levels.
In a similar vein, I wonder if it would not be sufficient to include list-sorting, so the user could, for example, sort by number of recipes to which a bag is associated? Low to high, therefore, first showing bags included in no recipes.
I don’t believe there is anything inherently “orphaned” (though I certainly understand your choice of word) about having bags that have no recipes - especially if moving multiple tiddlers between bags is easy, someone might want to have repository bags that they could shuffle tiddlers in and out of, which would be associated with no recipes – and that could be especially helpful if some of those bags contain large media files, for example, or time-sensitive content such as in the case of coursework.
1 Like
This is only true for “public” recipes. An owner should be able to define, if a recipe is visible to others. The same is true for bags. Otherwise it would be a privacy issue.
1 Like
I could imagine a tiered administrative system where if you have access to a level you could be given permissions to see the owners of other wikis in your tier and/or beneath your tier. I would need to put more thought into the bigger picture of wiki administration, since my current needs are not especially broad in that sense.
If I understand @JanJo 's use case though, I think they would have a good perspective on this.
1 Like
I guess administrative Tools like that become absolutely necessary given a certaike number of users. @jeremyruston How do you treat these questions at anna freud?