all,
just a thought experiment - as i basically use my wiki as an os already, what sorts of hardware features would you put in the perfect dedicated tw machine? i am imagining a laptop-type form factor, with some custom keyboard optimized for navigating tw’s ui (maybe with something like my nav plugin?).
or put another way, if you could dream up the perfect dedicated tw5 hardware+software system, what would it look like?
as a side note, i find myself drawn to the cyberdeck-type devices. something like this seems perfect to take with you wherever you go and have quick (and stylish, in a sort of techno-brutalist way) access to your wiki 
Right(-ish).
As far as I know you can, under Node,js, and certain implementations of TW “back-ends”, that allow launch of programs from TW, you can get quite close to that (“OS interaction”).
I do think that “Back-End” interfaces with the OS are very useful. But they are not that widely accessible or, perhaps, understood? Browsers make it difficult (security concerns?)?
Just a comment
TT
I have a feeling this is going to turn into an interesting discussion, because already I can tell everyone’s idea of a perfect device is gonna be a tad different.
For me, if I could design a device whose sole purpose was to serve as a TW device, it would be a eink screen blackberry style device with stylus support. something like a slide up screen to reveal the keyboard underneath, but keep a full screen for drawing illustrations, when you need to jot down a quick sketch of something.
and, eink for the increased battery-life. you can then dock the device (given in this day and age all mobile devices that aren’t apple run android 10 and up) to a usb-c dock for connecting a monitor / keyboard / mouse, or serve as a usb for file transfer via OTG
That, is what my perfect TW device would be.
How do you use yours like an OS, if you don’t mind me asking? I’m curious about how you can do file management and web browsing from within a TW. I know some functionality can be done with an iframe, but I’m not too familiar with them 
Right. A Tad.
“I know some functionality can be done with an iframe …” Right. But not a lot.
More significant, maybe, are cases where you can directly launch programs from a TW.
Launching anything directly has got very difficult in modern browsers. FYI, the first version of the Timimi saver by @Riz provided that–but he withdrew it in the later version as he felt it not kosher, I think, i.e. potentially dangerous.
The Node versions of TW have more potential that way. Including @inmysocks’ Bob and TiddlyDesktop???
Just a comment
TT
i guess a note on the “os” comment - i meant less launching programs from the tw and more “tw is the only thing i’d ever need to run on this device”. not a backend launcher / os but with no need to go further “back” than the tw core.
although, a spinoff of tw with the ability to go beyond browser security limitations would be very very cool!
beautiful. i am a huge fan of e-ink/epaper displays, i used to have a pebble smartwatch back in the day. looking forward to larger versions of sharp’s memory lcd which has a much faster refresh rate!
Interesting Question @Scribs
Perhaps rather than Think of TiddlyWiki as an OS perhaps as the key “application interface”
Unfortunately I am biased as a user of TiddlyWiki on a desktop with two large screens, I am used to using two large screens, each containing a browser and between one and a dozen (often tiddlywiki) tabs.
However I just purchased a new Tablet, a Lenovo with a pen, with a view to using it for tiddlywiki, so my mind is now open to using tiddlywiki on a portable device.
This makes sense as a user but perhaps not for security. I many ways I think we need to come to terms with this division between internet facing tiddlywikis and local system facing tiddlywikis. Once we accept this, perhaps it points us in the direction we need to go.
I am in many ways only talking here about the underlying mechanisms, but they have being on my mind for some time. Yet I do have many ideas about how to integrate with the locally installed filesystem and apps.
You could have a program, like Polly, that periodically scans your TW file, looking for key strings. When it finds those strings, it parses and launches the appropriate activity.
Inside of the TW file, you generate the strings in a way that the string isn’t available as text until you do so. That is, you create a tiddler containing the instructions on the fly.
agreed on security, i would imagine that if the wiki was “the device” then it would likely be local access only with a cloud backup, not meant to be accessed by anyone else. there is still a promising (maybe even primary) use case of “my personal information manager” that would not be concerned with security as everything is user-generated or shared with the same… gravitas? as a full computer program with system access (super-plugin).
i.e
in this theoretical “tw os”, plugins can be shared and downloaded that request root access to your device similarly to an executable program. the “tw os” has full permissions and can load these “super-plugins” as root to launch other programs, run commands on the terminal to download dependencies, etc.
the security becomes a user responsibility at the same level as vetting software before you install/run it. this would necessitate the wikis being “local system facing” and not “internet facing”.
Keep in mind another aspect of useability is what can your tiddlywiki do, for example a Get things Done organiser wiki may want to open an internet resource such as a google calendar, a shared document or access a website to order goods.
I am not in any way suggesting we should not do this, only that we need to take full account of security issues and build what is needed. To do this we can start with thinking how to enable the functionality we need from a local access wiki, by handing off the security of some features to another browser at arms length from the wiki, Sandboxes, iFrames, embedding and API’s etc…
Agreed. The more access you get, the more attack/threat vectors you create. More doors = more locks to look after = more opprotunities for a break in.
Its why I’m hessitant about these neural chips elon’s developing. Taking something that is in a closed network, ie a brain in this case, and exposing it to the public network, you risk compromising that system.
It’s kind of like your going from isolated individual to artificial hivemind.
Imagine getting a neurological equivilant to a ransomware attack. Pay a large lumpsum or become at least amnesic, and at worst, a comatose-like brain dead state?
I’m good with just using a medium of connection, like smartphones. That natural barrier is fine by me. I feel like I digressed oops.
Anyways, that isn’t saying it can’t be done of course. I think for TW, you’d want to implement sandboxing, where you have conttol over which things can do what. Like granting permissions on a smartphone, or like qubes os, since we’re on the topics of operating systems.
A tiddler for file browsing that can only view and modify the files, not add or remove, a tiddler for file creation / removal functions, a tiddler for web browsing, that cannot interact with any other tiddlers except by way of an approved temp tiddler, that self wipes after each use, and at the root running the shows your core tiddlers.
Keeping it all isolated means that if one or multiple is co.promised, if they are shadow tiddlers, juzt delete them to reset them. Minor set back, but not a fully compromised and protentially dangerous system on your hands.
I love eink devices, but the screen is a bit slow to update, and the devices themselves tend to use slower CPUs and minimal RAM. A slow eink device used for drawing would not be popular with most people, but some specialists might want it.
And slow computers is becoming more of a problem, mainly from users of Office 365. It takes much longer to open an Excel file with Office 365 than it did with an earlier Office.
Thanks @Mark_S.
I won’t write much here as it is a @Scribs’ initiated discussion.
But, YES to a Polly approach!
FYI, after your very helpful post, I’m envisioning this …
Create a Tiddler Export format for a “.bat” file (or for any other O/S scripting language).
Put a button for that on any Tiddler tagged “O/S Command”,. On click it saves it to the “downloads” directory
The Tiddler contains the “command line” you want executed
This is detected by a running Polly daemon (or other PowerShell) script monitoring “downloads” for “.bat” files.
Executes the command.
On succes the .bat script is deleted.
Adds a record, indicating success or failure, to a “.log” file that is visible as an external file in the TW that started the process.
This is a brief version. One I will try.
Hopefully it coveys a viable idea that is not that difficult to get working.
Thanks again, TT
Yeah, that’s actually a better approach, as long as the user doesn’t mind the download dialog.
Right. But in the scenario where you get TW simply to save a text file (locally) with instructions to the O/S to run a program that is NOT a browser I can’t see a serious issue.
Unless your computer is under “remote control” already?
Just a comment
TT
wow! this seems more approachable than i thought with a polly layer vs. a rewrite of something like tiddlydesktop. while it is not completely integrated (requiring the file download workaround), it seems like an interesting place to start on expanding the capabilities of tw in a local system!
in any case, i see “launch external programs” is high on the list of desired features.
anything else? consider maybe a commercial product, the “tw machine” as a dedicated portable wiki device. what features would it champion that would get your attention? cloud backup? auto-import .tid files from a connected usb device?
i also see promise in the “mini-app” concept discussed here 
Samsung Tab s9 Ultra + Smart Stylus, TW5 front-end UI Client with Infinite Canvas mode (See this youtube video).
Backend cloud server to handle authentication/authorization/api-secrets/persistence/live-multiplayer-sync/mutli-wiki (recipe/bags model) support.
Launch local apps on your device through smart URL links, launch complex processes on the server through TW websocket messages.
Live filter your wiki to compose “context windows” and send them off to an AI-LMM of your choice with a click.
Store the results as a “Streams” style node tree branching off the context window-source.
Type stuff on your phone, see it on your tablet live.
Draw on your tablet, see it on your phone live.
Invite others to collaborate.
The pieces are starting to come together. It is still a ways out. Threads like this are a great inspiration to keep going.