I'm too lazy to write full note titles in my paper journals. With this, I can instead write a 4-character code that I can quickly look up in my Obsidian vault.
This would be even cooler if there was some heuristic to prefer codes based off of the titles somehow. Like if math-5/limits could somehow get the code M5-LM. I wonder if this is even possible to implement consistently at all. Sounds like a fun problem to solve (it’s the kind of thing an LLM could probably do very inefficiently)
Very interesting to see another person also landing on using 4 base32 characters for labeling things - it really is enough for a human.
Personally I use it for labeling physical things - mainly boxes. With a corresponding note in my Obsidian vault it really helps with getting content, context, and history about random stuff in my basement.
Python oneliner for generating them I've aliased in my Bash config:
python3 -c "import base64; import secrets; print(''.join(secrets.choice(base64._b32alphabet.decode()) for _ in range(4)))"
I feel this needs more explanation as to why and what problem is being solved.
> Note codes are generated based on a note's name and path, meaning that the note code will change if you rename your note.
I get the idea of assigning a short identifier to things, but then why would I ever want that ID to change when I change random properties about the note?!
It was interesting to read about the idea of 4 characters with minimal similar looking characters, but the application of that here seems like a solution looking for a problem.
(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.
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...
This has inspired me to literally build an exact copy of this but use a GUID instead and also not confusingly tie it to the file name. Such weird choice made with this...
I think ambiguity is not as critical as in Git here - if you look up a note code with multiple entries, it should just show you both so you can choose the right one based on context.
Could there be an option to make the code be generated based on the note UUID or creation timestamp so that is is hard-linked to the note and won’t change when the path changes? Because some users want the freedom to update the note title freely without the code breaking.
20 comments
[ 2.6 ms ] story [ 38.2 ms ] threadI'm too lazy to write full note titles in my paper journals. With this, I can instead write a 4-character code that I can quickly look up in my Obsidian vault.
If not, what if I make another note with the same name after moving the original one, does it then become a collision?
Personally I use it for labeling physical things - mainly boxes. With a corresponding note in my Obsidian vault it really helps with getting content, context, and history about random stuff in my basement.
Python oneliner for generating them I've aliased in my Bash config: python3 -c "import base64; import secrets; print(''.join(secrets.choice(base64._b32alphabet.decode()) for _ in range(4)))"
> Note codes are generated based on a note's name and path, meaning that the note code will change if you rename your note.
I get the idea of assigning a short identifier to things, but then why would I ever want that ID to change when I change random properties about the note?!
It was interesting to read about the idea of 4 characters with minimal similar looking characters, but the application of that here seems like a solution looking for a problem.
> 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.
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...
Let me know how your version goes - would love to see it.
> eb137
and IIRC git will raise an error if the prefix is ambiguous. OP, maybe you could do the same?
I think ambiguity is not as critical as in Git here - if you look up a note code with multiple entries, it should just show you both so you can choose the right one based on context.