My setup is basically: 1. TiddlyServer is basically an expansion of the NodeJS TiddlyWiki Server. It's designed like a static file server such as apache, but adds features for TiddlyWiki, such as saving single-files, and loading data folders in place, so you can have multiple data folders running on the same server instance with different paths. Back then the TiddlyWiki server didn't have any way to upload external files from the browser. If it had, I probably would never have written TiddlyServer, but I use it all the time now. 2. My main wikis are stored in Dropbox so I just reference their folder inside the Dropbox folder, and Dropbox automatically saves changes immediately. I've heard there is some kind of versioning as well in the Pro version, which I have. 3. Dropbox takes care of this for folder wikis, and TiddlyServer can also be configured to save a backup of all single-file wikis on every save. 4. Browsers are browsers, some are just more sandboxed than others, which is part of the reason I made TiddlyServer -- so I didn't have to make sure all devices could use file:// urls, which was always a pain. 5. Everything is central. 6. I used NoteSelf for this for a while, but eventually I dropped that and just used Dropbox.
I really like the TiddlyWiki concept and it's a lot easier than installing MediaWiki on my computer, which is what I had done before. I'm still working out a few problems with mobile access and the like and also trying to come up with a more usable layout for regular notes. Something like Google Keep, maybe. So that's my setup. On Sat, Nov 23, 2019 at 8:57 AM Miha Lunar <mlu...@gmail.com> wrote: > Hi there! > > I've only skimmed previous posts so forgive me if this came up already, > but I wanted to throw in my 2c. > > Most of this is from the context of accessing TW from more than one > device. Before I can talk about why having TW support PWA features would be > a good idea, I want to give some background. > > The ideal setup for me personally looks like this: > > 1. Central server running TW and acting as the source of truth and storage > of all my tiddlers. > 2. The tiddlers are versioned for easier maintenance and fewer worries > around deleting or changing things. > 3. The tiddlers are regularly backed up to protect against hardware > failure and malware / accidental deletion. > 4. I can access TW from any device via a browser or other more appropriate > means. > 5. The local TW running on device is connected to the central server so > that the tiddlers are shared between devices and not siloed. > 6. The device-local TW can run offline, which means that there needs to be > local storage that gets synced with the server once the device comes back > online. > > With these I could really use TW anywhere robustly and reliably. > > I have a large part of it figured out, but there are still some system and > UX level gaps. I will describe what my current setup and possible > implementations can be for each of the points above: > > 1. Central server. I have the vanilla TW nodejs running in a Docker > container on my Synology server and so far it seems great. The vanilla > server saves tiddlers as files already, so I just mount that save dir as a > volume, so tiddlers persist outside of Docker on the host. > 2. Versioning. Based on a blog post I found, my tiddler files are part of > a git repository. To commit I'm running a modified gitwatch that looks for > changes to tiddler files and commits automatically after a few seconds. > History in git is stored as deltas and compressed, so the history might > take _less_ space than the working copy at the beginning at least. > Reverting / looking at history is a little inconvenient as it's not > integrated into TW, but that can be improved with a plugin and a > server-side service. > 3. Backup. Since tiddlers are saved as files on the server host and I'm > running nightly backup on it, this comes by default. Any backup service > that works on the filesystem level would work here however. > 4. Device access. This already seems to work pretty well on desktop and > mobile. The UI is pretty responsive and works well on small screens for > most things. > 5. Central tiddlers. This also works pretty well. The vanilla nodejs > server has a REST API and the TW client that it serves connects to it and > uses it as the default saver. So all the data is persisted on the server > and not locally. > 6. Offline mode. I don't have a solution that I really like for this yet. > There are some attempts to do this, most notable seems NoteSelf. It syncs > to a CouchDB database however and for now I prefer having tiddlers stored > as files, due to the advantages that brings for points 1., 2. and 3. > > > Expanding on 6. Offline mode: > > I believe this is the only context where PWAs make sense. If the app is > already offline (served from the local file system, saving via browser > plugin, or running offline as a native app), then the concept of a PWA > doesn't make sense, since afaik the core problem they solve is offline mode. > > In the context of an online TW (like described in the setup above), it > would make sense for it to support PWA features (localStorage, offline > service worker responsible for sync, etc.). This way you could open up a > website hosting your TW at any point, even when you're offline and it would > store all the changes in the browser cache, then sync them up when you > connect back to the central server. > > This would solve 6. without having to create a separate application for > each OS just to handle the offline, caching and syncing problem. In Chrome > you can even install these kinds of websites as system apps, so they open > up in their own window and act like native apps to a certain degree, on > both desktop and Android. For example, the Home Assistant client does this > and it works great. > > I believe a proper syncing / diffing system is the only big roadblock that > currently stands in the way of having true offline mode and sync. I know > there is some effort being put into the diffing part (there's a macro for > diffing tiddlers), though I'm not sure how far TW currently goes wrt sync > with the nodejs REST API. > > Obviously expecting everyone to run the same setup as I am is > unreasonable, especially if you just want to try it out or if you don't > want to manage servers and so forth. If you use more than 1 device > regularly though, I would think you'd want some form of syncing between > them and that's why 6. would be beneficial, even if you connect to the > cloud, where someone else runs a variation on 1., 2., 3. for you. > > I'd be interested if anyone has a better solution for any of the parts of > this system or a better one entirely. > > Best, > Miha > > On Saturday, November 23, 2019 at 2:50:37 PM UTC+1, Arlen Beiler wrote: >> >> I think the bob saver can be expanded to use a browser plugin. This can >> address some of the security concerns with having a freely available saver >> listening on the network. And it’s also simply installable as you say. I >> must have heard enough complaints about corporate networks that I thought >> those environments have all the trouble, but maybe I was wrong. I guess >> putting a simple working solution in place first and then improving it >> would get us a long way. >> >> On Sat, Nov 23, 2019 at 08:16 TiddlyTweeter <tiddly...@assays.tv> wrote: >> >>> Ciao Stefan >>> >>> *Great post. To the point.* >>> >>> Fully agree that the POINT in all this should be to enable users to do >>> TW with the same level of simplicity they have for other apps. >>> Basically, nowadays standard, it comes down to one approach for mobiles >>> and one approach for desktops. >>> >>> IMO we have, actually, MINOR, issues between now and full cross-platform >>> unity of approach. *So close. Yet so far off.* >>> >>> One thing, largely OVERLOOKED in this thread, with its (necessary) focus >>> on mechanisms, is that end-users are primarily interested in CONTENT. >>> They don't care HOW they get it, just so long it's simple enough. I wish >>> "Desire for Content Delivery" would matter more here as it is a vital piece >>> of understanding the issue ... >>> >>> I really believe that normal end user working practice is central to >>> this discussion. The issue is, I think, just this ... >>> >>> - ... a person who wants to get something done, using conventional, >>> recognisable, common, methods. >>> >>> My 2 cents. >>> >>> Best wishes >>> TT >>> >>> >>> *(Footnote: Unfortunately TiddlyDesktop is not properly portable yet [it >>> currently uses absolute addressing to wikis] so its not yet ideal.)* >>> Stefan Pfister wrote: >>>> >>>> Hi, >>>> >>>> # The Goal and big question: >>>> >>>> * a simple way for naive and casual users to save their tiddlywiki >>>> (again and again)* >>>> >>>> >>>> I read this thread with much interest. In my opinium there is still one >>>> big aspect, which should be mainly considered. As a casual and >>>> non-technical user of tiddlywiki and as a teacher, who wants to show the >>>> students at school something with tiddlywiki I want to say: >>>> >>>> The easiest way to use a tiddlywiki is to double-click on a file with a >>>> tiddlywiki in it. I doesn't matter which ending this file has. If it is >>>> "html", "tw" or something different. If the user can simply click on it and >>>> it opens in a way which makes it possible to use it without struggling with >>>> the saving mechanism. >>>> >>>> This works with the so called hta-hack under Windows really well. >>>> Simply changing the ending of the tw-file to "hta" and you have a simple >>>> working one-file-tiddlywiki with saving mechanism. This is really usable. >>>> For me as the user the inner mechanism is not my point of interest. I can >>>> simply us this in class but only with windows devices. Something more >>>> universal and platform independent would be great. >>>> >>>> A single TW-file with a working saving mechanism in it which opens per >>>> doubleclick in a browser or even in a separate portable program like >>>> TW-desktop (something which organises the saving) would be a great progress >>>> in usability for the non technical and casual user of tiddlywiki. This is >>>> the normal behavior of programs and files. The most simple users know this. >>>> This is an easy workflow. I use this kind of workflow every day. I simply >>>> don't want to install or configure something special in order to be able to >>>> save my work. But it is in most cases not much of a problem to install a >>>> app or a program in order to use it. I know there are restricted >>>> environments but for the normal user: The normal way to use a programm is >>>> to install something a *.exe or under linux a *.deb and simply use it. >>>> >>>> Just my two cents. >>>> >>>> Regards, >>>> >>>> Stefan >>>> >>>> >>>> >>>> -- >>> 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 tiddl...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com >>> <https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/60b58373-13e8-427a-b7c8-c50f5597b496%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/60b58373-13e8-427a-b7c8-c50f5597b496%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSSeL%2BAPmef9zdMReypqAPU7uF4z9c8oLZs_nTEtCVN1Lg%40mail.gmail.com.
