Tinderbox Meetup 19APR26 - DoNotDelete, CSV vs. TSV Export Templates, Onboarding, AI Images

Tinderbox Meetup 19APR26 - DoNotDelete, CSV vs. TSV Export Templates, Onboarding, AI Images

Level Intermediate
Published Date 4/19/26
Tags AI, CSV, DoNotDelete, Image Generation, Onboarding, TSV, Templates, 5CKM, 5Cs of Knowledge Management, Eastgate, Identity Praxis, Inc., Mark Berstein, Michael Becker, Tinderbox
Video Length 01:41:32
Video URL https://youtu.be/SxXyphs2cwM
Example File TBX - CSV vs TSV Template.tbx (148.8 KB)
TBX Version 11.5
Host Michael Becker

In this Tinderbox Meetup, we discussed how to ensure a note can’t be deleted, reviewed and demonstrated how to create CSV and TSV export templates, explored Tinderbox onboarding, and discussed using AI for image generation (i.e., challenges and solutions).

1 Like

A few clarification notes arising from discussion that meet-up.

$DoNotDelete a system Boolean added to guard against accidental deletion of notes, e.g. by an inattentive use of the Backspace key. Note that it does not stop actions deleting a note—though in the meet-up discussion this wasn’t the main focus. Note also this differs from $ReadOnly & $Lock. For the next refresh of aTbRef, the article fro those attributes will cross-link to $DoNotDelete and the latter will be mentioned in the article on Non-editable notes.

I’ve checked, and the $OnRemove action for a container fires both if a note is dragged out of the container or is manually deleted (q.v. above). It also fires if an action moves a child, e.g. a stamp or rule setting a new $Container for the note. Thus, a container’s $OnRemove might be set to show a waring using [show()] if the (show(msgString[, backgroundColor[, colorString, [durationNum]]])) there is a change in the number of child items (implementation of that should be raised ax a new thread, if of interest).

Back-ups: in the meet I stated the context of their use poorly (well picked up by @echuck!). The point I was raising but could have stated more clearly is that if notes (as opposed to aliases) have been deleted unintentionally, and none of the above ameliorations have helped, those notes will be in a back-up. Rather than roll-back to the back-up, save the back-up version as a discrete file and then copy/paste the missing items back into the main working file. The copy of the back-up file may then be deleted. But, the overarching point about the stability and regularity of background back-ups today as opposed to when Tinderbox started still stand.

3 Likes

Some More Thoughts about Onboarding:

I watched the recent meetup and wanted to follow up, because I realized part of the conversation was picking up on my earlier post — and I think the points raised deserve a proper acknowledgment from my side rather than a defense.

First: the criticism is fair. Mark is right that there’s something paradoxical about describing Tinderbox as a deliberately open-ended tool and then asking for a ā€œsimple onboarding.ā€ And he’s right that people engage context-first — if the example doesn’t map onto their own problem, the underlying pattern doesn’t land. Michael’s 9:1 observation is probably the most honest framing of all: the software is the cheap part, the cultural shift is the expensive part. I take all of that seriously.

I also agree with the broader point: at the end of the day, you learn Tinderbox by using it. And there will always be people who after one week are doing remarkable things with it, and people who after twenty years are still using it in a fairly basic way. Both are fine. There’s no single correct depth of use.

What I’d still like to put on the table — more as a contribution than a counter-argument — is a small observation from my own second attempt at learning the tool. My first attempt didn’t stick. The second one did, and the reason was that I stumbled into a compact mental model that made everything else click into place. As part of working through that, I built a spreadsheet cataloging Michael Becker’s videos and certain topical meetups (the ones oriented around concepts rather than specific workflows), and arranged them in a rough chronological learning order. That exercise taught me something I didn’t expect: the hardest thing to convey about Tinderbox isn’t any single feature — it’s the functional principle underneath all of them.

Here’s the version that worked for me. Everyone already understands the idea of notes written line by line — plain text, one after another. The leap into Tinderbox is realizing that every one of those ā€œlinesā€ can carry attributes: a timestamp, a priority, a source, a color, a status, whatever you need. That turns a note from a flat piece of text into something that knows things about itself. And once notes carry context, the rest of the system follows naturally: you can filter them, query them, let agents act on them, let prototypes shape them, let links connect them in meaningful ways. The whole system is just the consequence of that one shift.

And I think this is where a clearer early framing would genuinely help newcomers — not a scripted path, and not a constrained tutorial, but a short, honest statement of the shared vocabulary. Notes, containers, links, prototypes, agents. Those five building blocks are present in every Tinderbox document, whether it’s two hours old or twenty years old, whether it’s a recipe list or a doctoral dissertation. That constancy is reassuring, and I think it often gets lost because Tinderbox tends to be described somewhat cryptically — ā€œa tool for thinking,ā€ ā€œa tool for notes that grow.ā€ True, but abstract. A newcomer arrives looking for a technical handle, something concrete enough to form a first mental picture. The five building blocks are exactly that handle.

