Custom application for TiddlyWiki based on WebDAV

#1

A half baked idea to follow that I want to share before I forget:

I’ve always found it problematic to introduce people to TiddlyWiki because of the barrier to setting up saving. People either expect a software as a service model where the app and their data is hosted online, or the familiar paradigm of installing a local application and using it to create new “documents” etc that are saved on their computer.

TiddlyDesktop comes closest to offering this experience but has its fair share of weaknesses including not being able to use one’s regular browser, difficulty working with local files etc.

I am wondering if a similar but smoother experience could be offered with a custom WebDAV application. Looking at the code for widdler, it is ridiculously simple to create a WebDAV server in Go. Releasing precompiled cross platform binaries should not be difficult, so all you would need to do to get started with TiddlyWiki is download a single file and double click it. In fact Widdler already does a fair bit of what is needed.

One could add a GUI component to the application that when started, on first run asks you where to save your wikis. Then gives you a localhost link to click on that loads in your normal browser an admin wiki similar to what you see here, which lets you create new wikis etc. The user could set the application to start when the computer starts, and the wikis would always be available (and saveable) via a bookmarked location in their browser.

The onboarding would look something like this:

  • download the application and double click it
  • get prompted for a directory in which to save your file, maybe a port? with a sensible default filled in
  • get a link to click to open the admin wiki which is created for you, and a message to bookmark it for the future.
  • admin wiki lets you create new wikis, restore backups etc.

Still too convoluted for new users? I am not sure and it would be interesting to hear other opinions from those of you that have experience with using WebDAV with single file wikis.

6 Likes
WebDAV for saving single file wiki
#2

@saqimtiaz I have shyied away from introducing others to tiddlywiki so far for the same reasons, as has most of the community I think.

I have grasped the opportunity with recent WebDav solutions to play with something almost identical.

I would consider perhaps even in the same solution to have three variants, perhaps that are configured from the wiki.

  • Download and activate a single WebDav imbedded tiddlywiki edition, Basically a way of distributing specific editions.
  • A way to down load an empty tiddlywiki as a specific edition
  • One like you outlined with the additional wiki creation and indexes etc… This could just be a back stage of the earlier variants.
  • An option to configure the above webdav wikis to appear on the LAN (listen 0.0.0.0) without editing the yaml file directly.
    I think it important that
  • such a solution can be preloaded with a tiddlywiki, ideally the one found on the internet.
  • we make use of the fill local host address range eg; 127.0.33.n
  • Ideally if we can get webdav to load a named tiddlywiki eg index.html when the address is visited without a port number (an unnecessary complication for new users)

So for the first variant;

  • Download the application and place it in its desired location
  • Run it to extract files and build folders if not yet, then load it to run and present the IP address URL it can be found at (no port), click and it will open in the default browser displaying the imbedded tiddlywiki.
  • Optionally
    • Provide OS specific instructions to load at computer login.
    • Provide instructions to alter the IP address it appears at.

We could even obtain a random IP address 127.A.B.C

The subsequent variants would just have a specific tiddlywiki edition loaded instead. Ideally we find a way to imbed the tiddlywiki of choice in the distributable.

Perhaps a well documented github project we can fork, import the tiddlywiki as index.HTML and generate the OS packages. So it is an option the Index.html empowers additional wiki creation as per your example.

Did you ever play with twexe.exe? you could load your own wiki into that at the command line.

#3

Addendum: It would be interesting to explore git bindings as well to see if auto-versioning is possible, that is every PUT request to save a wiki creates a new git commit.

I recall using something similar with webdav via nginx and mercurial back in the TW Classic days and it was immensely useful.

#4

Applications that run in “user-space” can not use port 80. You will need to run your app as an exclusive system service, if you want to use port 80 or 433 for https://

If you try to establish something that way, all the simplicity of a user-space app is gone. …

BUT you will win on the security side of things, which I personally prefer over simple and insecure hacks

1 Like
#5

I was thinking in terms of a single (signed?) executable for each platform with a verifiable hash. Not a generic container for including different HTML files, which would be a security concern in terms of not knowing what you have downloaded or what the contents are.

#6

I’m not that familiar with TiddlyDesktop — any reason not to use it instead?

Many other Tools for Thought like LogSeq use Electron to make desktop apps. Electron is much more common than NW.js which TD uses.

