On Android, RCX (Rclone for Android) should let you mount Google Drive and serve it over WebDAV. RCX works really well for me on Android to serve local TW files over WebDAV.
2 Likes
I periodically follow the discussions on the forum and it seems to me that programmers and technically literate people do not quite understand the mass user. This window with the choice of saving methods is a huge barrier for non-technical people. Most people will not take the time to do this, turn around and leave without realizing what Tiddlywiki can give them.
TW needs one official save method for desktop and one for mobile. It should be intuitive without reading instructions, so intuitive that a child without English knowledge can understand and cope by watching a short video. All alternative saving methods should be removed away from the main page in a separate tiddler. Those who need it will go and study. Most ordinary users at the initial stage do not need this and only repel.
As for me, for the desktop, this way should be the add-on GitHub - buggyj/savetiddlers . True, it is not suitable for the mass user now either, because it is desirable that it be in the firefox and chrome application catalog and be installed in one click. It can also be completed so that it saves the wiki at a certain time interval on sites like tiddlyhost.
For mobile https://tiddlywiki.com/#Saving%20on%20Android . But it still doesn’t fit. There is no way to work with files yet (however, there is no normally intuitive way to work with files in the whole tiddlywiki, not only in mobile)
4 Likes
We are aware of this @moosh and you are not the first to say it, it is not however as easy as you would think. It really does depend on the device, platform, browser, operating system and user skills, because the browsers actively try to resist saving to local files because this can be a security hazard. That is why the checkboxes are provided to list possible save methods.
We want to change this but its a bit like trying to recommend a part for all vehicles in the world, there is not one answer. If you can help us find a way please do.
I personally use Timimi so that once installed I need not worry anymore, but this does not help some users that want to share on the internet (Tiddlyhost.com) or on an apache server (Tw-reciever), share on their local/wifi network (use Node or Bob), or access local files without security limitations (TiddlyDesktop) etc…
Many other solutions do not have this flexibility so users don’t get this flexibility, and less choice as a result.
It is a dilemma
2 Likes
It would be interesting to know if this works. Within apps, Google wants you to connect to Drive only by file streams. Part of their ongoing security-through-obfuscation approach.
Since you said “files” , I’m wondering if you have a way with RCX of serving more than one file from one directory. As far as I could tell, you can only serve up one directory. Not a show-stopper per se, but another complication to deal with.
Developers are well aware of the problem. However, there isn’t just one ideal approach. Your choice here illustrates that:
savetiddlers isn’t available through the Firefox or Chrome stores, and saves only to a sub-directory of the download directory. Timimi is available through the main extension stores, and allows you to save anywhere on your disk. So it’s the best choice for most people. But … it requires a small executable, which is a non-starter in some offices.
Each of the various savers has its own pluses and minuses. This complexity is the price you pay for having an open source product that runs exactly the same on 5 different platforms and multiple browsers. Commercial products, like Evernote™ or One Note™ get around this problem by having whole teams of developers that work to make a product look the same on multiple platforms. But that takes lots of money and it’s not actually the same product – each implementation is different in subtle ways (or not so subtle, per the complaints in the EN forums).
1 Like
The steps required to accomplish this are described in the wikipost for webdav options. Last time I tried it, which was about a year ago, it worked just fine.
By files I just mean the contents of a single directory. I think you could perhaps set up multiple webdav servers at different ports to serve multiple directories, but that just sounds very messy.
With Rclone I could do that. But I don’t see any way with RCX to run more than one server. It would be messy, but is unfortunately not always possible to put everything you need to serve under one directory.
All keep in mind that many of the cloud storage solutions offer a local device synchronisation services and the cloud files simply appear as local files. We can just change files localy and have them synced between our devices.
- You have to ensure the sync occurs before closing a device to have access elsewhere
- Contention is not addressed
There are some great solutions that allow more devices and going direct to the cloud file, but it is important to acknowledge this access to the raw files as synchronised with a cloud services sync client.
RCX has a “Union” option under remotes but I could not get it to merge two local directories as one remote. One approach would be to serve a common ancestor directory for the directories with your wikis. Technically you can even serve the root directory though that makes me quite uncomfortable and I would not recommend it.
You could also try creating symbolic links to other directories, though this might require root access on Android.
That is exactly the problem, since most (all?) Android browsers won’t let you set the download location. I guess you could use the root if you’re running as localhost. It’s unlikely there’s a lot of exploits built on the assumption that people are running a webdav server. Also, any apps that could use that could already access the same root, so … maybe that’s the ticket.
Lots of good technical discussion and point solutions, some of which I even understand, though still a TW-novice. However, pivoting back to Moosh’s comment above:
… it seems to me that programmers and technically literate people do not quite understand the mass user. This window with the choice of saving methods is a huge barrier for non-technical people. Most people will not take the time to do this, turn around and leave without realizing what Tiddlywiki can give them.
Altho I’m a newbie here, I’ve been a software developer for over 40 years, so I’m more technical than the typical mass user Moosh refers to. I’ve spent 15+ hours trying to understand the basics (Grok TiddlyWiki is a great resource) and making several false-starts at addressing the use-case I described up top.
What attracted me to TW was its open nature, flexibility, and extensibility. But I need something now and it’s still unclear how much more time I’d need to invest to learn and assemble the components to address the synch and save needs I mentioned up top.
My current needs can be met by tools like Notion. As folks on this forum probably know, Notion synchronization uses the, “Keep it online in a single place and manage the use via different devices” model noted by TW_Tones. It’s simple and, “just works”. This is akin to Tiddlyhost, if not for the fact that it reverts the autosave flag.
For “mass users”, is there an approach here that would satisfy the 80-20 rule? Maybe…
- Tiddlyhost, enhanced to address the server-load concern. Perhaps via the autosave enhancement mentioned by simon?
- Providing articles/videos to address those use-cases that are common/easy?
- Others?
Of note is the recent development of a clone button that can be set on tiddlyhost and along with a little support info this may be the most rapid adoption path for many.
1 Like
Have you tried roam research, obsidian’s software?
Personally I DAV specifically my server’s Apache is configured to DAV on a directory and require (HTTP) authentication when a request does not come from my home IPv4/6 address(es).
I am also careful to close my TW tabs when finished and never open a second by accident.
With this discipline which admittedly does go wrong occasionally I can use any device or sit down at any random computer such as at the museum where I volunteer, or mobile device and use my TW.
I also have some crontab shell scrawl that with a throw of the dice may create a day-named backups of my TWs. So I have a sprinkling of backups that go back a few weeks.
I completely agree a less technical setup that saves tiddlers not whole files and covers what most people want including Android and iOS would be nice but don’t know how.
Maybe this subject needs a dedicated brainstorming meeting.
This is a great practice, if you can manage!
The phrases “when finished” (Do other people know when they’re finished with things? 
) and “never open a second by accident” remind me that we don’t all live in the same universe 
. Distractions and interruptions – plus the occasional “Let me load this in a second window to make sure the plugin/theme/css-hack behaves as expected, before I close this one” moment – can combine to make these ideals aspirational, rather than reliable.
In case anyone else runs Tiddlyhost in browser tabs that can get lost among other windows, I find it helpful to pin the Tiddlyhost account console as first tab in a window, and keep all my active TiddlyWiki sessions within that set of tabs. Then after using Chrome’s “Name Window…” command to name that window (something like ———tiddly, which stands out visually even in a long list), I can use a keyboard shortcut to access that named window. So I’m no longer scanning for my TW tabs like needles in a haystack after work sends me on a wild internet chase. 
All this is a bit of a digression from OP, but my strong vote is for something like tiddlyhost to be the default for new users, with all other save options being for those already sold on the power of the code, and interested in other solutions.
Perhaps tiddlyhost would need help to scale for this – and/or should offer free hosting only for a limited amount of time and/or within a limited storage ceiling. This would still be a much better deal than most “freemium” software.
-Springer
To reduce the likelyhood of overwritting the same wiki from a second tab and browser I have done a fair bit of research. It is hard to document a complete solution but hope I will in time. At least to avoid two tabs of the same wiki its worth opening a wiki in a named tab, follow a link using a target parameter. This sets the window name. You can use javascript to do this as well.
If you pin a named tab it retains its window name.
What I have found is the target/windowname can be set to the wikis domain or filename, then you can construct the target parameter from any link. So via this method if you open another link to the same wiki it will to open it in the same tab. If the target tab has unsaved changes you are warned.
I have also discovered how to capture the browser brand and access a cookie with a device name that once combined with a username allows a unique checkout amonst various tab / browser / device / user combinations.
Virtually every other modern webapp handles saving and syncing between devices with little to no issue, zero user set-up, and zero user input.
Tiddlywiki’s philosophy is not really special in any way that should prevent this from being the case for it too.
1 Like
Tiddlywiki dosen’t have a back-end, other modern web apps are run on remote servers that handle the syncing and saving.
The bit of Tiddlywiki’s philosophy that makes this not like other web apps is that it is running as a single html file in your browser so that you own and control it, there isn’t someone elses server to do the heavy lifting required to have the zero-setup saving and syncing between different devices.
1 Like
This argument really isn’t very convincing to me.
Own and control what exactly? The data? The specific instance of the app on my device?
Many apps have encryption to protect your data, have the ability to create txt or md backups, even automatically, so one owns their data.
Many apps are open-source and can demonstrate that the instance of the app on your device is fully under your control, and that this control can’t just be taken away.
I think what is happening is that the way in which the app was initially designed, which was at one time a reasonable means of tackling the issues in question here, is now being confused with the philosophy as to why it was designed that way. We now have better ways of handling these issues, than we used to. The philosophy of Tiddlywiki isn’t in question, but the best way of building an app that works with said philosophy, in 2023.
Convincing or not, it is a single html file. The way that tiddlywiki works means that it is completetly on your device, to make it so that it isn’t the case changes the nature of what it is in a pretty fundamental way.