Slipbox workflow


If you publish your slipbox online, write into hidden notes by default

Creativity requires the absence of censors.

How to stay creative while editing a published page?🔗

When you feel unwilling to edit a page because "that'll mess it up", you have a few options to unlock the freedom to be creative:

  • attach a :noexport: tag while you edit, so there's no risk you upload this mess to the web
  • make a new page and copy most of the content (You can always write a new page on the exact same topic), then axe content as you please
  • work first in a daily-page, and paste the completed work later
  • (some people suggest this) learn to trust in version control
    • doesn't really work for me, since even if I can recover work, I'm not confident that I'll remember there was anything good to recover

You can always write a new page on the exact same topic🔗

OK. Let's say you have a portal-page that systematizes a topic. If you realize you want a different kind of systematization… you can ALWAYS write a new page, and keep both.

Refile "frozen artifacts" back into dailies

Sometimes I have a note that's less a true slipbox-note, more an essay or a rant. Then one of two things happens. I may refine it for many months or years, like Nutrition science, or it loses relevance and I no longer want to update it.

I may even find it hard to update because it constructed a narrative that I don't want to disrupt.

If you recognize that, congratulations! You have what I call a "frozen artifact", or what some call "timeful content". The stream in The Garden and the Stream. What to do? Throw it down the stream. Refile it into dailies, so it's out of the main slipbox.

We write timefully by default

I'll bet that most things you've ever written has been timeful, i.e. you would now regard them as artifacts handed down from your past.

Things like school assignments, internet comments, emails, chat histories, diary entries… even many articles and essays are no longer so interesting as when you wrote them.

Maybe if you've written flashcards, cheatsheets, or personal-wiki content, you've written some timeless content, but it's difficult, right? We tend to write things that peg our text to a point in time—the now—and ensure it will age like milk instead of aging like wine.

Especially when we can't resist embedding our opinions. The resulting text may be embarrassing to read later on, since most of our opinions, we actually have weak reasons to hold. Maybe as we grow with the slipbox, we develop more nuanced/reflected opinions.

Reusing frozen artifacts

Anyway, there's no need to consign all those millions of words to the flames. You can reuse them. But tending your slipbox involves care so it doesn't become a "graveyard of notes". Reuse with subtlety.

When my slipbox was new, I was excitedly going through decades of braindumps and seeing what was still relevant that I could fit into my system. This is the sort of activity that's hard to do wrong with a handwritten slipbox, but hard to do right with a digital slipbox.

Separate these goals in your mind:

  1. Being able to find this old thing you wrote back then, using the amazing convenience of the slipbox software
    • Just import the artifact as-is… into dailies, under some date long long ago.
  2. Integrating insights into your main slipbox
    • Probably you can grasp the central insights you were getting at when you wrote this artifact. Write all-new notes about those insights, as if you were reading someone else's text.

Write when insights hot🔗

In my experience, it's hard to make good notes weeks or months after reading something. It's best in that piping-hot moment when the insights are fresh in my mind.

Have you ever marked paragraphs in a book to revisit in the future? It feels good, but it's a false feeling of productivity – instead, paraphrase in a separate notebook or device, right away!

In fact, it may be harmful to passively mark paragraphs because Recognition is deceptive: when (if ever) we revisit what we marked, the feeling of recognition makes us think we understand the subject so it's harder to tell just which knowledge it is that we could not regenerate—which insights won't come to mind when we most need them. Reading without writing creates a false sensation of learning.

Another compelling reason:

Eliezer Yudkowsky once tried to re-write the material that went into Book: Rationality: AI to Zombies, but he failed: the test readers said this re-written material lacked the "Yudkowsky charm". I find this concerning to all who want to take good notes, because it appears that even the person who originally wrote an intuitive explanation cannot do it twice!

I guess it's because after too much mulling over the same insight, it'll have become too clarified in our minds and we can no longer see what was so difficult about it (the curse of knowledge). And then we cannot find the most pedagogical way to express the idea.

Best to write when we first encounter the idea, while we're still a bit confused about it.


Treat books as read-once consumables

May be good to borrow books instead of buying them.

Why? When you own the book yourself, you get the option of lazily marking paragraphs to deal with later, and that freedom may harm you. By borrowing it for just a week, you're forced to take your own notes.

