We’ve had lot of wish list stuff in the discussion following @jeremyruston’s initial post, so what’s your/ our/ my story?
Still working on this post. Pressed the send button by mistake. Be back later.
on this note, i made a thread in the past considering an all-in-one tw operating system, where a hardware device would boot to tw and all of a user’s apps, files etc. could be accessed via a tw interface. on a much more reasonable note, i’ve found myself wanting to put links to open local files, folders, apps, or run terminal commands from tw links many times, all of which are limited by browsers.
admittedly i have not looked much into tiddlydesktop, so i am not sure if it allows these things. but if not, that would be a huge expansion of the capabilities of the platform. and on the security side, maybe the core could detect if a plugin uses these features and produces a warning / confirmation window before installing the plugin?
Right. Browsers now are very limited.
I won’t go over how Bob (still?), TiddlyDesktop and the first version of Timimi allowed, via TW scripts, passed to the O/S, machine control.
I still think it a good objective for any TW user who wants to control their machine to do so.
Right. You’d likely need (1) a plugin and (2) a back-end system tool installed to re-connect the browser to the O/S.
I agree a “simple warning” is advisable and is enough.
My point was that the limitation of common browsers has had bad effects on freedom— as well as a few good safeguards. It is now far too limiting.
I’d like to see TW explicitly be able to control ALL I do on a computer 
when I want that.
TW is getting limited by browsers in a way that is limiting its existing powers and development IMO.
QED, TT
1 Like
In the past few days I have been pointed towards two AI tools. I’d not used either before, nor was I aware of them
- Perplexity
- rabbitOS
The latter really suprised me. It outputted images, markdown files. It created a repo.
I’ve now asked rabbitOS to create me a TW
It is still crunching away. It may never do it.
However the idea is seeded. Create TW files pre-populated with data.
Any thoughts?
Alex
This is what it output. It didn’t complete the task such that umami_dashi_wiki.htlm actually worked with the images and tiddlers.json
Any ideas on what I would put in a prompt to create a node.js version which would be able to read folders of .tid files ?
I’d like the back-ends for getting at the OS to be configurable per machine that I might sit down at with a relatively simple way to configure them.
For example I have previously wittered on about email Message-Id URLs which should of course follow the standard. One could use the OS’s handler which in turn goes to Mail.app or Thunderbird. Or fall back to gmail.com on somebody else’s computer.
Then there’s opening files and directories.
Perhaps I’ll have a macro in my notes that refers to <<source_file file:“project_A/create_problems.c” line:“389”>> and I’d have my back-ends translate that to a Windows UNC path on my Windows machine, an automounted UNIXy path on UNIXy (inc. MacOS) machines and some URL on anything else (following the gmail above) .
Something I have experimented with recently is having the EDITOR environment run a script that fires the file spec through a reverse SSH TCP tunnel to my client machine’s editor (well emacsclient). That allows me to run for example cscope efficiently on the server. But I could also imagine an http request to my server hosting the wiki using some mechanism to make my local editor (or Finder or file explorer) do something.
TiddlyWiki and I have had quite a history together. I first started experimenting with TiddlyWiki with classic trying to start a Getting Things Done system and later as a game engine through Twine. But once I discovered what TiddlyWiki was at its core I found that it was the perfect tool to dumb brain ideas into. Anytime I found or thought of a tip, trick, idea, or link I didn’t have to worry where I should store that. Unlink a raw file system where I had to worry about what directory to organize it into or how to manage separate files that are actually related (linked). Searching would need a structured data system. Presentation would need some kind of build system. Web ages needed a server. None of that worked will in the sneaker net that I used to be stuck in long ago.
Like most systems my GTD setup floundered and my use of TW faded. But I revived later when I needed a working static website generator and I knew a normal blog was too much structure for me to keep going. Instead I needed a dumping ground of random stuff big and small that I could have generated to a basic personal home page. TW came to my rescue now at version 5.
The more I used it the more I discovered how flexible it was and how useful it was to have a single HTML file I can place anywhere/anytime. I started using TW for all kinds of things like Minecraft Tutorials and Résumés (CVs). I learned just how many features come built-in from the core modules. And anything that wasn’t in the core modules I could add myself. I started using TW as a base framework to add my own features including image processing build tasks.
Eventually I needed a way to track my daily habits at work. The field I work in needs strict approval for installing applications. It is close to (but not really) air-gapped. I thought TW was perfect for this kind of situation since it just an HTML file running in the browser. Then since we use Node for our development build tools it was not a hard jump to vet the source and run TW under Node. Now with a localhost server I can pin a tab in my browser and have a daily brain dump wiki with daily journalling.
For whatever reason, this has been the only tool I’ve ever tried that has remained in daily use for six years now.
It is for these reasons I find TW to be invaluable for me. I hope these core ideas remain.
- designing a structured wiki
- brain dump ideas without any organization
- complex and expressive searching
- customize anything
- single file saving
- self-executable (runtime on all modern machine by default)
- auto-save to a built-in backend
- no JS frameworks, VanillaJS based core
- zero dependencies
- easy to upgrade
- easy to contribute to
- easy to walk the codebase
9 Likes
Right.
That way would ensure security AND freedom. An opt-in backend connection.
I fear on browsers now it would still be very difficult.
One way around it would be to run a daemon in the background that could detect any file written to disk by a TW.
So … In TW have an action to save a batch command file (I.e. a “command tiddler”) to disk that a daemon can detect and execute.
Not ideal, but still workable atm.
TT
Yes. A beautiful one.
Thank you to everyone for the thoughtful and interesting feedback. I have now posted a longer thread about v5.4.0, but do feel free to continue to post here.
I may not be able to envisage the scope of your aspiration but as a single file TW user who is highly dependent on TW on my tablet, phone and laptop I very much appreciate the current role of the browser.
On my android phones I use Tiddloid and on my Unix laptop I use Tiddly desktop, I have a small keyboard for my tablet which means I can work when I am in transit. I use TW as my central knowledge base which is large and the product of hours of work every day for a number of years.
For me the browser is rarely a fundamental limitation and a lot of problems have a manual work around - what it delivers in return is that the browser is my access to TW on any device, its like a passport that means I float above the OS problems, all in return for very little inconvenience.
There are device issues for sure, for example on Android I need to access my TW on a device local server because of the way the Android security and filing system limits the ability of a browser to access locally stored videos and so on.
In terms of liberating people on different machines and platforms, in principle it might be a great thing, one of the reasons I am on Linux is because I could not tolerate Microsoft updating my machine when ever they felt like it - they always messed up my custom device drivers and thought they knew my needs better than I did and I have already mentioned a limitation of Android and of course there is Apple - the pinnacle of user tie in or coercion depending on your point of view. Against this viewpoint many users out there don’t want to understand their machine or software they just want something that works most of the time (Apple?) - as a linux user I sometimes forget all the fears about viruses and so on. I think a truly open system would have to come up with some new ideas about security balancing open-ness with safety - not an easy balance.
2 Likes
I think that is right.
Part of the issue is that back-end-geeks, informed users etc. can perfectly well understand the potential issues and address them.
Meanwhile the “let me only do anything safe but stop me otherwise” is the standard browsers’ norm.
There are good reasons both ways!
But, I do think a v. good case can be made to get round browser limits In Cases where the user needs interact with calls to the O/S.
A simple example would be “invoke a local search of all my docs mentioning ‘Ruston’ and build an external tiddler listing them.”
Implementations such as Tiddlydesktop, tiddlywiki-app do this by using a custom (Chrome) browser and do give you access to local resources. Also the antequated and limited hta method.
- Extending this to internet hosted wikis or through host side instalations (as used in Timimi) just requires the nessasary skills and a champion to make this posible.
- However we are already having trouble keeping Timimi operational after recent and pending browser changes.
1 Like
Wouldn’t it be great if instead of making custom browsers it were possible to configure regular ones to allow certain pages to interact with operating systems in the ways we want.
Could browser producers (roughly MS, Google and Mozilla) be convinced this would be good or can plugins achieve it including for mobile devices ?
1 Like
Chrome and Edge (desktop) did implement a native file-api lately. There even is a TW plugin which is a bit clunky to use for security reasons.
Safari and Mozilla did not implement it (probably) for security reasons. They are not even considering it atm.
I think none of the mobile browsers will ever implement it, since mobile phones do not really have a file-system. They have storage, which is heavily sandboxed, for obvious reasons.
-m
PS: I think we should give our TW browser-storage plugin a bit more love, since it works out of the box on all browsers.
1 Like
There actually is a proper filesystem on both iOS and Android, it’s just not exposed to users very often. That said, I’m also skeptical at this point that the File System Access API will move beyond Google Chrome Desktop.
Right. I use Chromebook. It’s whole thing/k is wooden.
To the point here: HOW, practically, can we legitimately get TW to act beyond The Standard Browser?