Slipbox workflow

Creativity requires the absence of censors.

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

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.

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.

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.

• 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

#org-roam

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.

That is what I have done with "topic-tags" like this one: #org-roam.

When you need an actual Org tag, you'll know.

Example: I use Org tags to filter out some notes when I run org-publish to make this website. 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 use Org tags for that).

A writer says:

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.

The above quote prompted me to make the counter, which you can see, in the top bar of my website.

Anyway.

Some software, including org-roam v2, org-node,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 treat 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, if you didn't have such software, you could just have notes that are a hierarchical list of links to atomic notes, a kind of meta-note, but sometimes it feels more natural to write a linear document without linkifying every last thing.

As mentioned in gwern.net/design, hyperlinks aren't such an amazing thing that everything should split up and connected by hyperlinks. On the contrary! Try to need as few hyperlinks as possible.

Imagine you want to print out your notes. Maybe for your future amnesic self at the elderly home. 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…" But it need not be an iron rule.

---

Anyway, might be easy. Write some command to find the minimum en.wikipedia.org/wiki/Feedback_arc_set, 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.

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 questionable: www.greaterwrong.com/posts/Psr9tnQFuEXiuqGcR/how-to-write-quickly-while-maintaining-epistemic-rigor

You don't need to do any research! Just explain how you got to where you are.

A sweet benefit is that you're free to just write, write and write. Less detours along your way.

It's also more useful to 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.

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

Although:

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 human limitation that only ideas within a short inferential distance tend to 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.

from www.nateliason.com/blog/roam

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

• 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, 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.

• maggieappleton.com/programmatic-notes
• Slipbox pitfalls
• Unpacking beliefs
• How to put in your own words something the source expressed perfectly?
• notes.alexkehayias.com/don-t-use-deductive-arguments-to-connect-key-lines-use-inductive/

• Custom org-roam-extract-subtree
• Using the reMarkable, my unsophisticated way
• Portal: Slipbox
• Website writing tips