Multi User Summary

181 views
Skip to first unread message

Stobot

unread,
Jan 4, 2020, 10:00:41 AM1/4/20
to TiddlyWiki
I really appreciate all the recent discussion around multi-user solutions - though in my usage, it's still not nearly as mature as single-user, which obviously makes sense. The point of this post is to see if others can point out something I've missed, as there are a LOT of solutions out there listed on the "GettingStarted" page, but most are over my head from a technical standpoint. My technical background is Visual Basic type stuff, not web stuff. If I can identify that one of them solves all of my problems, I'll buckle down and try to learn that one.

My environment is a team of about 40 users around Canada/USA, in a corporate, microsoft-based environment with SharePoint. That (SharePoint) makes single user stuff ideal - automatic backups, ActiveDirectory authentication, available everywhere, though unusable from a multi-user standpoint. The best/easiest multi-user setup is BOBEXE, but there are some significant drawbacks in comparison, and that's where I'm looking for input. What I'm building / have built is a project management platform - similar to an ASANA or something, but that has all the benefits of TiddlyWiki that we know and love. I *should* probably just use ASANA, but I'm a long term user and somewhat obsessed, and want to solve all my problems with TiddlyWiki - I'm sure some of you can relate.

Here's my quick decision matrix from my knowledge - can't seem to type a table here, so will do as list:
  • Content stored in a way that's parse-able. If I can parse it, I can use other software (like Microsoft Flow/PowerAutomate) to turn new items into email notifications - like other project management does, or do pseudo RSS stuff.
    • SharePoint/WebDav/ASPX: No ability (that I know of) here
    • BOB: Works great - the .tid is a little weird to parse vs. json or something, but doable
  • Wiki responds to simultaneous edits. Absolutely key for my use case
    • SharePoint..: Total fail here, you don't see impact of others until you manually refresh, anything done in that session is lost.
    • BOB: Fantastic here, changes are so fast it's like magic (especially when you're in the same building as the 'server')
  • Only *some* tiddlers sync, some don't (like $:/temp/...). This is important for things like storing usernames etc. as well as many other UI pieces
    • SharePoint: Nope
    • BOB: Yup, very customizable
  • Backups: Obviously the easier the better
    • SharePoint: Tons and automatic, though at full file-level
    • BOB: Can do manually due to file storage, little painful by comparison but workable
  • Available on mobile:
    • SharePoint: Yep, security just goes through ActiveDirectory, then works same as on-network, beautiful
    • BOB: Not that I know of, I keep reading about something called Termux, not sure if that's easy enough to scale to all 40 of us (most less technical than myself)?
  • Available off-corporate network:
    • SharePoint: Yep, works normally from home
    • BOB: Some of my users have VPN access and can access it from home, some don't / can't. Is there a different solution?
  • Reconnectability: My team constantly docks and undocks their laptops flipping back and forth LAN / WIFI all day
    • SharePoint: No issues
    • BOB: I've never got the re-connect ability to work, and sometimes it doesn't even give the red warning until after significant work has been done - little painful
  • Summary
    • SharePoint: Fantastic and easy for single-author stuff that's not very interactive, but like a standard wiki. Not going to work for my use case
    • BOB: Good at what it was designed for, though a little painful from an access / user convenience point of view vs. something like ASANA (hosted solution)
I can't help but think that TiddlySpace (which I was aware of, but didn't really need at the time) would've been the best of both worlds. The 'future' list of BOB looks like hosting may come eventually, but is not there yet. Let me just say again that I don't want this to come across as overly critical, I'm very thankful for TiddlyWiki, BOB (Jed), and the rest of this community donating so much time. I'm just hoping some of you with more experience in web stuff than me can point out something I've missed. Also I'll say that while this may seem like an edge case, if someone were to monetize TiddlyWiki, a multi-user platform like how I'm trying to use it would be a *great* place to start. If I can't figure this out I think I'll be paying some alternative at least $10 / user / month in perpetuity.

Sorry for the long post - appreciate you if you made it this far :)

Mark S.

unread,
Jan 4, 2020, 3:51:17 PM1/4/20
to TiddlyWiki
The original intention of TiddlyWiki was as a single-user, single-file tool. The fact that you can almost get it to work as a multi-user platform says something about its flexibility.

