Custom application for TiddlyWiki based on WebDAV

#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
#21

@amreus thank you.

Researching GUI libraries that are cross platform and with which the application can compile to a single executable of reasonable size is on my to-do list.

One of the options worth considering is just using a PWA/TW served over WebDAV for the server configuration itself as well.

#22

I’m not sure if I’ve mentioned it before, but at the risk of introducing a tangent I have a soft spot for https://redbean.dev/, a cross platform web server in a single executable that integrates the code and data. Very TW-esque.

4 Likes
#23

@saqimtiaz I just reviewed your video demo and was very impressed.

Despite intimating various ideas earlier in this thread I think the webDav solution you presented would facilitate the concept of tiddlywiki’s acting as smart documents. Basically a document which, in addition to providing an interactive UI it may also contain the “smarts” to manage itself, a bit like packaging a document with the document management environment built in. That is, rather than placing the document into a Document management system, placing the document management system into the document.

To explore the possibility of such a vision a key requirement is they can be treated as documents on different devices and operating systems. That is they are not bound to the server or browser. Your solution demonstrates this. It also allows instances of tiddlywiki to be more really be treated as documents/files.

I used TiddlyDesktop a lot previously just to get the interaction with the local desktop and files. This solution allows one to use the preferred browser and all the bookmarks, bookmarklets etc… therein whilst gaining the local interaction.

Love your work.

1 Like
#24

I just returened here after posting this curiosity Curious Observation Tiddlywiki.com in read only windows help file.

I wanted to Bump this and suggest it would be good to see all four of the following;

  • The ability to package a single tiddlywiki into a exe that can save locally. Using a native application windows (like Single wiki version of Bob.exe or tiddlydesktop) bit like tw.exe.
  • The ability to package a single tiddlywiki in an exe which serves it at a local host address (not the 127.0.0.1 but say 127.4.4.4 and/or configure)
  • The above on 0.0.0.0 or a named “static IP Address” eg: 192.168.32.200 so the one user can access it from multiple devices.
    ** We need a form of checkout on device.
  • Something similar to the webdav solution which acts as a way to serve multiple TiddlyWiki’s and open/save them.

I could see us having .tw files with associations to open in a exe or server such as ensure WebDAV is loaded.

Yes I would also like bob.exe for multi-user wikis to allow us to package a custom wiki in it.

#25

I think that is near GitHub - tiddly-gittly/TidGi-Desktop: TidGi is an privatcy-in-mind, automated, auto-git-backup, freely-deployed Tiddlywiki knowledge management Desktop note app, with local REST API. 「 太记 」是一个基于「 太微 TiddlyWiki 」的知识管理桌面应用，能保护隐私内容、高级自动化、自动Git云备份、部署为博客，且可通过RESTAPI与Anki等应用连接。（迭代开发中欢迎试用，开发进度见下方链接）(Under active development, see website below for details) , I make this to make sure most of user can use it like using Obsidian app.

In TidGi, TiddlyWiki only cares about saving to disk, the backup is managed by the git, so we can use any git manager or just use TidGI’s built-in git-sync module to do complex git-flow backup.
Adding a webdav backup module to TidGi won’t be too complex. And I pack the git binary with TidGi, so user don’t need to install nodejs and git (maybe webdav server too) by them self, they possibly don’t even know what git and nodeis are!

Doing backup in TidGi is because its electron is multi-process, we can backup in background, so it won’t slowdown the frontend. And no matter what happened to frontend, there will always be a backup in the disk.

Beyond that, I’m providing some native feature to tiddlywiki via electron, like executing shell and JS in the nodejs via GitHub - google/zx: A tool for writing better scripts , or open tiddler (PDF tiddler) in native reader…

1 Like
#26

That is what I’m implementing in Choosing starting Template, a TW edition (wiki template) list API JSON example - #3 by jeremyruston

2 Likes
#27

I have made decent progress on implementing a basic cross platform WebDAV server with a GUI configuration for creating new wikis, configuring backups etc. In limited testing it is working well on Ubuntu, Windows and OSX.

All of the code handling creating new wikis etc is client based and the next thing I need to do is refactor that for potential inclusion in to the core and greater reliability overall.

The overall user experience is similar to what is shown in the video demo I posted a while back, with the major difference being that setting up a WebDAV server for TiddlyWiki to use and creating your first wiki is pretty much a one click process.

