Hello Twikians;
I’m excited to share with you a proof-of-concept demonstration I’ve been working on for the past few days which really highlights the versatility and elegance of TiddlyWiki. But first I would like to provide a bit of background context and to explain my journey if you would be so kind as to indulge me in some devblogging.
Click Below to Read the Devblog
Click Here
Electrical Engineering Studies
I am a nontraditional student; and I have 1 semester left to complete my electrical engineering degree and if everything goes as planned I will graduate in December.
In my time I kept finding myself needing a central place to store all my notes, homework, thoughts, lab results, etc, which let me to exploring the PKMS software sphere. Notion; Affine; Xournal++ for PDF markup/written notes and finally Logseq was my favorite of them; though it still had a lot of things I didn’t like.
Then I stumbled into TiddlyWiki and started exploring all it was capable of; found TiddlyStudy which took a lot of inspiration from Logseq, and I started expanding it further into a new pet-project edition I’ve called Lithic UK. It’s been fun for me trying to curate; collate and combine all the features and plugins I want and need into a comprehensive Tiddlywiki edition.
Lithic Development and Extending *.tid Files
Originally I used the Wikis in standalone HTML-mode without any sort of wrapper or anything; but this gets cumbersome pretty fast. At some point I stumbled on to TiddlyStow , simplified the UI a bit and used that to access my local HTML Wikis. But this led to another point of friction; most of my standalone wikis were the same lithic ‘core’ with a comparatively smaller set of data tiddlers contained within. To ease this I tweaked TiddlyStow further to fetch the most recent build of my ‘empty’ wiki and dynamically inject *.json data tiddler bundles, then on save over-write that same *.json with only the data tiddlers and none of the core wiki tiddlers. This worked well and saved space; but there was still room for improve.
*.json is syntax and symbol heavy; it is not fun for humans or LLMs to read. I really liked the terseness and readability of the *.tid format, but it currently only supports 1 tiddler at a time. So decided on a bespoke format I’m calling *.lith; (like short for monolith, 'lith) and it’s simply multiple *.tid-formatted blocks; delimited using triple asterisms:
created: 20260513153401404
modified: 20260513153404926
stream-list: [[13th May 2026@10:34:04.922]]
stream-type: default
tags: Journal
title: 13th May 2026
this is a test.
⁂⁂⁂
created: 20260513153404924
modified: 20260513153405872
parent: 13th May 2026
stream-type: default
title: 13th May 2026@10:34:04.922
type: text/x-markdown
this is another test
This worked really well for me, cuts down on token usage when fed into an LLM, and still allows me to save my full wikis in a svelte, plain-text file that stays pretty small. Up to this point I only used this process on local files with the launcher and core wiki being static SPAs, but someone on GitHub requested steps on how they could self-host Lithic, which led me down a back-end rabbit hole.
Building the Backend
I really liked the above workflow I was using, and so I didn’t want to use node.js as it seemed to be built around the idea of having your wiki stored as a directory tree + individual *.tid files; I wanted a solution that would seamlessly leverage the *.lith format I was already using. I heard a lot of people recommend WebDAV saver around here, and since it isn’t a SyncAdapter it would still be able to generate the monolithic *.liths like I was wanting; it was basically a ‘bolt-on’ solution. So I extend the launcher a bit to support saving *.liths remotely over https when Webdav was available; and this worked pretty well too. The other advantage to using webdav vs node.js is that WebDav is a very barebones protocol and there are lots of small libraries, node.js base is around 80 MB compiled while lighthttp + webdav only takes up ~ 10 MB of space; the server image needed for this hosting strategy is extremely small and efficient.
Back to Electrical Engineering Studies
Last semester I finished my Senior Design capstone project, a 1-plant self-contained ‘smart’ automatic watering device. I used an ESP32-WROOM for the main processing component as it has a built-in wifi antenna so I could host a local ‘webapp’ to control the device and view history etc without needing internet; or develop a full mobile app or anything. It seemed to me a practical way to approach making the prototype. I finished the project and (forgiving some inconsistent connections due to my dreadful soldering skills) it worked like a charm. I had bought a handful of ESP-32s so I would have spares (glad I did because I inadvertently fried one by supply 12 VDC to one of the pins due to a layout error on my stripboard) Since the semester is over; and TIddlywiki/Lithic being a near omnipresent obsession of mine, I put 2 & 2 together and decided to see if I could run the Lithic Backend on an ESP32-Wroom. Turns out you can!
TL;DR: Lithic-UK on ESP32
I’ve successfully ported a functional Lithic-UK (a local-first, Live Preview outliner) backend to an ESP32-WROOM. This setup utilizes a bespoke .lith format—a multi-tiddler plaintext specification using triple-asterism delimiters (⁂⁂⁂)—to maintain the readability of .tid files while avoiding the overhead of JSON or the directory-tree complexity of Node.js.
The implementation leverages a lightweight WebDAV protocol for remote saving over HTTP, managed via ESPAsyncWebServer and AsyncTCP PlatformIO Libraries. By avoiding the overhead of a traditional Node.js environment or heavier server software, the system operates as a high-performance, asynchronous backend that fits comfortably within the ESP32’s limited 4MB built-in storage. This allows the microcontroller to function as a self-contained, hardware-based PKMS that serves and saves monolithic .lith files directly over local “ad-hoc” wifi.
Resources:
- Lithic Core: Xyvir/Lithic-UK
- ESP32 Backend: Xyvir/Lithic-UK-esp32
- Video Demo: Watch the Proof of Concept
- Hardware: ESP-WROOM-32 Development Board