Hmm. Javascript has encryption abilities. So there could be a macro for encoding / decoding tiddler content. I know Danielo had a per-tiddler encryption tool, but don’t recall if it allowed more than one password for the entire page.
At the top a student would enter their password.
Students would see a list of topics and click on a button for each topic that would decode the text into a temporary tiddler and then either transclude it or link to it. This way you could share info without having to worry about students seeing other student info. Unless of course they hack the 54 bit security. In which they are in the wrong class.
First question: Is it true that TiddlyWiki is not multi user capable?
Look at a product’s DNA. If multi-user collaboration is the top requirement, multi-user is not in TiddlyWiki’s DNA.
So consider something that has multi-user collaboration in its DNA.
IF TiddlyWiki filtering and/or transclusion and/or some other TiddlyWiki feature is the top requirement (I have a hard time making do without TiddlyWiki features that are part of TiddlyWiki’s DNA), and if you are inclined to, and have the time for, fiddling/hacking/caring’n-feeding add-on’s for multiuser, then stick with TiddlyWiki.
Multi-user does not seem like a trivial affair. (If it is a trivial affair, it is pee-poorly documented. In this very thread of discussion, all suggestions for multi-user TiddlyWiki kind of make my argument for Notion, but only if you can live without TiddlyWiki features that don’t exist in Notion.)
Pick the solution that involves the least pain considering all things in your world.
Second question: If it’s true, what are your recommended (and also not-recommended) alternatives?
I stand by the recommendation of Notion if multi-user collaboration is the top requirement.
Even if only for temporay use to flesh out requirements. (You learn what you need by rolling up your sleeves and collaborating on real-world stuff.)
Seems to me there is a fee for more than just a handful of users involved in collaborating via Notion (you’ll have to look into that). That may be a huge negative. If so, then I’d suggest an ecosystem of intertwingled Google things (Docs, Sheets, Sites, Calendar, Keep, etc.) which can be really smooth as silk if properly setup.
That implementation uses Amazon serverless primitives, and is not completely open source.
I know of at least one company that runs an off-the-shelf TiddlyWiki Node.js server behind a proxy as their intranet knowledge management system.
There’s no doubt getting TiddlyWiki up and running will be much more involved than getting started with commercial products like Notion and Roam, but it doesn’t require much maintenance once you’ve found an approach that fits with your existing infrastructure.
What would it take for us all, as a grassroots open-source community, to beg, borrow, steal, or honestly develop a solution structured more or less like that one? (I don’t have deep pockets, but I’d pitch in my share!)
I’d also be interested in an intranet multi-user solution if the connection to SSO were simple enough to hand a clear package of installables over to my university IT folks without myself being an IT folk. Still, the most amazing goal would be a system that works easily over the web.
Here’s another suggestion for live collaboration : visual studio code. You can use the plugin Visual Studio Live Share to enable realtime collaboration, and use another plugin to add wiki-like features to visual studio ( WikiLens seems promising). You dont even need to install visual studio code, you can use it online : https://vscode.dev
Other interesting solutions :
Features - CodiMD : real-time, multi-platform collaborative markdown note editor
Yes, yes. Very. I looked at it about a year ago. I think it is an amazing meld of developer (@jeremyruston) input + clients who are very good at their jobs.
One literal barrier is that right now, the backend used for Anna Freud is not open source. I did intend to make Xememex open source but didn’t do it at the beginning and so it has become a big job to get everything into shape so that others can use it. But it something that I have always intended to do.
The actual AWS running costs for Anna Freud is a few hundred dollars per month, which is relatively high. I architected the system for flexibility rather than the lowest possible cost profile, and I’m pretty sure the costs could be much lower if required.
I’m not sure how far a community run hosting service could get. It’s not something that I have seen done by other open source communities. The key issue is that providing free hosting for material created by other people can be a hazardous business: hosting services have to deal with legal and regulatory issues like spam, malware, and DMCA takedowns. Making a service subscription only mitigates the problem because paying customers are not incentivised to do the bad stuff. Then once one has paying customers they have a right to expect a commercial level of service, which I suspect pushes the centre of gravity towards running it as a commercial operation.
But the fact remains that the technical components are in place. It’s kind of a business problem to figure out how to effectively deploy that capability in a way that is sustainable and meets the needs of the community.
As a Tiddlywiki super user (not a coder) and an IT professional with some professional security expirence I have spent sometime looking into Tiddlywiki for teams. Bob is already appropriate for fully trusted teams if it continued recieving updates at least. More people should fund Jeds efforts to support bob as I do myself a little.
Bob is Suitable on the LAN or via VPN, I would leave it to others to comment on internet facing security.
Although a user managment layer would be good, this can be built using existing tiddlywiki features as long as you trust your users to some extent. I have researched this extencivly and done a proof of concept for most of the needed components.
I also have a proof of concept for multiuser single file wikis using serial editing. Ie check in and check out.
Some limited private content on a shared wiki is possible, although larger volumes of private content may be better retained outside the core wiki. There are some smart ways to do this which I will not detail here.
Like all solutions we always need to start with realistic business requirements even more so with security needs. There is quite a big range between a simple user selection and a very secure environment and the needs drive the solution. It is my informed view, that especialy with already trusted teams, we already have the capacity to address a large percentage of the possible senarios. If you start undertaking a review of requirements for a team solution you quickly discover there is a vast range of details and circumstances, degrees of risk and comfort with different requirements.
There is already a large number of internet facing secure solutions depending on the requirements, but not multiuser high security.
I am confident we can already address a large number of the multiuser and security issues to deliver practical solutions. For me however I do not want to work on this on my own and I must find an income.
If you have a genuine interest in collaboration or the capacity to fund such an activity please contact me privatly.
Mark, Good point. My solution is a “lazy” one, in that I could make a single announcement: Your url hashtag is your initials (except for a pair of students who needed a disambiguating middle initial), and tossing initials into a list field was easy to remember and easy to troubleshoot. Assigning passwords and setting up encryption for each student was more administrative overhead than what I wanted for a large class. But, as your note, tiddlywiki does indeed have great encryption tools, so a multi-audience tiddlywiki could serve up grading info along with other student-specific tips.
Hello @joshuafontany ,
sorry for loosing your job. We should have a sort of Patreon-system in TW for such cases because the work you intended to do with y.js sounds really inspiring. Realtime-cooperation is really something that TW lacks.
Hi all, newcomer to TiddlyWiki. Love this discussion so far! What if we relax the requirements for a multi-user system based on TiddlyWiki? I am looking for this limited setup:
Open Access to the wiki, no support for private posts.
<20 total “users”.
No need for the concept of a user but rather a creator, ie have a special tag for who created a post but all can edit/access all posts.
Ability for read-only access simultaneous from several machines but a single post can be edited only by one author at the same time (some locking mechanism maybe?).
Can this be achieved by storing the wiki on a shared database in the cloud and have some sort of locking when a post is edited or maybe use optimistic concurrency?
Using github actions, I can think of another way, that doesn’t involve “next generation” or non-available tools. It’s similar to twederation, but depends on generic technologies.
There is one central github page. Everyone in the group loads that page. But they use their own repository to save back to. The action script periodically grabs each user’s page, and extracts the tiddlers. Each person in the group has a designated tiddler prefix. So “John” might title his tiddlers “John/Discussion re multi-user alternative”, and “Susan” would title hers “Susan/Discussion re multi-user alternative” The script would only pull “Susan” tiddlers from Susan, and “John/” tiddlers from John. So no one could write over anyone else’s work or pretend to be someone else. Then the script would compile a new master.
From the user’s standpoint, once it is set up, all they do is take notes and save them (remember, you can save to a repository that may be different from that of the page you are viewing). Periodically they will reload to get the latest changes from others. Only their notes prefixed by their names (e.g. John, Susan) will get picked up. Threads could be created by stripping off the prefix and using the following portions as thread titles sorted by modification times.
Mark. I was thinking somthing very similar but giving the owner of the shared wiki the option to review “shared tiddlers” at import. As long as we provide nice guidence or workflow to the consolidation process even like editorial control I think it has some interesting possibilities.
I have also thought about
not importing some tiddlers for the user to have private tiddlers.
allowing an edit request for a shared or user tiddler