4 Likes
#28

@saqimtiaz I revisited your demo video again and must say I am really impressed.

Once finessed I think it provides an easy path to adoption and hosting. Other features long sought after such as a basic locking, local system access all in one bundle is fantastic. By the way it is implemented, I can see it should be easy to add more sophisticated features built on top such as user control mechanism’s etc…

  • In my view it already includes the lion’s share of features for a robust solution

Is there a installable example? and could you please share the link?

  • I am collecting all the resources I can find but not yet found an install method.

One other Question

  • You mention its operation simply required a “put” so do you think it can be able to work on top of a php host?
#29

I am not sure if you refer to the client side code (TW plugins) for working with WebDAV that is presented in the demo, or the WebDAV server this thread is about. In either case however, there is no public demo yet.

The first goal will be to get the server robust enough for release, which will take a fair bit of time considering my schedule for the near future. The plugins likely will not be published until after we have HTTP actions in the core, and I rewrite the plugins to use them.

Everything you see in the client side demo requires WebDAV. When I mention requiring a PUT request, it is to illustrate how easy working with WebDAV actually is.

I would prefer to keep this thread focused on the server component.

#30

No time pressure at all. It was hard to see if I had missed something. I just wanted to help, experiment etc… I await any updates :nerd_face:

#31

I am still very interested to see this - the demo you posted some time ago was really promising. Unfortunately I cannot find the thread anymore, can relink it?

Spotlight: A Dream to Have a LightBox Gallery in Tiddlywiki
#32

@JanJo I don’t believe there has ever been a publicly accessible version of it but I did post a writeup and video demonstration a while back, see below:

2 Likes
#33

This looks incredible. I think many would find it useful. Looking forward to the publicly accessible version!

2 Likes
#34

Just spent some time going down the redbean rabbit hole!! This is truly a very cool piece of software. It would be nice if it had an integrated webdav server!

#35

There is a Red Bean saver for TiddlyWiki that works via the TW WebDAV saver:

https://links.tiddlywiki.org/#Link%20from%20saqimtiaz%3A%20baee72b39bfff0793fa2

1 Like
#36

I tried to investigate redbean over the weekend - Windows immediately flags it as a virus, makes the executable inaccessible, and ultimately removes the download entirely. I know it’s a false positive. I know I could white list it. Until enough false positives are reported and the antivirus scanners catch up, It’s literally a nonstarter on Windows.

Edited to add that a key feature of redbean named StoreAsset which performs the save is currently not supported on Windows.

#37

This looks promising but beyond my ability to implement myself at this point.

Thanks @saqimtiaz for your work and I look forward to the possibility of someone publishing this.

A couple of quick points;

  • There is value having a single wiki solution if it smooths acquisition of a tiddlywiki and would complement the multi-wiki solutions such as widdler.
  • The use of localhost:8080 is making a serious assumption that such an address and port is free, it is not in most cases, where a server is already in use. The ability to publish at any local or network IP address, and ideally port, should I belive be configurable (after initial setup if not before)
    • 127.any.any.any are available for local only addresses - selecting a somewhat random one may help eg 127.84.87.53 wich is ascii decimal for 127.T.W.5
    • To be able to set 0.0.0.0 to publish on the LAN, or ideally a static IP address for which the desktop owns, including its own principal IP address and or an additional one assigned on that same computer, would be as far as this customisation needs to go.
  • The use of an additional static IP Address permits such a solution to be published and shared initial from the current device without interfering with other servers on the device, but also allows the “server” to be moved to another device along with its custom IP Address, without needing to update the IP Address and/or DNS every where a link to it is used, even in the server setup itself.
  • Using port 80 allows a simple link to be used with no port specified, eg port 80 which browser open as html by default. Thus 127.84.87.53 or an external IP Address is sufficient to access the wiki
    • The wiki can be published in a local DNS and be practical to use if no port is required because many if not all DNS’s do not accept a port number.
  • Being configurable multiple wikis can be published on local host or the local network

Regards
Tony

#38

Oh man this is amazing thanks yet again!!

from way down on the page under flags:

|-p PORT|listen port [def. 8080; repeatable]|

|-l ADDR|listen addr [def. 0.0.0.0; repeatable]| (that’s a lower case L )