Is there a MacOS user anywhere out there testing?
If yes, could you please test drag&drop?
That would help me A LOT!
oo la la, professional, comprehensive, fast, small, responsive including to feedback
Perhaps you should discuss this being the next generation to TiddlyDesktop and lift the responsibility off @jeremyruston but avoiding a rod for your own back by onboarding others to this open source project.
I am on the move so my desktop access is limited but I will deep dive on the current release asap.
One experiment I want to do on windows is to setup .tw file associations to open in tiddlydesktop ts, it works on regular browsers as they see the html tags in tw files. why, because it allows someone to find and search tiddlywiki files seperatly from other html files especially important to big desktop computers and html authors and collections.
what if we could add internet hosted wikis to the index but simply let them open in the default browser or a command line. eg tiddlyhost wikis.
why? to consolidate our key wiki list
Good morning @yan
Could you try the following?
WEBKIT_DISABLE_DMABUF_RENDERER=1 ./tiddlydesktop-rs
if that doesn’t help, try this:
WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_DISABLE_COMPOSITING_MODE=1 ./tiddlydesktop-rs
Edit: wait 30 minutes for release v0.1.36
This document describes the security architecture of TiddlyDesktop-RS and how it compares to running TiddlyWiki in a standard web browser.
TiddlyDesktop-RS is a purpose-built application for running TiddlyWiki files locally. Unlike a general-purpose web browser, it has a narrower attack surface but also intentionally grants more local system access to enable TiddlyWiki’s full functionality.
Key principle: TiddlyDesktop-RS trusts the TiddlyWiki files you explicitly open, similar to how you trust documents you open in a word processor.
TiddlyDesktop-RS uses Tauri 2.0’s capabilities system instead of traditional OS-level sandboxing. This provides security through explicit permission grants:
// capabilities/default.json
{
"permissions": [
"core:default",
"core:window:allow-set-title",
"core:window:allow-destroy",
"dialog:allow-open",
"dialog:allow-save",
"fs:allow-read-text-file",
"fs:allow-write-text-file",
...
]
}
How this provides security:
Comparison to browsers: Browsers expose a fixed Web API. TiddlyDesktop exposes only the Tauri commands explicitly permitted - no arbitrary backend execution is possible.
Allowed protocols:
wikifile://localhost/* - Custom protocol for loading local wiki fileshttp://127.0.0.1:* and http://localhost:* - For wiki folder servers onlyBlocked protocols (in authentication windows):
file:// - Prevents local file access from auth contextsjavascript: - Prevents script injectiondata: - Prevents data URI attacksAuthentication windows require HTTPS (except localhost for development).
Each wiki gets its own isolated session directory:
wiki_sessions/
├── {hash_of_wiki_a}/ # Cookies, storage for Wiki A
├── {hash_of_wiki_b}/ # Cookies, storage for Wiki B
└── ...
Comparison to browsers: Similar to browser profiles - different wikis cannot access each other’s cookies or local storage.
The <$action-run-command> widget requires explicit user confirmation by default:
┌─────────────────────────────────────────┐
│ ⚠ Execute Command │
│ │
│ A wiki wants to run the following │
│ command: │
│ │
│ ./myscript.sh --arg1 value │
│ │
│ Do you want to allow this? │
│ │
│ [Cancel] [OK] │
└─────────────────────────────────────────┘
$confirm="yes")$confirm="no" for trusted commandsComparison to browsers: Browsers cannot execute shell commands at all. TiddlyDesktop allows it with user consent.
DevTools are disabled on all windows to prevent:
Capability-limited operations: File system access is restricted to specific operations defined in the capabilities:
fs:allow-read-text-file - Reading wiki and text filesfs:allow-write-text-file - Saving wiki filesfs:allow-rename - Atomic save operationsfs:allow-exists - Checking file existenceAtomic saves: Wiki files are saved atomically (write to temp file, then rename) to prevent corruption.
Path validation: All file paths are validated and canonicalized to handle symlinks and prevent path traversal.
Main wiki protection: The main TiddlyDesktop configuration wiki cannot be backed up over itself.
External drag-drop operations:
| Security Aspect | Web Browser | TiddlyDesktop-RS |
|---|---|---|
| Local file read | Blocked (requires user file picker) | Allowed for wiki and attachments |
| Local file write | Blocked | Allowed (wiki saves) |
| Shell commands | Impossible | Allowed with user confirmation |
| Cross-origin requests | Blocked by CORS | N/A - local files only |
| Cookie isolation | Per-origin | Per-wiki |
| JavaScript execution | Sandboxed | Full access to Tauri API |
| DevTools | Available | Disabled |
| Extensions/plugins | Supported | Not applicable |
| Network requests | Full internet access | Limited to localhost |
| Same-origin policy | Enforced | Not applicable |
OS-Level Sandboxing: Browsers use OS-level process sandboxing (seccomp-bpf on Linux, App Sandbox on macOS, etc.) to restrict system calls. TiddlyDesktop does not use OS-level sandboxing - instead, it relies on Tauri’s capability-based permission system and architectural separation between WebView and Rust backend. The WebView cannot make system calls directly; it must go through the IPC layer which enforces the permission allowlist.
Same-origin policy: Browsers prevent one website from accessing another’s data. TiddlyDesktop doesn’t need this since you’re working with local files you trust.
Content Security Policy: Browsers enforce CSP headers. TiddlyDesktop has CSP disabled to allow TiddlyWiki’s self-modifying nature.
Automatic updates: Browsers update security patches automatically. TiddlyDesktop requires manual updates.
Site isolation: Modern browsers isolate each tab in separate processes. TiddlyDesktop uses a single process with per-wiki session isolation.
Local file access: Direct file read/write without browser download/upload dance.
Atomic saves: Prevents wiki corruption that can occur with browser-based savers.
No tracking: No telemetry, no analytics, no cloud sync unless you configure it.
Offline-first: Works entirely offline with no network dependencies.
Shell integration: Can execute local scripts and tools (with confirmation).
Session persistence: Wiki authentication sessions survive restarts.
Only open wikis from trusted sources - A malicious wiki could execute commands (with your confirmation), read local files, or exfiltrate data.
Review command confirmations carefully - When a wiki asks to run a command, verify it’s expected and the command looks correct.
Keep TiddlyDesktop updated - Security fixes are included in updates.
Use HTTPS for authentication - When configuring external authentication, only use HTTPS URLs.
Don’t use $confirm="no" carelessly - Only skip confirmation for safe, well-understood commands.
Validate user input - If building wikis that execute commands based on user input, sanitize carefully.
Document shell requirements - If your wiki uses <$action-run-command>, document what commands it runs and why.
CSP is disabled (null) because TiddlyWiki:
A strict CSP would break core TiddlyWiki functionality.
Network access is restricted to:
127.0.0.1 and localhost on any port (for wiki folder TiddlyWiki servers)No arbitrary internet access from wiki windows.
TiddlyDesktop uses Tauri’s architecture with WebView2 (Windows), WebKitGTK (Linux), or WKWebView (macOS). Each wiki window shares the same process but has isolated session storage.
Security implications:
Why no OS sandbox?
TiddlyDesktop is designed to give TiddlyWiki full local file access for saving wikis, importing attachments, and optionally executing shell commands. An OS-level sandbox would prevent this core functionality. The security model is “trust the files you explicitly open” rather than “distrust all content.”
If you discover a security vulnerability, please report it responsibly:
This document describes TiddlyDesktop-RS v0.1.x security model.
Last updated: January 2026
Hi @BurningTreeC I’ve been testing some of the recent builds on Github, currently 0.1.42
Drag and drop (links and droppable) is working fine now in Windows!
I went in to do the auth and somewhere along the way the formatting seems to have broken a bit. It still functionally works, but the font (if it’s there) is invisible for things added to the list, and I doubt the !! there is meant to be visible, they’re probably related issues.
I’ll investigate @stobot !
About drag&drop handling… in the following builds I will probably break it a bit because I have to explore alternative solutions. All this because it should work consistently for all OS’s
Another idea @BurningTreeC , as MultiWikiServer (MWS) matures, I believe the roadmap was going to have some kind of desktop support eventually. I’ve not able to really try MWS out as I don’t have admin privileges to my main work computer, but your portable app works great. A TW MWS RS would be great!
I’m probably not the best person to answer that - @Arlen22 are you around the forums?
The valuable thing from a user perspective to me is the bags and recipes where you can kind of nest wikis. I’ll circle back to this later and add more detail if it’s helpful.
GitHub - TiddlyWiki/MultiWikiServer: Multiple Users, Multiple Wikis
Loving this new tiddlydesktop-rs - it works really well on apple silicon (macos) (after a sudo xattr -c /Applications/tiddlydesktop-rs.app to allow it to run as an unsigned package).
However one feature that the original TiddlyDesktop supports today but which I could not get to work with tiddlydesktop-rs is RW support for classic tiddlywiki’s as a single html file.
tiddlydesktop-rs seems to only have RO support, i.e., able to open & read the classic tiddlywiki but widget to create a new tiddler is not rendered and existing tiddlers only have a ‘view’ rather than an edit tiddler menu item.
Thanks to Tiddlydesktop I still have a working classic TW wiki file (from 2005 which I don’t want to migrate!) and so it would be great if tiddlydesktop-rs could support classic tiddlywikis too.
Thank you!
Hi @Vidya_S
Thank you for your feedback! How is drag&drop working for you on apple silicon?
I’ll investigate if I can make this work for TW classic, too… but I believe that’s a long way
On my apple macbook air M3 running latest MacoOS (26.2) DnD of a wiki file (html) onto the Wiki List canvas works fine.
DnD of an image file (like jpg or png) onto an opened single wiki file works fine - you get the green topbar and a dialogue and can import.
But this dialogue appears on all opened Wikis - not just the one on which it was dropped. So you have to cancel the import on the others.
Ideally the import dialogue should only appear on which it was dropped.
DnD of a standalone .tid or JSON tiddler does work (with import dialogue appearing on all open Wikis)
DnD of a tiddler or a plugin does not work - the green import topbar appears (again on all opened Wikis) but no subsequent dialogue to import and does not get imported.
BTW please please do consider support for TWc as well in your rust edition, even as longer term goal for it to be a complete replacement for TiddlyDesktop. 
Hi @Vidya_S this will be fixed in the next release! Thank you!
I’m currently actively working on that…
I’m considering it!
Basically MWS is an official server for TiddlyWiki. It stores tiddlers in a SQLite database (currently using the sync adapter mechanism) and supports multiple wikis at separate paths. I’ve designed it to be easy to add features to. I’m hoping over time we can expand it to cover as many online and local network use cases as possible.
The server and client can be used in a desktop app as well, since TiddlyWiki relies heavily on transferring assets between client and server via tiddlers, rather than directly linking them. In Electron or NodeWebkit, this is trivial, but I’m not sure how system webviews work, so it might be more difficult.
Bringing it into your application would require porting the application layer, which uses Prisma, but it would let you get rid of the external Node process and just serve everything via a custom protocol.
I’m guessing there’s a compromise here. If you want to avoid listening on ports at all, you could write a node addon in Rust to let you initiate the system webviews directly from NodeJS, and this would allow you to use the MWS server code directly, as well as all the other benefits that come with Node. You would just martial requests for your custom URL back to the NodeJS side.
Sorry, I’m not trying to say you’re doing it wrong. I love the innovation here, and my brain couldn’t help extending the idea. What you’ve got here looks like a really good idea.
It’s too bad you can’t just use the chromium rendering engine directly from Rust. Then you could just use whatever Chromium install you can find (Edge, Chrome, Firefox, Opera, etc) and just fire up the renderer as its own webview. There’s gotta be a way to do that somehow.
My understanding is Tauri is design specifically to piggybacks on OS’s builtin system browser, like webkit on Windows (which is thankfully chromium nowadays) so you don’t have to prepackage a whole browser application like with electron.
What I don’t know is if you can configure it to prefer/depend on a specific 3rd party backend IE chromium on linux or Mac.
Hi @BurningTreeC , I just loaded 0.1.55 in Windows (Portable) to see any updates. Noticed that the drag and drop kind of works, but in my standard workflow of links and drop-zones, it also “open” the dragged tiddler which it shouldn’t. Just a note.
One thought on an earlier comment I made about in-app upgrading is that as far as I know you can’t actually see what version you’re actively using. That might be helpful for debugging if nothing else.
Thanks for all your efforts here!!
Unfortunately for 0.1.57, yes.
Minimal test example:
[[Thing 1]] has category: {{Thing 1!!category}}
[[Thing 2]] has category: {{Thing 2!!category}}
[[Thing 3]] has category: {{Thing 3!!category}}
---
@@background:gainsboro;padding:5px 10px;<$droppable actions="""<$action-setfield $tiddler=<<actionTiddler>> category="CAT-A"/>""">CAT-A</$droppable>@@
@@background:gainsboro;padding:5px 10px;<$droppable actions="""<$action-setfield $tiddler=<<actionTiddler>> category="CAT-B"/>""">CAT-B</$droppable>@@
@@background:gainsboro;padding:5px 10px;<$droppable actions="""<$action-setfield $tiddler=<<actionTiddler>> category="CAT-C"/>""">CAT-C</$droppable>@@
Also, in trying to export this tiddler to json, I noticed another bug. Anytime I try to export tiddler, it doesn’t actually export and it saves instead
Oh wow @stobot , thanks for reporting! inserting the tiddler in the StoryList is totally unintended and I don’t recall having added anything like that 
For the second issue… there’s no “Download” indicator but it should land in your Downloads folder. The auto-save-wiki is normal behavior
Ahhhh - I don’t use the Windows download folder, but you’re right it’s fully of json files! I tell all of my browsers to download to desktop.