Dropbox offers version control, but there us no automatic idiot-proof conflict management system. team members have files on their own machines, hosted locally and synced. The Tiddlyweb protocol comes very close to what I am thinking of, but it will still take some work.Īlex Hough You can, in small groups use TiddlyWiki with Dropbox. Also there is Tank, but that seems to be basically dead. I have been thinking about this and I think TiddlySpot and MediaWiki should give us some ideas of where to start. It’s the same thinking as the current TWederation work. I’m still an enthusiast for the approach that TiddlySpace took - separate spaces for individual users or small, trusted groups, and space inclusion as the primary sharing mechanism. My own view, which evolved before TiddlySpace, is that shared spaces do not work beyond a very small number of users. Your document strays into some questions around the design collaboration systems. Personally, I’m a huge fan of not having to run a conventional server, and not having to worry about patches and intrusion attempts :) Rather than a conventional server, I stitch together services like S3, CloudFront and Lambda to build TiddlyWiki HTML files and provide an API for them to use. In my day job, I’ve been doing a lot of work with getting TiddlyWiki running under Amazon Web Services. So I’d always encourage such experimentation. TiddlyWiki’s strong encapsulation at the HTTP boundary makes it easy to build new and different server sides for it a simple serverside for TiddlyWiki is a good deal less complicated than TiddlyWiki itself. On the whole, I don’t think they would be a huge problem for a community documentation project. (In that situation I would handle interactivity by swapping in revised definitions for macros like the TOC, or tabs, that use minimal JS to manipulate state in the DOM (like Bootstrap etc)).Īs you reflect in the Google doc, there are some security issues with sharing TiddlyWiki content on the server. Or, as you note, we can generate standalone HTML tiddlers on the server. For example, we can ship skinny tiddlers to the client, but handle searches on the server. The best approach to the problem you mention of all the tiddlers being shipped to the client is to shift some or all of the processing back to the server. The biggest architectural change that I can see is to separate the client wiki from the server wiki, so that they don’t need to be same (with the same plugins etc). None of those things present any implementation difficulties. * There’s no support for multiple revisions
* There’s no feedback if the edits of another user clash with your own * There’s no instant notification of changes made by another user * There’s no separation between different users, so they share the same username for signing edits, and share the same state data (much of the state data isn’t synced to the server eg for popups) I’m going to respond with a few points here to keep the information together.įirstly, TiddlyWiki under Node.js is specifically designed for multi-user scenarios, but there are some rough edges that make the experience imperfect at present:
įeel free to add comments on the document itself or here. Not that I have a lot of experience, but for what it's worth. Part of this comes from my experience on Wikipedia, and part from setting up my own MediaWiki installations on my computer. In that sense its a kind of multi-users system, though with no hierarchy rights?Īfter making the comment on the documentation, I started wondering exactly what it would require to re-invent the MediaWiki juggernaut as TiddlyWiki. What I mean is if I synced to multiple devices could I work on one could I go further than have the other version register it? For instance, I get 3 other people to work simultaneously on three other instances of the same on different computers, could it cope and harmonise them?Īs far as I grasp the tech both PouchDB and CouchDB are optimised for syncing. I was wondering, given the sophistication of the PouchDB (TW) and a possible CouchDB (Apache server) combo could this permit what I might call "A Surrogate Multi-User TW"? If he and his brother both submitted at the same time, someone's entry would lose. It's definitely not true that the TW5 is now multi-user.
Since the security is being provided by the server, he would like to hard-wire the password in the TW5 file so that he doesn't have to re-type it every time he goes on a new platform. htaccess and have the file (usually the entire folder) protected by a password via the server's protection system. Multi-User Environments - Authentication and ACLs-Policies 1276.Using TiddlyWiki With Simultaneous Multi-User Updates On Own Server.Collaborative use of TW-possibility to merge.Setting up a Tiddlywiki for multiple users.