You could have each user run their own TW node instance, and then have the tiddlers synchronized via syncthing or drop-box. A "gentlman's" (or gentlewoman's) agreement could help prevent collisions. You can run TiddlyServer or node.js on Termux on Android, though I've never tried Bob.

There are a lot of existing Wiki and content management systems out there. Perhaps one of them is more suited to your goals.

Do you have an actual budget for this project? I believe Jeremy has a commercial product/service that might fit your needs more precisely.

Good luck!

TonyM

unread,
Jan 5, 2020, 1:43:19 AM1/5/20
to TiddlyWiki
Stobot,

This is a big subject. Let me try a concise initial answer by example. 

My Example.
I have produced a commercial solution on tiddlywiki. It involves multiple users, over time, what I call serial editing. Tiddlywiki is deployed on SharePoint as an aspx file and only the checked out user can save back to sharepoint. All users can access the wiki, only one can save (at this point), they check it back in and another user can check it out. Keep in mind however users may think they can save the wiki with browser or local storage keeping their changes.

I have being commissioned to allow all staff to access the wiki and update their personal records. Of course we do not want every staff member to make a serial checkout so I am developing a solution on top of this single file model to allow read only interaction with the wiki to be saved in local storage, then exported and emailed to the owner from which the changes can be merged. This works for my use case because many staff do this review only occasionally. Basically the multi-user management is taking place logically rather than physically. (This could be automated somewhat at a logical design level) to support his I made this question/suggestion which has no replies User+ based namespace mapped to simple tiddlernames

The ONLY physical multiuser (update) method I am aware of is Bob or Bobexe. It provides multi-access such that the same wiki can be open in multiple windows/tabs and the contention is handled on a per tiddler basis. You can't edit a tiddler edited by somewhere/someone else. This multi-access can effectively provide multi-user however there is no logical user management process on top of this, but it is easily built. 

Bob needs a node server accessible by users so could be accessed by team members who can VPN into it. There is still more design work to manage a multi-user management and features on top of bob but they are all at the designer/logical level.

Theoretically you may be able to host a node or bob implementation on AZURE compute, not sure how hard it would be to introduce authentication that way.

Regards
Tony

Ste Wilson

unread,
Jan 5, 2020, 5:46:59 AM1/5/20
to TiddlyWiki
Noteself did multi user with couchdb.

Jeremy Ruston

unread,
Jan 5, 2020, 6:07:59 AM1/5/20
to tiddl...@googlegroups.com
Hi Stobot

As Mark mentioned, for the last couple of years I’ve been offering an online multiuser TiddlyWiki hosting service called Xememex as part of my commercial services through https://federatial.com/. Most of what I do is bespoke software development to adapt TW5 to the specific needs of a business but the hosting service was necessary to be able to address the use cases that customers were willing to pay me for.

Xememex is very simple: tiddlers are stored as individual files in S3 buckets. There is a series of Lambda functions that splice those tiddlers into static TW5 HTML files, and an API to enable those wikis to load and save individual tiddlers to S3. Authentication is via Amazon Cognito. There are also Lambda functions to run TW5 within AWS as a static site generator (e.g. Federatial’s site is a automatically generated static rendering of the wiki at https://xememex.com/federatial/).

The end result is a robust, multiuser implementation of TiddlyWiki, with the storage semantics of TiddlySpace (ie content is stored in bags, which are combined into recipes, and spaces which contain automatically generated renderings of recipes).

The largest public instance of Xememex is https://manuals.annafreud.org/ which currently has just shy of a thousand users. The largest private instance of Xememex is for a US law firm and has just over 100 users.

Xememex is designed to cope with large wikis — the US law firm is using a wiki of almost 100MB with tens of thousands of tiddlers. Their preferred tradeoff is to accept 10 second loading times in exchange for instantaneous operation once the wiki is loaded.

Feel free to drop me a line privately to discuss if you’re interested.

I should also note that I share Tony’s interest in adapting TW5 to be able to use SharePoint as a generic backend, with the promise of massively reducing the friction for internal corporate deployments of TW5.

Best wishes

Jeremy



--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bcc2f3b2-c8b1-43ca-98dc-324691a51c98%40googlegroups.com.

Stobot

unread,
Jan 5, 2020, 10:21:46 AM1/5/20
to TiddlyWiki
Thank you all for your input!

Mark S. - I agree, it is amazing that I have a mostly-working solution already. That's why (in addition to the 100+ hours I've put into it) it's so hard to abandon it at this point. Preventing collisions is going to be hard just due to the nature of what I'm trying to accomplish, and with my non-technical audience and corporate windows environment, the node.js install is problematic. I do have some budget for the project, but as I'm not looking at rolling out something to the whole company, just my 40 users or so, I doubt it'd be cost-effective. I appreciate your input though.

TonyM - I remember that you were living in a SharePoint / Windows world at least partly, so was hoping to hear you chime in as there seem to be few of us. I hear what you're saying on how you're implementing on SharePoint, and for many wikis that I'm doing where it's a small number of authors, many audience users, that is working well - I agree. For my current need in particular though, I'm trying to do things like have my team all in a room and doing voting on options - in which BOB works great, but is mass-simultaneous editing, so outside the scope of what a non-BOB implementation can handle. I agree that a BOB that had an Azure back-end or something sounds like a great next step, but well beyond my capabilities at current. Thanks,

Ste Wilson - I just spent a few hours getting NoteSelf up and running, though got stuck as soon as I tried to get on it with my phone for some reason. Do you have any knowledge of whether all users are updated when anyone edits it like BOB would? If not, I don't think that would work for my particular situation. It's very cool though.

Jeremy - That sounds very interesting, but as I mentioned to Mark S. I doubt there's an ROI (don't think I could afford you) given the *scale* I'm currently aiming at, but for a future project such as a whole corporate wiki, I'll keep that in mind, and frankly I'd love a business reason to financially support you and the future of TiddlyWiki. I think the SharePoint angle would be a huge market as the built-in wiki option is absolutely terrible. If further progress is made in this area, people like TonyM and me would love to see it. Let me know if I can help towards this end.
Reply all
Reply to author
Forward
0 new messages