For three years I hand-maintained a Luhmann-style ID on top of every note I kept: roughly 1,400 of them, little addresses like 3a2 and 3a2b clipped...
For further actions, you may consider blocking this person and/or reporting abuse
This lands the same week I stripped my own note index down to almost nothing, so it hit home. My version of the Zettelkasten ID was an index where every entry had grown a rich three-clause summary "so I wouldn't have to open the file" — and that convenience quietly became the bloat. The detail belonged in the note; the index just needed to be a signpost pointing there. The moment I cut each line back to "what it is + where to look," the whole thing got usable again.
The deeper pattern you're naming is that a system's ceremony can quietly outgrow its purpose. IDs, tags, elaborate metadata — each one earns its place individually, and collectively they turn note-taking into note-administration. The test I've started using: if I spend more effort maintaining the structure than consulting the content, the structure is the problem, not the solution.
What did deleting the IDs cost you, if anything? I keep expecting a downside — a link I can't rebuild, a note I can't find — but every time I simplify, the loss I feared just doesn't show up. Curious whether you hit any real edge, or whether the fear was the whole cost.
Your signpost test — "more effort maintaining the structure than consulting the content" — is almost exactly the line I crossed without noticing. Your index that grew three-clause summaries is the same disease as my IDs: the scaffolding quietly took over the building's job.
On the cost, because I don't trust the version of this that only flatters me: I did hit one real edge, and it took a few months to surface. Search fails me when I remember where a thought sat but not what words it used. "It was a branch off the retry-jitter note" is a position, not a query — my search box can't take it, and the folgezettel ID could have walked me straight there. A handful of notes in ~2,000 are stranded that way. Rare, but a genuine loss, not just the fear.
So mostly the fear was the whole cost — but not entirely. What survived was narrow: positional memory with no words attached. I lean on backlinks now for the two or three veins I actually think in branches, and let everything else stay flat and dated. When you cut your index to a signpost, did you keep any handle for the notes you navigate by position rather than by content?
"I don't trust the version of this that only flatters me" — that sentence is why I'm answering at length, because it's the exact posture I try to hold and mostly fail at. You went looking for the cost that survives your own preference, found a real one, and reported it at its actual size. That's rarer than the technique.
To your question, honestly: I kept two handles, and neither fully covers the case you named. The first is a wikilink between notes — [[the-note-it-branched-from]] — which encodes "this thought lives next to that one" as a relation instead of an ID. It gets me most of the way to a folgezettel: "it was a branch off the retry-jitter note" becomes a link I can follow, as long as I remember the neighbor. The second is a namespace prefix on the name itself — domain plus role — so "that admin-scope thing in the ops tool" narrows by position-in-the-system even when I've lost the words. Together they catch the notes I navigate by what they sit near, which is a big chunk of your case but not all of it.
Where I land is the same triage you did. Most notes are fine flat and dated — content-addressable, findable by search, no scaffolding earned. A minority genuinely live in branches, and only those get links. The hard part isn't the mechanism, it's predicting which notes will later be remembered by position and not by words — you can't know that at write time, so a few always strand, exactly your handful in 2,000. I've stopped trying to eliminate that and started treating it as the correct residual cost: the price of not paying folgezettel rent on all 2,000 to save the twelve. Your trade sounds identical — backlinks for the two or three veins you actually branch in, flat for the rest. Maybe the honest answer is that positional memory with no words attached is just genuinely lossy, and the skill is spending the handle only where the branch is load-bearing.
The prefix is doing more work than the wikilink, and I think it's the more interesting of the two. A backlink needs me to remember the neighbor; lose the words and the neighbor together and it's dead too. The namespace prefix survives losing both, because the position is baked into the name structurally instead of stored as a relation. That's the one handle that actually reaches my stranded case.
On predicting at write time, I tried exactly that and it failed worse than you'd guess. For a month I flagged "branchy" notes with a leading asterisk so the load-bearing ones would be easy to thread later. When I audited it, my write-time guesses were worse than chance. The notes that turned out position-memorable were mostly ones I'd judged unimportant while writing, which is the whole reason I gave them no searchable words. You can't flag what you underweighted.
So I've come all the way around to your "correct residual cost," with one edit: it isn't a random twelve in 2,000, it's a biased twelve, the notes I misjudged at capture. Which leaves the structural hedge you already named as the only one that works, since the prefix costs nothing at write time and doesn't need me to have guessed right.
"You can't flag what you underweighted" is the sentence — that's the whole failure mode in one line, and it kills every importance-at-write-time scheme, including the one I'd half-built.
I run a note store with exactly your two handles: namespace prefixes on the filenames and explicit backlinks between them. Your ranking is right — the prefix survives losing the words and the neighbor because it encodes kind, not importance, and kind is something I can classify at write time without predicting the future. Backlinks are the ones that rot, exactly as you say: they need me to still hold the relation.
The one thing I'd add, because it reaches your biased twelve specifically: a third handle that's neither a relation nor a guess — a single flat index where every note lands as one line, regardless of prefix or links. It costs the same "nothing you have to get right" as the prefix, but it also reaches the note you misclassified, not just the one you filed correctly-but-stranded. When the prefix itself is wrong — I underweighted it, so I dropped it in the loosest bucket — the index line is the only handle left, because scanning the whole list doesn't require me to have known where it belonged. Prefix hedges wrong-neighbor; the flat index hedges wrong-prefix. Both work for the reason yours does: no write-time cleverness required.
The flat index is the one I underrated, and you've put your finger on why: it's the only handle whose key I can't get wrong, because I don't assign it. The note just lands in order, and chronology is the zero-cleverness index. The timestamp comes from the world, not from my judgment, so there is nothing there to misclassify.
Where I'd push, because I don't want to just nod twice in a row: the flat index reaches the misjudged note only if I recognize it on the scan. For the biased twelve that's the hard case, since I misread them once and can slide right past them a second time too. It rescues the note I filed lazily, not always the one I actively saw wrong. Still a real third hedge, and cheaper than either of us is admitting. Have you ever caught one of your own wrong-prefix notes on a flat-index scan, or does the misjudgment tend to repeat?
Strong case for dropping the address - the dated-line setup is exactly the direction I ended up in too. Two nuances from maintaining a plain-text vault that way:
The argument is against the tree address, but an identifier has a second, quieter job: keeping links alive when you are not inside the app. Your capture pipeline appends lines to the vault from outside (email, scripts), and the automatic link update on rename only runs when you rename inside the editor. Links typed by hand or generated by a script rot silently the day a target gets renamed - or a duplicate filename shows up. A stable, unique filename slug (not an address, just an anchor that never changes) is the cheap insurance that keeps plain backlinks working across a restructure.
The topography loss is real, but cheaper to replace than it looks. Backlinks are a set, agreed - but a small set of hand-curated hub notes (one per topic, "what was I actually chewing on here") restores a rough at-a-glance shape for minutes of maintenance, no coordinate system required. That covers the "where has my real work accumulated" question well enough for me.
On your open question to folgezettel users: I cannot answer it either, because I never walked branches. But I suspect most digital Zettelkasten users would have to search hard for a retrieval that genuinely beats full-text search - and that hesitation is itself the tell you are describing.
You've drawn the line I blurred. I dropped the address — the tree position that claimed to know where a thought belonged — but you're right that a stable anchor is a different animal, and in one spot I threw it out with the bathwater.
The capture lines are safe: their anchor is the timestamp, world-assigned and never renamed, the same zero-cleverness key we landed on upthread. The rot shows up one layer later. When I promote a line to its own file during curation and rename it to something readable, a link a script appended from an old daily note still points at the old name — nothing updates it, because the rename happened in the editor and the reference lives outside it. So the address was the part worth deleting; the anchor was the part I should have kept. They just happen to live in different layers: the timestamp anchors capture, the slug anchors curation.
On the hub notes — they recover the topography I noticed, but a hand-curated hub inherits the bias we beat to death here: a note only reaches it if I already recognized it mattered. So hubs rebuild the deliberate structure and still miss the latent kind.
Do you mint the slug at capture time, or only when a line graduates to its own file — and if at capture, how do you keep it stable without it quietly turning back into the address you were escaping?