Ostensibly a successor to VoodooPad, MojoPad swims in the same lake as Tinderbox.
I linked to the manual because I really couldn’t get a good idea of what it was about. I may try it in demo mode, but probably not. I’ve got enough things to do and learning another app is not one of them. (Except for Parallels and LoopCaD, because hydronic heating design apps don’t run on MacOS. Le sigh.)
Just tossing this in the mix. First read about it at Bicycle for Your Mind.
I’m not sure about the app, bur the blog was worth looking at. Some thoughts on outliners, especially EMACS and OmniOutliner but nothing I could see on Tinderbox.
Thanks for sharing this.
But the link-to page says:
A MojoPad document is a personal wiki
A wiki. Something Tinderbox is not. It might look like a wiki. It might cover the same ground as a wiki. But, a wiki is structurally a different thing. Does this matter to the user? Perhaps not, but whilst cows and horses both have four legs, getting milk from a cow is easier than from a mare.
The wiki’s lineage is the Web (1990, or publicly 1993). Tinderbox’s lineage is hypertext (c.1960s). This is not a zero-sum good/bad assessment, but I think there is some difference. The most obvious being wikis only have text-embedded links—HTML-style links hard coded in to a note’s text. Tinderbox uses the now-less-seen Linkbase notion, i.e. links stored outside the note. At casual use level, to the user, the two look the same. Go a bit deeper, and I think a linkbase offers a wider scope of affordances. Not, this still isn’t a binary assessment of worth. difference can still be meaningful difference without an implicit ranking (based on what criteria?).
I ought to get out more, but I’ve a stack of old Hypertext papers to read. 
Hmm.. I just tried the link to the Mojo site and my Safari refused to connect because it could not establish a secure connection.
FWIW, no such issue on my Mac (macOS 26.5.2, Safari v26.5.2 (21624.2.5.11.8)), when I first used the Mojo link above, or when trying it now.
[Edit: clarification. The above doesn’t negate @pvonk’s observation of their system but I posted only to indicate it might not be globally ‘bad’ access.]
I am using the same versions of macOS and safari. I’ve tried using links to MojoPad from other websites that have their own links to MojoPad, same result in all cases (as I would expect, since the same link was being used). I must have Safari set up with higher security. But I sort of recall reading about the successor to VoodooPad (which I used a decade or two ago), and felt it was a bit too limited for my work these days.
In addition I tried the link with DuckDuckGo and that gave the error: “A TLS error caused the secure connection to fail.” Ah, but Chrome was able to reach the site.
Oh well, after reading some of the pages of MojoPad’s documentation (in Chrome), I clicked on one of their links in the left side panel and now I get “This site can’t provide a secure connection
mojopad.app sent an invalid response.
ERR_SSL_PROTOCOL_ERROR”
Any other links also result in the same outcome.
I don’t have an issue accessing the site or getting SSL errors. I wonder if it could be something network related, or related to a particular security software.
I think the universe is just trying to tell me something. 
“MojoPad is an Electron application” (from the Bicycle for Your Mind review) stopped me there.
So. I went down the MojoPad rabbit hole. I imported some markdown files and clipped a few webcites with the Mojopad web clipper. Whtat I ended up with was a beautiful UI that was all hat and no cattle. I was totally lost as to what to do with it. In the MojoPad Discourse discussion grouop https://mojopad.discourse.group/ I found a post from a new user that devled into learning structures of which I knew nothing about. So I asked Gemini to explain to me what the post was about. Here is the question to Gemini and the conversation that followed:
ME: My question to Gemini is__what was the original poster Lerone talking about? And please, explain this to me in terms of what has been my background with the structure of Obsidian (YAML properties, bases for table views, and the Outliner plugin) and Tinderbox (attributes and multiple views of notes).
Gemini: What Lerone Was Asking: The Core Dilemma
At its heart, Lerone’s post asks: “If I split my knowledge into multiple separate MojoPad wikis/documents, how do they talk to each other?”
Coming from Obsidian and Tinderbox, you are used to having a single, massive workspace—or at least very flexible ways to cross-examine data across your entire repository. Lerone wanted to know if separate MojoPad files (which MojoPad calls “documents” or “wikis”) can share connections, semantic indexes, graphs, or automated links.
Breakdown in Terms of Your Tools: Obsidian & Tinderbox
To understand what Lerone and Mark (the developer) are discussing, it helps to map MojoPad’s architecture against the mental models of Obsidian and Tinderbox.
[This output was structured in nice tables via Gemini]
1. “Documents” vs. “Vaults” vs. “TBX Files”
Obsidian: You generally have one large Vault. Inside, everything lives together—YAML metadata, Dataview tables, tags, and [[wikilinks]] can query across thousands of notes seamlessly.
Tinderbox: A .tbx file is a self-contained world of attributes, prototypes, and spatial views (Map, Outline, Chart). While you can script or copy between files, a Tinderbox file is fundamentally its own environment.
MojoPad: Functions much like Tinderbox files or separate Obsidian Vaults. Each MojoPad “document” is a completely self-contained folder on your disk.
2. The Limits of MojoPad’s Scope (The “Document Edge”)
Lerone wanted to organize notes into separate topical wikis (e.g., one wiki for Theology/Scripture, one for History, one for Personal Journals) to keep things clean. They were asking whether MojoPad’s intelligent features could bridge those separate wikis.
Mark Busse confirmed that inside a single MojoPad document, the app acts like an automated combination of Obsidian and Tinderbox:
Automatic [[wikilinks]]: Auto-links text based on page titles as you type.
Semantic / On-Device AI: Performs semantic analysis (“Ask AI” / Related Pages) using local embeddings.
Living Graph: Renders a connected map of your concepts.
However, none of this crosses the border between two different MojoPad documents.
3. Comparing the Cross-Document Approaches
Feature
Obsidian Equivalent
Tinderbox Equivalent
MojoPad’s Stance
Search
Global search across all folders/files in a Vault.
Search within a single .tbx file (or multi-file spotlight).
New Feature: You can manually trigger a search across other MojoPad wikis on disk.
Metadata & Meaning
Dataview / YAML properties queries across all notes.
Attributes, Prototypes, and Agents analyzing notes.
Strictly isolated. Semantic AI, backlinks, and auto-linking do not look into other wikis.
Deep Semantic Blending
Community plugins (e.g., Smart Connections, Omnisearch).
Complex Agents / Rules linking attributes across spaces.
Not supported natively. Mark calls this a “hard design problem” and intentionally limits it to prevent noise.
External AI Access (MCP)
Community AI plugins connected to local folder.
AppleScript / Command-line integrations.
Supported. You can point an external AI agent (via Model Context Protocol) at multiple wiki folders to query them all.
Export to Sheets
What Lerone Means by “Conceptual Blending” and “Atolls”
In the latter half of the post, Lerone references DEVONthink and cognitive science theories (Conceptual Blending by Fauconnier & Turner):
The “Atoll” Metaphor: Lerone views knowledge as islands that look separate on the surface, but share a single “reef” underneath. In DEVONthink, opening multiple databases creates a shared “concordance” (a combined semantic index) where related documents across completely different databases are automatically suggested.
The Difference in MojoPad: MojoPad does not create a shared underlying semantic index across files. If you keep Scripture citations in Wiki A and Book Notes in Wiki B, MojoPad’s native AI won’t automatically surface connections between them. You would either need to:
Keep them in one single MojoPad document (using folders, tags, or page-tables to structure them).
Use an external AI agent (MCP) to read both folders and analyze the connections for you.
How This Applies to Your Workflow (YAML, Attributes, & Structured Notes)
If your current workflow relies on structured metadata (e.g., YAML properties in Obsidian for Index Term, Declarative Sentence, Scripture Citations, or Tinderbox Attributes/Prototypes):
MojoPad is Page-Centric, Not Heavily Attribute-Centric: While MojoPad supports “Pages as Tables” (sorting, filtering, and fields), its core philosophy is driven by plain text, automatic linking, canvas spatial thinking, and on-device semantic search rather than deep attribute-based queries like Tinderbox’s Agents or Obsidian’s Dataview.
One Document vs. Many: If you want your claims, Scripture references, and book notes to interact automatically via AI or auto-links, do not split them into multiple MojoPad files. Keep them inside one MojoPad document, using tags or folders to organize them.
Me: Thank you, this is helpful. My next question, does MojoPad provide any advantage over my Obsidian (original capture from Kindle, or web clipper via the Obsidian webclipper that does structure the content and meta data from Youtubes very nicely), then import the processed markdown files from Obsidian into Tinderbox? I realize I can import these markdown files originally processed in Obsidian into Mojopad. But what do I do with them once the markdown files have been imported into MojoPad?
Gemini: The short answer is no—if your current system is already working smoothly, MojoPad does not offer a technical advantage over your Obsidian + Tinderbox pipeline.
In fact, replacing Tinderbox with MojoPad for your specific structured note workflow would likely feel like a step backward in analytical depth.
Here is an honest breakdown of where MojoPad fits, why your current workflow is superior for your needs, and what would happen if you imported those markdown notes into MojoPad.
1. Comparing the Architectures: Obsidian + Tinderbox vs. MojoPad
Your current setup represents a best-of-breed pipeline:
Obsidian (Capture & Structure): Excellent for web clipping (YouTube, Kindle highlights), YAML frontmatter metadata structuring, and rapid Markdown entry.
Tinderbox (Deep Analysis): Unrivaled for spatial synthesis, attribute-based querying, prototypes, agents, and complex visual mapping across extracted elements (declarative sentences, claims, scripture citations, etc.).
By comparison, MojoPad is a “hybrid” desktop wiki. It tries to combine a note editor, canvas, spatial outliner, task manager, and local AI into a single application.
Dimension
Your Current Pipeline (Obsidian + Tinderbox)
MojoPad
Structured Metadata
Extremely Strong. Obsidian YAML/Dataview handle frontmatter; Tinderbox converts them to native Attributes and Prototypes for deep querying.
Basic. Has “Pages as Tables” for sorting/filtering, but lacks Tinderbox’s powerful Agents, Action Code, or Boolean rules.
Semantic & Spatial Analysis
World Class. Tinderbox offers Map, Chart, Treemap, Attribute Browser, and Agent views to slice data along any dimension.
Moderate. Has a spatial canvas and a automatically generated living graph, but lacks Tinderbox’s rule-based visual structure.
AI Capabilities
Optional via plugins (Smart Connections, local LLM scripts).
Native & On-Device. Has built-in local AI for reading/summarizing books and asking questions across a single wiki without cloud dependencies.
Ease of Use
High friction across two distinct apps, but infinite depth and power.
Low friction—all-in-one “playground” app, but shallow compared to Tinderbox’s analytical power.
2. What Happens When You Import Obsidian Markdown into MojoPad?
If you were to import your processed Markdown files (containing Kindle quotes, Scripture citations, declarative sentences, and YAML metadata) into MojoPad, here is what MojoPad would do with them:
Auto-Wiki Linking: MojoPad will scan the page titles in your imported files and automatically convert matching phrases throughout your text into clickable wiki links.
Local AI Semantic Indexing: MojoPad will index the text using on-device embedding models. You could then ask its built-in AI assistant questions like “What claims are made about Romans 8 across my book notes?” and it will answer with cited passages.
Living Graph Generation: It will plot all your imported notes on a visual node graph showing which notes link to each other.
Canvas Placement: You can manually drag these imported Markdown notes onto a MojoPad spatial canvas to arrange them visually.
What it Cannot Do (That Tinderbox Does):
It will not parse your custom YAML metadata into rich, querying attributes the way Tinderbox does with prototypes.
It will not run automated rules or agents (e.g., “Find all notes where Type = Claim AND Scripture = Romans 8 and group them visually on a map”).
It will not give you Tinderbox’s deep, custom spatial views (Attribute Browser, Treemaps, Hyperbolic Views).
The Verdict
Stick with Tinderbox and Obsidian.
MojoPad is designed primarily as an all-in-one alternative for people who find managing Obsidian plugins too cumbersome, or who find Tinderbox’s learning curve too steep. It provides a quick, integrated environment with a decent outliner, simple spatial canvas, auto-linking, and local AI.
However, for a rigorous, highly granular semantic workflow—where you are extracting discrete elements like index terms, declarative sentences, claims, and Scripture citations—Tinderbox remains the undisputed gold standard. Importing your structured Obsidian notes into MojoPad would result in losing the rich attribute-based power you already enjoy in Tinderbox.
Me: Thank you. Another rabbit hole I can safely avoid!
Gemini: Amen to that! PKM (Personal Knowledge Management) tool exploration is one of the most enticing “productivity traps” out there. It’s so easy to spend weeks migrating notes and tweaking architectures only to realize your original setup was already doing the heavy lifting.
You have a top-tier pipeline with Obsidian handling high-speed capture and metadata frontmatter, and Tinderbox providing unmatched analytical, spatial, and attribute-based synthesis. That combination is a powerhouse for serious research.
Save yourself the migration headaches and stick to building out your ideas rather than rebuilding your digital workshop!
Interesting read, thanks.
Frankly, the idea of automated wiki links sounds like a nightmare of distracting noise.
automatically convert matching phrases throughout your text into clickable wiki links.
I’m sure that’s a feature which demos incredibly well at small scale.
On aspect of hypertext dropped by Berners-Lee’s Web was storing links in the text’s code) and thus making all links the equivalent of what Tinderbox cals ‘text’ links, with the need for visible anchor text. Early wiki’s, where CamelCase anchor text formed the anchor text narrowed the understanding—of the casual user—even further: anchor text is the title of the link-to object.
Links don’t have to be seen to exist: in Tinderbox it is possible to have a richly linked document and use views that never display any links in the view pane. It is surprising how narrow the thought/design of many noting tools has become as designers seek to improve but rarely—if ever—look back to a much richer noting past. The point is not a qualitative better/worse but a sadness the designer’s of today’s note-taking app have such a narrow perspective on what the user might need.
I don’t see the point in posting 1,700 words of AI blather about some random app, rather than a concise personal opinion.
