Hacker News Reader

Comment by sethaurus | Hacker News Reader

(From the article, talking about the number of available codes)

> 32^4 = 1,048,576, which is hopefully enough.

Unfortunately, it really isn't enough. Since these 4-character codes are based only on a hash of the note's filename, and there's no other collision-resistance built in, the likelihood of two notes getting the same code rises very quickly. With 500 notes in the vault, the chance of two notes having the same code is about 1-in-10. At 900 notes, the odds are 1-in-3, and at 1200 notes, the chances of a collision rise above 50%: it's more likely that there will be a collision than not. These are realistic numbers of notes for an Obsidian vault.

This is all solvable by having something allocating IDs (and attaching them to the notes), but when using a hash, 32 bits just isn't enough to give uniqueness at even small scales.

View on HN

(developer here)

Thanks for raising the birthday paradox problem.

The search panel should show all the notes with the same code, so hopefully even with collisions you'd still be able to tell from context which note you're looking for.

I did consider allocating IDs, but I'm a bit worried about this tying notes to a specific Obsidian vault - with the way note codes work now, there is no dependence on the vault itself, only on the note's name. Something to think about...

You're lucky to regard note names as stable enough that they work as unchanging IDs for you!

But is it not then the same thing, because you already "allocated an ID" by naming it? Did you, before coming up with the 4-char hash, often label things outside the vault with the same names as those found in your vault?

I keep a paper journal and refer to my Obsidian notes once in a while.

I like the idea of throwing the note code in the frontmatter of the note.

Then it is stable, not tied to the vault, not tied to the name, can be customized on a per note basis if a user wants (00-00 is a specific note for example), and can be deduplicated within a vault.

Agreed, this would be a nice setting to "burn in" the codes to frontmatter on e.g first save. And with this enabled the plugin could also check for and avoid duplicates by modifying the code until its unique).

One other possibility is use git log --follow to grab the original filepath + commit hash, to base the code on. Imperfect but should reduce code changes vs. on rename.

I really like the simple 4 letter code for shorthand!

It's an interesting idea - sadly the problem with it is that there's no way to add these tags to other kinds of files that don't have frontmatter. Not sure how to best to deal with it. Right now I'm leaning towards having some vault-specific storage for it.

Ah yep, I hadn't considered these codes appear for all files, not just frontmatter-friendly formats, which my vaults mostly are… Watermarks for media files? EXIF? — I joke.

It's an interesting problem to think on and also reminds me of resource fork advantages. My two cents is it's worth having a setting for "more permanent" codes at whatever compromise it forces. The idea of very short note codes is really nice, especially if it's "that's the code, it won't change" (I constantly rename and move notes to improve organisation and I expect others do) — I'll be trying out your plugin soon!

The Git idea was to track the original commit of note, assuming the vault is in a repo, and use that original path + git hash as the thing that doesn't change. Log tracking is imperfect, but I'd expect it to work in a vast majority of cases in Obsidian context.

maybe pick an ID at random, record it in a "used" list, and store the code in the note as a property? an event handlers(1) could manage removing used codes from the list when a note is deleted. likewise, another handler could check if new notes (ie those imported from another vault) already have an ID and register it as used or ask the user if they want to generate a fresh ID.

[1] https://docs.obsidian.md/Plugins/Events

> 32 bits just isn't enough to give uniqueness at even small scales

You're right, but it's actually just 20 bits here, not even 32 bits.

Reply on news.ycombinator.com