C- Reviewing past notes in the process of creating new notes is a key user behavior to promote synthesis
The core game mechanic of Zettelkasten is to file your note some place where you would want to stumble over it again. As you rifle through old notes to find this place, you recurse over notes you had forgotten about, sparking new ideas, which you then write down, and have to file, causing you to rifle through again, sparking more ideas… in a cascade of idea generation. Zettelkasten is a feedback system. Notational Velocity was a tiny note-taking tool built around a single idea: search-or-create. The only way to create a new note in Notational Velocity was through the search bar. Typing would live-searched through your notes. Hitting enter would create a new note, with the contents of the search query as the title for the note. Like Zettelkasten’s game mechanic, this search-or-create mechanic closes a feedback loop. Every time you enter a new idea, you’re recursing over old ideas. Often you find yourself editing, or refactoring an old note, instead of creating a new note. Over time, these microinteractions add up, generating knowledge from the bottom-up.
We can see this used in Roam Research and Obsidian with wikilink autocomplete-or-create, combining the process of linking to a page with reviewing the pages you’ve already created. Threadhelper takes this a step further - as you are writing a tweet, it searches through your history to find tweets that may be relevant based on keywords from within the tweet you’re writing.
Q- What are powerful primitives for a user of a decentralized knowledge graph? How do we create primitives and feedback loops that encourage reviewing past notes in the process of creating new notes?
Reviewing old notes helps provide another lens towards the concept, as well. C- Multiplicity facilitates synthesis.