Exploring TW-desktop integration using tm-http-request

#1

We have some discussions on TW desktop integration to launch local file and applications ( How to launch a desktop application with TiddlyWiki - Discussion - Talk TW and Your perfect tw5 device (and running external programs via tw) - Discussion - Talk TW ).

I was intrigued by nemo’s post TiddlyWiki Integration / Automation to explore a possible hack for desktop integration. The idea is to use TW tm-http-request to send XML-Http-Request(XHR) message to a XHR-capable network tool, then launch a desktop script to process the message and return a response back to TW. Basically, TW will circumvent the browser-desktop barrier to interact with the desktop via the network using tm-http-request messages.

With AI assistance, I found a bash script that runs as a rudimental web server using “socat” network utility. On my chromebook, a single file TW was able to retrieve directory listing and files from the Linux desktop, and launch on the desktop the default Linux application for a file :slight_smile: There is no network security though, so some more work is needed for it to be useful outside of private LAN. The test scripts and details have been uploaded to https://tw-desktop-integration-testing.tiddlyhost.com/

Some thoughts from my exploration:

  1. The appeal of the approach to me is Simplicity : just a small network tool and some scripts can give us some* of the desktop integration many have sought. The scope is simple enough for me to test it myself. But now that I know it works, there are more to be done to get it to work properly than I have the time to spare :frowning:
    *tm-http-request messaging can only be initiated from TW to the desktop, not the other way.

  2. I believe this tm-http-request approach works not just with single file TW, but also with the server-based variants of TW as it requires only tm-http-request (TW v3.5.0 onwards) on TW’s side. So the same TW app written to interact with a desktop using this approach should work on single file TW as well as on the server-based variants of TW !

  3. On the desktop side, the “desktop for integration” need not be on the same machine where TW is running, or on the server where node.js is running. It can be a “remote desktop” on any OS platform as long as we have a compatible tool/app there that can receive and process the XHR-based messages from TW. Pre-requisite is the tool/app will need authentication and encryption enabled to run securely across network.

    On Android : “Termux” seems to be depreciated nowadays. Nevertheless, I tested sending a tm-http-request locally from TW on Android browser to the bash script in Termux successfully. The “Tasker” app for automation supports XML-Http-Request and seems promising for this purpose; not tested though.

    On Windows : Powershell supports XML-Http-Request directly. I tested sending a tm-http-request locally from TW on Edge browser to a AI-generated Powershell script successfully.

  4. An idea beyond this “hack-together desktop integration” : For TW to circumvent the browser-desktop restrictions permanently, it might be worth looking into developing a lightweight native app as a sidekick for TW that can exchange XHR messages with TW for desktop integration, as a remote TW saver, and perhaps to facilitate inter-TWs communication ? Just an idea.

I enjoyed this little exploration. It scratched a little itch for me. Hopefully, you find the info useful and perhaps some of you might be tempted to push it further. My test scripts are shared at https://tw-desktop-integration-testing.tiddlyhost.com/. Your feedbacks are welcome !

3 Likes
#2

I use Windows. I failed with all my efforts to get a reliably working solution for this. I ended up copying the path to the file from windows explorer. Then, when I need to open the file or the folder, depending of the path I copy from tiddlywiki and I use a Beeftext combo to run a PowerShell script that does the trick.

#3

The Powershell script was AI generated. I only tested it very briefly to see that it can receive a TM-Http-Request from TW. This one needs more work.

Mmmm, the TW-HTTP-REQUEST-sender won’t work from Tiddlyhost, you did copy to and run it on Windows ? I put them on Tiddlyhost rather than in Talk.tiddlywiki.org mainly because the Powershell scripts are AI generated and I wanted to distance them from Talk.tiddlywiki.org.

The bash script is human-crafted and works much better :slight_smile: I tested it on a Chromebook but not in Windows Linux. I don’t use Windows much nowadays, no idea what could go wrong there.

These scripts are more proof-of-concept at the moment and needs more work, please don’t expect a working solution that you can use right off.

#4

From what I know, the main issue of access to file system is security wheen it comes through the browser. I previously tried to use file:// paths with an extension which opens the door to the browser accessing files on the hard-drive. It got patched up as soon as my browser or anti-virus app updated.

I didn’t try anything from your post above. I am sharing a reliable method to work around this, instead of trying to solve it with TiddlyWiki. I can elaborate if you’re interested.

However, if your goal is to build a solution to this problem, don’t listen to me. It is a feature I’ve been trying to bridge for a long time and I believe will be very usefull.

1 Like
#5

Ah, I misunderstood your post. That came across to me as exasperation, but it’s over the browser security and not from working on my solution, ha ha. Same here, with both actually. Thanks for sharing !

1 Like
#6

An earlier version of Timimi flirted with this even from a full browser by leveraging a host application to provide the ability to issue host actions.

  • of course security needs to be taken into account but most of the big players like Microsoft ang google have done this and maintain it for their online suits

not withstanding the above from tiddlydesktop, tiddlywiki-app, the .hta method and others operating in local applications and non general purpose browsers have more local access than from within browsers exposed to the risky internet.

  • it should be somewhat trivial for someone with the appropriate skills to enhance this further