One reason I keep circling back to this is that I come to Tinderbox from a slightly different angle than most of the forum: I work as a content creator and media designer, so I tend to think about how information is delivered, not just what it contains. And I’ve been playing with the idea — inspired by Michael Becker’s videos, not as a critique of them at all — of what an even more condensed, slightly more visual introduction might look like. Michael’s library is a genuine gift to the community and goes deep where depth is warranted. What I’m thinking about is complementary: a very short, graphically supported piece that just nails the core principle before anything else. Because I think one thing that quietly happens is that Tinderbox gets framed as inherently complex from the first sentence onward — and that isn’t always true. You can make notes, give them attributes, organize them in containers, and use agents as smart filters that group things by their properties. That isn’t a complex level of use, but it’s already enormously capable, and it’s the same foundation every project rests on, regardless of scale. In principle, the core concept is something a ten-minute onboarding video could genuinely convey.

None of this contradicts the meetup’s point. You still have to use the tool. You still have to bring your own work to it. You still have to accept that the real investment is in yourself, not the license. But giving someone the shared vocabulary on day one doesn’t reduce Tinderbox to paint-by-numbers — it just lets them stop being lost in the first hour and start being productively confused in the second, which is a very different experience.

That’s really all I wanted to add. Grateful for the discussion.

Iā€˜ll try my best to come up with an idea for a condensed onboarding video. Iā€˜ll share the script as soon as Iā€˜m done. After some feedback Iā€˜ll go on producing! (:

4 Likes

A Stepped Model with Plateaus

Picking up from the last post — I want to get more concrete about what I actually think is missing, because on reflection it’s much smaller than it might have sounded.

Most of the hard work is already done. Michael Becker’s video library is, honestly, a remarkable resource. It’s thorough, it’s patient, it’s deeply informed, and for anyone willing to sit with it, you can learn the fundamentals of Tinderbox in a surprisingly short amount of time. Layer on top of that the forum — which, for all the ā€œnew users feel out of their depthā€ observations, remains genuinely generous when asked clear questions — and the raw material for learning the tool is all there.

So what I’m really proposing isn’t a new curriculum. It’s a chronology and a leveling laid over what already exists. A map to the resources, not a replacement for them.

The idea behind the structure below is simple: every level should be a place you can genuinely live in. Not a stepping stone you’re forced off as soon as you arrive, but a stable way of working that’s complete in itself. Some people may spend an afternoon on Level 1 and move on. Others may stay there for months, and that’s equally valid. Progression happens when the material itself asks for more structure — never before. This is essentially Mark Bernstein’s concept of incremental formalization from The Tinderbox Way, applied to the learning curve itself: you add complexity when the content calls for it, not because the tool offers it.

Level 0 — Introduction: What Tinderbox Actually Is

Most people already know what notes are. You write something down — a thought, a quote, a task, a piece of research — give it a title, put it somewhere. That’s the baseline, and it’s what every notes app in the world shares. Tinderbox doesn’t replace that idea. It extends it.

The one shift Tinderbox asks you to make is this: what if every note could also carry information about itself? Not just a title and some text, but also a date, a source, a priority, a status, a category, a color, a confidence level — whatever the work actually needs. These pieces of information are called attributes, and together with the title and the body text that the note already has, they’re what makes a Tinderbox note different from a note anywhere else.

Once a note carries attributes, something quietly changes. The note is no longer just a piece of text — it becomes an object with properties. And once your notes have properties, you can do things with them that a plain notebook can’t: filter them, group them, compare them, connect them, let the system watch for patterns, let it respond when something changes. You can start to set up simple rules that react to those properties, so that the document begins to organize itself as you add to it.

From that point on, a Tinderbox file stops feeling like a list and starts feeling like a network. Every note contributes to the whole. Every attribute gives the system something to work with. Every link expresses a relationship. You build up a multi-dimensional web of your own material — and because the system understands the metadata you’ve given it, it can help you see that material in ways your unaided memory cannot.

That is really the entire underlying idea. Eastgate describes Tinderbox as a tool to visualize, analyze, and share your ideas, and the levels that follow are progressively deeper ways of doing exactly that. Level 1 is the pure notes. Level 2 adds the attributes that give notes context. Level 3 lets the system start organizing itself. Level 4 lets it act on its own. Level 5 connects it outward to the rest of your work.

But the principle at the heart of all of it stays the same throughout: notes with context, arranged into a network, that you can think with rather than just read.

Level 1 — Capture

Notes, containers, text. That’s it.

Just writing notes and putting them somewhere. A note has a title and a body. A container holds notes. You can move things around, rename them, delete them. The outline view is enough. No attributes yet, no prototypes, no agents.

This level is already a complete tool. Many people use Tinderbox this way for quick project files and never need more. If all you want is a flexible, outline-capable notebook with spatial rearrangement, you can stop here.

Level 2 — Context

Adding attributes to notes. Using views to see them differently.

This is the first real Tinderbox-specific shift. A note stops being just text and starts carrying metadata: a date, a status, a source, a priority, a color, whatever the work asks for. Once attributes exist, the Attribute Browser becomes useful, the Outline view gets more informative, and the Map view starts showing patterns you couldn’t see before.

This level is where Tinderbox begins to feel clearly different from other note apps. And critically, it’s already enormously powerful. A reading-notes system, a research log, a meeting-notes archive, a project tracker — all of these work beautifully at Level 2 alone. You can live here for a long time.

Level 3 — Structure

Prototypes for inheritance, links for meaning, agents as smart filters.

Now the system starts organizing itself. Prototypes mean you define a kind of note once and all notes of that kind inherit from it — change the prototype, and every note that uses it updates. Typed links mean connections between notes carry meaning, not just existence. Agents continuously watch your document and gather notes that match a query, updating themselves as your material changes.

This is where the famous Tinderbox ā€œaha momentā€ usually happens. Watching an agent pull notes together automatically, based on attributes you set, is genuinely different from anything most people have used. Plenty of experienced users operate at Level 3 indefinitely and never feel they’re missing anything.

Level 4 — Behavior

Rules, edicts, OnAdd actions, Action Code as something you actually write.

At Level 3 the system reacts to how you categorize things. At Level 4 the system acts on its own. A rule recalculates an attribute every time the note changes. An OnAdd action applies a prototype the moment a note is dropped into a container. An edict runs on a slower schedule for expensive computations.

This is also where Action Code stops being a curiosity and becomes a working language. Not the full reference — just a small vocabulary of common patterns. Most users who reach Level 4 use maybe a dozen operators comfortably and leave the rest for when they need them.

Level 5 — Integration

Import, export, publishing, AI, cross-tool workflows.

Finally, Tinderbox as part of a wider ecosystem. Pulling data in from DEVONthink, Bookends, spreadsheets, or plain files. Exporting to HTML, Markdown, or fully designed PDFs. Using the AI features. Building templates that produce polished documents. Moving notes to and from other tools in your stack.

This is the most open-ended level, and it’s also the one where paths diverge sharply depending on what you actually do. There isn’t really one Level 5 — there are many, shaped by each person’s work.

Why this shape, and why plateaus matter

The reason this is split into five working levels (plus the introduction) rather than a shorter sequence is that each one represents a genuinely different mode of working — which maps, I think, onto the distinction Mark Bernstein draws in The Tinderbox Way between taking notes, thinking with notes, and analyzing through structure. Level 1 is capture. Level 2 is giving your material enough context to be thought about. Level 3 is letting structure emerge from the material. Level 4 is letting the system carry some of the cognitive load. Level 5 is connecting the whole thing outward.

The plateau idea matters because it gives people permission to stop. One of the quiet frustrations of learning Tinderbox is the sense that you’re supposed to eventually ā€œuse everything.ā€ You aren’t. The tool is designed to be useful at any depth, and a Level 2 user doing careful, attribute-driven reading notes is not doing Tinderbox ā€œwrongā€ because they haven’t written an agent yet. They’re simply at the level their work currently needs.

Incremental formalization, in this framing, is the engine that moves you between levels — but only when the content itself calls for it.

Closing thought

I realize this is a lot, and I want to be clear about what I’m actually proposing. Not a new curriculum. Not a criticism of any existing resource. Just a front door — a short, explicit, leveled path through the material that already exists, with the early levels stripped down to the absolute minimum a new user needs to feel they’ve arrived.

If any of this is useful to anyone building or revisiting introductory material, I’d be glad to contribute. And if it isn’t — no harm done, and thank you again for the discussion that got me thinking about it in the first place.

4 Likes

Thanks for this and glad you saw that my picking up on the central conundrum wasn’t critique. There is a challenge. I’m in writing purdah as present so worn’t respond at length but I’ve noted this to return to in coming weeks.

A challenge I see is we’ve (societally) largely educated ourselves out of long-form learning, i.e. something involving more time/effort than ā€˜just’ watching a video (and that isn’t devaluing @satikusala wonderful trove of recordings). Rather, how to get people to engage other than coupled to their immediate desired outcome. Not least, the latter is often wrong, insofar as analysis of the task at hand as the best way to progress is often flawed. Most often because it is a vicious loop of: ā€œI used to use app X but can’t do this task, how to I use Tinderbox to resolve this but in the style of app X?ā€. How you nudge people to think more in the terms of what does doing X involve.

Your 'ā€˜levels’ deconstruction makes sense but my experience this results in something too abstract for most people (which includes this who want/need to learn the app). My past decades of consulting reinforces that hunch.

I’m not sure I have an answer, other than (in my case) documenting things people might need.

1 Like

I’m happy to pitch in, if that is desirable, but for now I think gazing on with admiration is what (with this cold >cough) I am capable of doing.

1 Like