Hi everyone,
It would be great if you could bring me all your feature requests, wish lists, and ideas over at Feature Requests Wanted! · TiddlyWiki/MultiWikiServer · Discussion #120 · GitHub
or do it in this thread, either one works. And if someone else posts a feature that you also want, please upvote it.
It can be literally anything as long as it is somehow even remotely related to a use case related to TiddlyWiki. 
Thanks,
Arlen
I want this.
Hi @Arlen22 - Here’s my wish list - tried to put a mix of things together.
A way to use it at work
I’m unable to use it on my main machine (work) - Windows Corporate Laptop without admin privileges. No Node, Bash, Git, …Something like either BOB.exe had (executable version), TiddlyWiki App (electron), TidGi, etc.
A way to access it when away from desk on my iPhone
I remain hopeful that some combination of MWS, Tiddlyhost, and Jeremy’s iPhone app will all bring this together someday. Until then, I don’t have access to enough technology to make this all work together like my competing software.
Easy way to delete bags?
This might be available now, but I remember when testing on a personal machine that I created a bunch of bags to test how it all worked, and then couldn’t figure out how to delete them. This drove me a bit nuts, I’m not even sure if I could rename them? I might be mis-remembering.
Somehow make large imports better
This isn’t directed at MWS specifically, but my main wiki has about 100K tiddlers in it. Some are “packaged” using plugins which makes import/export much easier, but my main note tiddlers (~ 25,000) need to be “normal” tiddlers and importing them means breaking into blocks of ~1,000 at a time. Given that I have a plugin with ~45,000 tiddlers in it works extremely easily, I suspect it has a lot to do with the import mechanism UI having to SHOW all the tiddlers on both sides. I would love an additional “blind” utility to filter-to-export and import large json files full of tiddlers in bulk.
Have you considered making a MWS publicly reachable to the internet?
I think this would solve your two first requested features (it did it for me).
My wishlist, sorted by importance:
A public roadmap that shows priority and tells which features are going to be developed first, (my intuition is that this discussion is the first step to build that).
Oauth as mentioned by @Scott_Sauyet. It would be great that once someone logs in with a google account, a user and a private bag were automatically created on MWS.
Allow MWS to act as a Sync Server, similar to what TiddlyPWA achieved, I find it really useful to have the option to work on your wikis even without internet.
From the Planned Features, my favourite two are the possibility to upload gygabite files, and instantaneous sync of changes.
This integration is definitely on my wishlist too, since it would allow some serious use cases:
Best,
I spend more time here these days than on GH discussions, so mine is here. I will spend some time thinking of others, but my first request is crystal clear in my mind:
Auth: I would love it if MWS could allow instances to pair with OAuth providers to handle logging in. Ideally, it would then also allow different views (in my case edit vs read-only, but possibly more sophisticated) to logged-in and other users.
I think any conforming OAuth2 provider would be fine, but perhaps we might need to restrict to those providing OpenIdConnect implementations, such as Apple, Facebook, GitLab, Google, Microsoft, Okta, and such. But if we just need OAuth2, there are many more options, including Amazon, Discord, Dropbox, GitHub, StackExchange, Wordpress, and so on. (Wikipedia List.)
I can’t say I’ve had the pleasure of trying out the MultiWikiServer plugin yet, but if possible, a prebuilt demo download would be nice.
Also, I have added the tag “MultiWiki” to the post, as I initially thought this was a post for any feature requests haha
I admit that I don’t even know enough to understand the landscape of technical thresholds here.
BUT: If users could gain managed-role editing privileges via university SSO authentication systems (such as for LMS or other portal/gateway institutional systems… Active Directory?) that’s THE HOLY GRAIL from my point of view.
If university students and faculty — who aren’t themselves running node.js or doing any other server-side geekery — can experience interacting with a TiddlyWiki collaborative project… that would change everything.
I really believe all my students would come out of my courses thinking not just “That professor curates a cool complex website” but “I need that tool!”.
That’s a somewhat different, but complementary, use.
What I described (in a language I’m sure Arlen understands, but probably should not have used in this forum without more description) is the way many websites let you “log in with Google/Facebook/Github/XXXTwitterXXX/etc.” The application doesn’t know anything about passwords, biometric scanning, etc., but offloads that work to a third-party provider. That provider verifies the user’s identity, and passes back some set of credentials, such as, perhaps, full name, email address, and the site-specific user id.
Integrating with your school’s identity provider would probably handle more than just user authentication; it probably also comes equipped with authorization, allowing you to assign both Emily and Tony to the course Metaphilosopy: Swallowing our own Tail, allowing Emily but not Tony to see the course work and grades for user id 1234567 and the reverse for user id 9876543. While a sophisticated use of the Oauth tool I was looking at could do something similar if it maintains its own list of permissions for users by supplier and id, that’s much more sophisticated then I was looking for, although, depending on the backend model of MWS, it might not be too hard.
I have no idea if this is possible, and my uninformed assumption is that it’s not possible, but I have quite long passwords to my single HTML file encrypted wikis and it feels very clumsy to type them often with one finger on the (Android) smartphones. If I can unlock the smartphone with the fingerprint, I would be very happy if it was possible to unlock the encrypted (with different passwords) wikis with just the fingerprint as well?
Ah yes, I wasn’t assuming that you were talking about the same thing, but it’s related enough to light me up with delight at the thought that TiddlyWiki might someday meet this challenge.
Actually, on a related note, I wonder whether there’s any chance that TiddlyHost might be able to integrate with google or other web-wide OAuth standards.
Then (again thinking big) if @simon could somehow enable a MultiWikiServer in TiddlyHost’s backend, sharing read/write privileges could become as straightforward as it now is with google docs and such…
Easy to say, but surely not easy to do!
I think this could be usefull
For what, should it be used?
i haven’t really tried it, because i did not want to deal with node and git. I don’t want to be tied to a computer or server in order to work.
Tag dropdown list items to be listed alphanumerically. Pretty much all lists in TiddlyWiki to be alphanumeric by default.
Is this specific to multiwiki? (I think this was the point of the thread, even though the title doesn’t include that detail.)
On your actual idea: Surely we wouldn’t want to make tag dropdowns always list alphanumerically, since order of items listed under a tag can itself be very important (for any cascade tag, or $:/tags/ViewTemplate etc.)… But perhaps this would be a setting that could be toggled on a per-tag or filter-condition basis? I could work up a demo of that, if you’re curious…
also a pre setup Docker image or compose. would make it easier to self-host on Coolify, which is my personal go-to as a self-hosting noob.
Thanks for that clarification. That should have been expressed more clearly in the OP. The title and everything but the link in the OP does not specify that. It even says “it can be literally anything as long as it is even remotely related to a use case related to TiddlyWiki.”
Thank you everyone for your thoughts. Yes, this was a request for MWS features. I should have made that more clear.
Also, I think the following is my opening thoughts on the subject, not my final verdict, so please feel free to respond with your perspective as you see fit.
There’s good news and bad news. The bad news is that third-party auth is complicated and normally tied to domain names. The good news is that part of my design philosophy is to make auth completely external to MWS.
In practice, this means you would install it as an NPM dependency and then setup your own auth handlers around it with all of the server keys and third-party connections for your specific use case. In my current line of work, every auth solution I implement is wildly different based on the specific use cases and requirements, and it’s always a pain to setup. There are entire companies dedicated to JUST auth!
I work on a few JavaScript projects very similar to MWS, and I have yet to find a good turn-key solution to auth that doesn’t require absolute tons of configuration AND is also verifiably secure AND is obviously the best solution, but if I ever do, I might bring some form of that into MWS. Better Auth (the successor to Auth.js) is an option I’m keeping an eye on.
But implementing auth that is BOTH usable AND secure is challenging. With the advent of passkeys we may finally have something that could work with the default MWS use-case by scanning a QR code in the console.
So I am more than happy to work with anyone wanting to do this to make sure MWS is as extensible as possible, but I don’t know how I could even begin to directly support third-party authentication in all it’s various flavors.
Along with that, any JavaScript developers who want to setup MWS as a dependency, feel free to open an issue on GitHub about that.
This is another subject with a huge amount of variation and deep implementation details and caveats. It’s not as easy to accomplish as you’d think, especially in TiddlyWiki where the client isn’t just a rendered page, but contains the entire wiki, but that doesn’t mean it’s not possible.
Unlike auth, this is something I think belongs in MWS. But I’m not exactly sure how to do it. The server side is very simple, so there should be no problem there. Most of the work that needs to be done is in the browser, so we could borrow the work of existing TiddlyWiki plugins that already do this well. Any recommendations along this line are appreciated.
As in literally. I can’t think my way through all the caveats and edge cases this brings up. I’d be happy to work with someone else on this, but compromises have to be made for offline support, and I don’t know how to do that.
The best I can probably do is some kind of read-only offline caching or a PWA that installs as a home screen app and keeps a copy of all your wikis cached and up to date. This would require some server-side integration and I’m quite happy to make sure that happens.
There could also be a way of creating an offline cache of tiddlers that is presented as an import when you come back online and allows you to diff and merge tiddlers that changed while you were offline.
A few people have requested being able to import huge wikis. This is already implemented in MWS. Just drag and drop anything into an existing wiki, and all tiddlers are saved at one time, instead of slowly over hours.
The existing TiddlyWiki syncer only saves one tiddler at a time, and there is no way for sync adapters to change this. There is currently a PR open with an improved syncer which does allow sync-adaptors to support saving many tiddlers at one time. If you write sync adapters, please take a look at that PR and let us know if that works for you.
There are various requests for running various portable installs of MWS. I’m open to these but not well-versed in all the user-land requirements there. I’ll have to take a closer look at that at some point. PRs are always welcome.
Jeremy put me in charge of MWS mainly because of an extensive rewrite I proposed to the first version of MWS, which at the time was in a branch in the TiddlyWiki repo. The rewrite became the basis for the MWS repo, and a couple more rewrites followed, most notably separating the server and application layers of MWS. I’m in charge of the core architecture, first and foremost. Since this is a side-project for me, and definitely not my full time job, I have to let other people help with implementing various feature requests.
The twist is that I’m actually using the core server layers of MWS in my existing work projects as an alternative to Express, exactly the same way the mws layer uses it, which helps me work on the extensibility and core server features.
This also allows me to copy project ideas, like the client build system, between MWS and my existing projects.
And yes, these projects do use auth. And that experience informs most of what I said on the subject.
I’m trying to work on a rewrite for the frontend of MWS that incorporates a lot of the suggestions around bags and recipes. I’m still not exactly sure how to do that but I’ve been coming up with some ideas.
Jeremy and I share a slight aversion to React, despite recognizing its prevalence and ease-of-use, and I’ve been working on a way to use JSX with web components completely outside the React framework. The basic framework has been slowly coming together and at some point I’ll be porting that into MWS as well. There’s already a branch with one attempt.
So basically, I’m very actively focused on the core architecture of MWS. I don’t have time to implement all the features as my involvement isn’t being funded in any way, but I want MWS – both the server layer and the application layer – to be a solid foundation that anyone can easily build on or contribute to.
Deleting and renaming bags will be available eventually.