You don't need a steadily growing personal library at home, just a steadily growing slipbox.

A hot tip: libraries are often happy to take your suggestion for new books, so if they don't have it, just request it.

Design of nodes


The "tweet version" of the note. A concept handle.

Don't waste energy upfront thinking of the perfect title – you can change the title later, after writing the note.

Untitled notes

I haven't tried this as of <2023-Oct-01>, but to emulate Luhmann's paper slipbox, you could try leaving many notes untitled.

In org-roam: press RET twice to get past the title prompt, if you've configured the capture template to name the file randomly anyway.

You no longer get much use out of org-roam-node-find. And that's ok because we have consult-grep and ilk. But org-roam-node-insert needs a replacement, that picks a note based on a body-text-search. TBD.

Noun title vs. statement title

Seems that while learning a new topic I'm prone to make a lot of "noun nodes", as if writing for Wikipedia. Probably because the first question in my mind about a topic goes something like "what is this?" More sophisticated questions like "why and when to use this?" come way later, after I know what it is.

I'd prefer to make "statement nodes"; Andy Matuschak argues that they are more useful by e.g. letting you more easily atomize to one-idea-per-note.

When reading a lot of new info, try to stay in a book-note (or daily-note), where you're free to organize by noun, and later refile what you can to new statement-titled notes.

Tag "everything-nodes" so the grapher can ignore them🔗

Do you visualize your node graph? I'm talking about software like org-roam-ui and Logseq. I ran into a problem I call "everything-nodes".

An example of an "everything-node" would be if you made a node called "History" that links to the histories of every single topic, which in turn link to… every topic. How does this look when you graph the nodes visually? You'll have a central node around which your network ties itself in knots. It'll be harder to see any interesting structures in the network.

Invent a tag for such nodes, let's say :dontgraph:, and configure the grapher to exclude them.

  • For Logseq, there is the per-page property :exclude-from-graph-view: true.

Use transclusion for writing about history🔗

I like to write about the history of a specific topic as well as about specific people that lived in the past. Obviously, these overlap. How do I avoid duplicating content, writing the same facts in several places?

A trick is to think of "history notes" as compositions of "people notes", chronologically ordered. Just transclude the text from those notes. A drawback is that when you deal with people like Newton or Aristotle who influenced almost every topic, resulting in irrelevant material when you want to focus on a specific topic. For these people, you can make an exception and not transclude, instead write a summary of how they impacted this subject, and of course leave a hyperlink to that person. The same how Wikipedia does it.

If we really want to avoid duplicating content, I suppose each "people note" could have subheadings for how they influenced each topic, and we'd transclude only that subheading.

This feels a bit artificial. Maybe better to do it the other way around. Let the people-notes stay as empty stubs and just link to them whenever writing about them from anywhere else.

Qualify forward-links

Try to minimize appendices of "Related"/"See also" links by qualifying how the linked topics relate. After you've qualified them, the link can often be moved into the main text.

Even if they stay in "Related", it's nice to see a couple of words pointing out why they're related.

(I'm not talking about backlinks i.e. "What links here" – that section's ok.)