I would think that the NodeJS version of TW wrapped in Electron would be a more straightforward path vs messing with WebDAV?

What do you think the benefits are of WebDAV in your proposed approach?

#7

I think there are several advantages

  • You can use any browser to work with the wiki
  • The server can be visible in the LAN
  • Go produces “native” apps for different OSes with a relatively small footprint
  • There can be a “custom workflow” that lowers the entry barrier
2 Likes
#8

Electron apps can also expose NodeJS ports for this.

I’m trying to understand the user here. Sure, “home tinkerer” is a persona, but not very common.

Also possible with Electron/NodeJS I think.

Yes Go is famous for portable executables. Balanced against Electron being built for this very purpose and having lots of tooling for this — eg built in update mechanisms.

I’ll check out TiddlyDesktop a bit and maybe even try bundling an Electron app. Electron is the “common path” that one sees in the wild today. I use LogSeq with it today and it’s an easy experience.

Issue with LogSeq and TW in this context is having access on mobile (outside the home).

#9

Oh, I did forget 1 thing:

  • It’s a single file wiki

For some users this is still “the reason” why they use TiddlyWiki at all.

1 Like
#10

Apologies, I’ve done a poor job of framing the conversation, and the technical details I included have led the conversation astray. That’s what I get for hastily putting out a rushed post for a half baked idea. I wanted to get it out there quickly though before it ends up yet another idea that I never get back to, which happens far too often.

What I was hoping for was to get feedback on this part, about a better onboarding experience for users who want to use single file TW locally:

I’ll reply at length and address the technical questions and other concerns when I get the opportunity, likely after the weekend. Thank you.

3 Likes
#11

I understood this, but if a mechaisium to preload such a distributable is available I think it would drive use and adoption of both tiddlywiki and this distributable mechaisium. The ability to simplify the install process that wraps a custom tiddlywiki (not empty) would be good for newbie’s to acquire actual solutions not just tiddlywiki, Eg Perhaps I make a decision making tool, installing locally with the minimum steps will ultimately attract new users, but the authors of such solutions will jump in and support your Custom application for TiddlyWiki based on WebDAV

I understand the security issue, but if someone wants a local application they need to seek it from a reliable source. It is more reliable if its a tiddlywiki inside an open source installer and local server, not a bespoke app.

1 Like
#12

A WebDAV based desktop application such as @saqimtiaz is suggesting is an interesting idea. It’s barely TiddlyWiki specific and so one would hope could be assembled from off the shelf components.

