Unfortunately most of your post is way over my head, but I want to continue to offer encouragement and excitement around progress on multi-user. After using both the standard server functionality and many versions of BOB, I can submit a bit of user experience in those areas in case it’s helpful. What might be additionally helpful from your standpoint is a comparison to BOB, so that those of us that use BOB might understand the differences more clearly. (Note: I didn’t for this to be so long when I started
)
First, from your post a few comments in the order you discuss them:
Multi user
I don’t really understand most of what you discuss here, and am not familiar with Yjs in general, but from a practical/functional standpoint, a 3 tier system is what I tried to force BOB into:
- Admin (standard TiddlyWiki): What the main owner of the wiki can do - with password
- Member: Can use functionality like buttons etc. provided by the Admin/author, but can’t for instance edit a tiddler from a UI standpoint
- Guest: Read-only, can’t edit, and all buttons (and equivalent) are in disabled status
In BOB I try to accomplish this via wikitext alone which works fine since I’m the only one that understands TiddlyWiki. I have a hard-coded data-tiddler with usernames, passwords, and levels. This is obviously not secure at all, but good enough for team purposes. Admin is easy, Guest is relatively easy as it’s all just adding <$list> widgets around all of my buttons etc. Member is a bit tougher, and I end up having to hide the edit button globally, and then contiditionally show another one near the top for admins. Clunky, but it works.
Multi Wiki
This sounds mostly like BOB which works well. This is obviously a huge pain point in non-BOB, but the way BOB handles it is pretty great. Much easier than TiddlyServer by comparison.
Live Experience
I don’t understand much of your technical detail, but if this is like BOB, it’s magic and hugely useful. I know others here find that “serial editing” is good enough, and i’m sure it certainly has it’s use cases, but for me, the real-time nature of BOB is critical. Much of the use I have is to collect information from my team, often around scoring, ranking, and discussion. We will all co-edit in real time during meetings.
File Watcher
For me I’m constantly torn between the folder and file versions of TiddlyWiki. In general the folder versions have two main benefits: Quicker saving (per-tiddler vs. per-wiki) and integrations. I work in data analytics, and therefore have other processes as a result of batch files, Power Automate or other automations that now ingest information, and then translate / push into .tid files for BOB to injest. In this way it’s like a whole “connections” ecosystem that becomes available.
I don’t really understand much of the rest of that - Yjs / StoryList etc. so I can’t comment there.
Secondly, generally around the multi-user paint points generally: Bob is currently the best in all areas functionally so far, but here are my current concerns:
- BOB seems to be much worse at re-connecting without data loss. I work in an office where I’m about 50% at my desk (on ethernet), but 50% of the day I disconnect with may laptop and switch to wifi around the building, then come back and plug back in. In the normal server version I’ve yet to have a problem, but with BOB it’s fairly common that I’m getting the red messages and when I use the sync-back-up it outright crashes BOB completely, kicking everyone off. That’s pretty painful.
- I worry considerably about it being a non-core function and the risk that comes from that. Jed (I believe) is on hiatus, and he and the limited resources supporting it (including you) could abandon it at any time. While true of TiddlyWiki more generally, I worry much less about the core server version being abandoned.
Lastly, I’ve pre-emptively mentioned my willingness to sign on and continue supporting via open collective, though I do worry that the pool of people passionate about multi-user is smaller (which I continue to find surprising). I will say that if a product was out there robust enough, and with guaranteed support, people like me could support it via business expense, which would be a rich revenue stream if realized.