Exploring the collection

  • Rely on dense linking
  • Rely in part on taxonomy in so-called topic-notes or "portals", while accepting that such a taxonomy won't be complete and that's okay
    • In the metaphor of a directed graph, these nodes are the start points
  • Rely in part on pseudo-tags: empty pages with titles that start with a hashtag (#). They're the inverse of portals because they link to nothing themselves and contain no text, but lots of pages link to them, so they have massive backlinks
    • In the metaphor of a directed graph, these nodes are the end points
  • Use different methods of exploration now and then, for a fresh look at the material
    • Generate a visual graph (with org-roam, there's org-roam-ui)
    • With org-roam, use Delve sometimes
    • Use fulltext search (consult-grep) when title search isn't satisfying

Don't tag in an Org-mode knowledge base🔗


In Emacs Org-mode, tagging is a wild-goose chase. Don't tag just because there is a "tag" system. From what I read, it's different from the "tag" system in most slipbox software, like Roam Research, which have something they call "tags", but they're just a different way to write links. A close Org equivalent would be a page that starts with a hash symbol, i.e. the hash symbol forms part of the title—end of story.

When you need a real Org tag, you'll know.

Example: I use Org tags to filter out some notes when I run org-publish. Tags can also mark org-drill flashcards, or mark stub-pages so I can grey out their links. So, strictly technical purposes, not to do with classifying the content in a way that matters for exploration ("math", "literature", that kind of category, don't do it).

Pros of hierarchy

I had this problem when I was trying to keep a good mental model of my Semantic Synchrony graph. A surprisingly nice thing about linear (including tree-hierarchical) text that I didn’t notice until I had a knowledge graph is that there’s a natural traversal you can measure your reading progress against. That is, it’s much easier to know “I’ve read 40% of this text file” than “I’ve read 40% of this knowledge graph.” Your knowledge-graph files are likely to reference each other in a circular manner – that’s why they have to be a graph, not a tree.

The most natural solution would be to write code that creates a topological sort of the files, based on something like Kahn’s Algorithm.

But my solution, and it’s the most common one, is to simply not know what’s in the graph very well. The guy who invented Zettelkasten said navigating his knowledge graph was (eventually, after it was quite big) like conversation – it often surprised him.

Some software, including org-roam v2 and Logseq, have the wonderful property that notes need not be tied to disk files in the sense of one-note-per-file. This means you get to have hierarchy when you want to: you can write a very large note without needing to look at it as an indivisible chunk – any section therein can be registered as a complete note of its own, while staying part of the large document also.

Of course you could just have notes that are a hierarchical list of links to atomic notes, but sometimes it feels more natural to write a linear document without linkifying every last thing.

Acyclic slipbox?🔗

Imagine you want to print out your notes. Maybe for your future amnesic 70-year old self. Before it's possible to sort them to easily read in sequence, they have to be acyclic, meaning that the whole network of hyperlinks form a DAG (directed acyclic graph).

I think it's silly to put in a lot of effort just to enable a sequential printout, but I'm wondering whether imposing acyclicity can also help the sense of logical structure, and help whoever walks the notes to not walk in circles.

Of course a knowledge base worth anything must be circular, but it may be possible to impose that it only be circular when you count backlinks, and fully acyclic when counting forward-links only.

Maybe it'd also result in more distinct structures when the graph is plotted visually. Even better, maybe you'd find yourself hashing out more clearly what ideas depend on (are enabled by) as opposed to what they enable (are dependencies for).

I am concerned it could obscure connections. Because backlinks are automated, you can't add info to them, but you may really want to write "this idea enables X, Y, Z because…" as well as "it depends on A, B, C because…"

Anyway, might be easy. Write some command to find the minimum, then snip those links if it makes sense to. If it doesn't, consult a different feedback arc set (there are many sets, for any given graph). Or instead of snipping, move some links so that instead of A -> B, you have B -> A. Bam, the cyclic becomes acyclic!

Repeat the process every few months as a kind of quality-control routine.

Give up on persuading anyone, so perfectionist paralysis won't strike🔗

In other words, write not persuasion pieces, just explain your process.

LW user johnswentworth claims that this habit promotes better epistemics than the high-school habit of researching everything you want to say because you fear saying anything shaky:

You don't need to do any research! Just explain how you got to where you are. And the nice, sweet, crucial benefit is that you're freed to just publish, publish and publish. Less time-sinks blocking your way.

As a side-effect, it's better for the audience:

Point is: the amount of uncertainty I should assign depends on the details of my process. It depends on the path by which I reached the conclusion.

This carries over to my writing: if I want to accurately convey my uncertainty, then I need to accurately convey my process. Those details are relevant to how much certainty my readers should put in the conclusion.

Lessons from untitled paper notes

Luhmann didn't necessarily title notes, he just numbered them. So titles are not necessary, only links are. (Mandatory titles clash with Luhmann)

Compressed titles can make great concept handles (see Why publish?), but I cannot title a note well until after I've written most of the body. Try to start with an untitled note, and title it later.

We could use a workflow for developing untitled notes. The digital medium has some drawbacks compared to paper if we don't carefully program in equivalent functionalities.

Benefits of paper:

  • Locality. Newer notes tend to come later, in chronological order, so it's very quick to look up the IDs of what you were just working on.
    • ☑ my-next-file-in-dir
    • ☐ some way to insert link to a "nearby" file
      • an Embark action for inserting a link to the file under point, for use in consult-buffer
        • consult-buffer even has previews: essential when the title means nothing
    • ☐ Linking back to a file you were just working on, for when you didn't have so much foresight as to use org-roam-node-insert to create a node and insert it at the same time
  • Note-sequences. Sometimes you want to refer to a note that's not at all "nearby" in terms of date created, only nearby in terms of relevance. It must be enough that you've visited a note, for you to easily link to it.
    • (The Embark solution above looks good).
  • Easy peeking at notes as you leaf through them
    • org-roam-node-{insert,find} should preview contents as you go like consult-buffer does


Not every insight is expressible in few words. So while I might've favored handwriting because it forces me to find better words, it would be wrong-headed to regard an idea unimportant just because I can't find a succinct way to express it.

This would limit my room-to-learn on top of the universal human limitation that only ideas within a short inferential distance will make sense. On a laptop I can write verbosely, and doing so is also a way to talk to myself, generate examples & learn, perhaps important when there's a lot to unpack at once.

Quotes Nat Eliason


A wiki does not enforce discipline in keeping ideas atomic. Imagine a hybrid between twitter and a wiki, where there's a character limit on wiki pages – that would be closer to Zettelkasten. It forces you to break things up, which can result in reifying concepts which otherwise would be a forgettable paragraph in a longer text.

[…] but what really freaks me out is seeing the dentist. […] Now as a mature, psychoanalyzed adult I STILL get weird, compulsive, emotionally distant, and rigid. In waiting a day to deal with fear of pain (denied) I decided to create template in Roam. A card template a patient could use to prepare for a new, emergent, medical or dental contact. I titled it Good to Go and worked on it a couple of hours. Made a provisional outline and sketches of examples of what pt. need to collect, know, tell the MD, etc and also some sketches of a "manual" what the risky points a patient might expect in a new setting.

The whole effort was about two pages, and three hours of work and writing. Went to bed, slept and had a dream (significant as in this type of situation I usually would have disturbed sleep.)

Incidental Finding: Remarkably when I went to the Oral Surgeon to have tooth pulled I was relaxed, had good questions, remembered all I was told, and after leaving realized that something at a deep level of consciousness had occurred. I attribute this to Roam.

On Roam Research:

Since you start in the Daily Notes, every day becomes its own page and you can “pre-create” those pages with the Date Picker. So when I have a thought about something on a future day, or want to assign a to-do for myself for the future, I can just tag that date.

i.e. you should have a command, which in org-roam we might call org-roam-dailies-insert-date, so that when you want to schedule something for the future, it'll autocreate the daily page for that date and link to it. Then on that day, the backlink will be visible. However, that presumes three things:

  • that you're on the computer every day
  • that you start every day in a day-note
  • that your backlinks buffer are visible by default

Thoughts [2022-09-29 Thu]

  • No longer believe in extracting book highlights. At least per Three kinds of slipbox notes, highlights can be considered transient notes, which means you must take care of them within a day or two while your thoughts are still fresh. This I will not do – I know myself.
    • The problem with revisiting highlights later is that I'll recognize the reasoning in front of me, and this recognition is deceptive: I feel like I already possess this insight and don't have to write a note. Even though the truth is I don't possess the insight in such a way that I'll ever use it in other situations – I never wrote in my own words, I was never tested. And if I try anyway, I don't remember why it was novel to me the first time I read it, making it harder to figure out what's worth writing. Always read with pen in hand! Taking notes is never a detour!
    • So, I no longer need to sync highlights from my #e-reader. Thank God, because that was a complicated tech stack. I just need an e-reader, of any sort. (Bonus if I install KOReader on it to easily jump from bookmark to bookmark if needed, although perhaps even bookmarks are evil.) Then, write notes in any way possible while reading.
    • Perhaps a "book cover" for the e-reader, that has a paper block on the facing page, since I've now ascertained I must take notes while reading, not after reading, and paper doesn't need me to bring a second device that must be kept charged. Paper is additionally great for Write, then edit, training brevity/getting the gist, and the well-known better recall due to the interaction with a physical object.
      • Maybe the reMarkable's default app (xochitl) also lets me take these transient notes acceptably. The important takeaway is that I cannot just highlight as I have been doing – and onscreen keyboards suck, so I must use either a stylus or a Bluetooth keyboard.


What links here

Created (2 years ago)