There are a lot of options here, and I think about them a lot. Some idea that rattle around my head:

  • Treating TiddlyDesktop as a custom browser ran out of steam quickly because it turned out to be impossible for us to provide all the features that users are familiar with from their own browsers. My original motivation for wanting a custom browser was so that we could wire up global keyboard shortcuts that bring up a window with a particular tiddler. I’ve never got as far as implementing it, I think because alt-tabbing to it is good enough. It’s second nature by now, and I can use it consistently to switch to any application.
  • There should be a core distribution of TW5 with Node.js packaged as a single executable
  • That TiddlyDesktop could be integrated into the main TW5 core as an optional UI that can be summoned under Node.js
  • If we switch to using a local HTTP server to enable users to use their preferred browser then the UI could even be a terminal mode UI (eg using a cross platform library like blessed

To @boris’s questions about nw.js vs. Electron: Electron wasn’t available back in 2013 when we did the first version of TiddlyDesktop.

Having seen the community momentum around Electron, since then I’ve intermittently researched switching but found that nw.js is still often judged superior in key respects (particularly memory consumption and size on disk). Furthermore, we use it in a special “mixed content” mode that enables us to call Node.js APIs directly from the HTML/JS making up the UI, which is not supported in Electron. But these things change over time, and if we were to undertake a major rewrite I’d certainly re-evaluate the benefits of switching over to Electron.

1 Like
#13

Bob.exe by JED is a version of this, it can also host single file wikis.

I would like to see bob or it’s equivalent subsumed into the tiddlywiki with its tiddler level locks and find a way to publish securely on the internet.

But also allow finished tiddlywiki 's to be published as apps.

#14

I don’t think our users will be happy with a terminal based UI if they just installed a TW GUI – I would expect that the system configuration can be done with the same or a similar GUI

1 Like
#15

I think the “process” you describing for a “setup” looks very good even in draft and would be well “user tolerable” so long as there is a clear “wizard”.

I have two general initial questions I think may be relevant …

  1. Will it work (roughly) the same on all platforms?

  2. What about smart phones? Would this approach work for them too? (Given that it is such a huge slice now of modern computing)

Best wishes
TT

1 Like
#16

@jeremyruston, this is a fascinating comment from the man driving that great TiddlyDesktop innovation.

By way of a footnote on your observation. I think it depends on the use case. I’d like to flag some of the other types of cases. In instances where you need replicate a self-contained software/data system TiddlyDesktop is superb! For instance, an anthropologist collecting data. They don’t need browser bells-and-whistles; they need entry-slots, full stop. Simply a simple interface. In fact TiddlyDesktop is good precisely because you can control the “interface” so well and focus on the “user needs process” precisely.

#17

Yes indeed. The real value of the current TiddlyDesktop implementation is the way that behind the scenes it is just a TiddlyWiki with some special capabilities (such as opening desktop windows), and I would expect to retain that architecture in some way.

1 Like
#18

This is indeed the appeal of WebDAV, it seems like very low hanging fruit that would serve the needs of users who work with single file wikis. In fact the only thing missing from existing options is a friendlier way (GUI?) to configure the server parameters than using the command line or editing a YAML file. I haven’t looked into GUI implementation details for Go, or other configuration alternatives yet, but this could ostensibly be an undertaking small and self-contained enough that I could find the time to build and maintain it.

I have a professional and personal interest in facilitating use of local single file TiddlyWiki by users with limited digital literacy using resource scarce devices.

I will revisit this topic when time allows and explain my thinking in more detail, both in terms of user experience and technical details. I am waiting for an opportunity to write up my thoughts in a considered and coherent manner lest I compound the mistakes of my initial rushed post.

Happy for others to continue the conversation in the meantime if there is interest.

1 Like
#19

@saqimtiaz I too are keen for a similar solution ultimately for professional and business reasons.

I hope the following thoughts are of some value as I have spent a lot of time on this subject.

One step forward may be;

  • For a locally accessible wiki the local host address range 127.x.x.x offers around 16 million addresses one could argue a random address could be an auto-configuration option.
  • Interestingly this larger range seems rarely used.

What are the other key server parameters we need to deal with? They are influenced by the trust environment.

  • Configuration handling - JED’s Bob imports and allows the changing of configuration settings on the server, in its case Node. Something similar could be used to handle a YAML file.
  • If our WedDav served wiki can save and read other files (not just itself) in its local directory,
    • sophisticated Tiddlywiki based GUI’s can be developed in tiddlywiki itself
    • The locks/serial editing user control and passwords features added
    • File uploads plugin or a version of it can be used.
  • I am a strong believer we should design with the consideration of the different “trust” environments. Eg:
    • for oneself to access ones wikis
      • On the local machine only eg local host
        • This should permit the option of more interaction with the local machine (eg; like Timimi Webextensions)
      • from another device of mine on the LAN eg my Mobile
      • Only needs listen on 0.0.0.0 and it will acquire the local ip Addresses
        • We should however allow a static address to be used.
    • to share with others on the LAN
      • from friends, family team members on the LAN
      • to host somewhere “always on” on the LAN not my local desktop
        • One opportunity here is also those with a VPN into the LAN for individuals or team members for remote access.
    • Ultimately on the Internet (very low trust)
      • but lets not let this negatively impact the other higher trust environments.

A key technology for multiple users is the provision of a lock, check in or checkout facility for single files wikis to allow serial editing, ie multi-user over time. I have done a lot of work on this already, but believe it should be included in a WebDav solution.

If a solution can be preloaded with a specific wiki, but containing a configuration GUI, people can obtain a for purpose “application”, minimal setup requirements with access to a “backstage” where they may install additional wikis, access backups etc… via the same server/IP address but different paths.

#20

I hope this is relevant and interesting - it is just something I ran across while browsing. LoFloccus - a webdav server with a user interface. Written in the go language and the Qt graphics library for the server ui. It was written as a companion for a browser plugin for syncing bookmarks to a local file; which seems similar to the application of syncing in-browser tiddlers to local files. I thought the UI looked like it could be inspirational for a similar TiddlyWiki focused application.

68747470733a2f2f63646e2e696b6c6976652e65752f74636231332f323031392f6c6f666c6f636375732d312d312d302e706e67

5 Likes