From memory… you begin with typing [[ to start the incremental autocomplete on note filename, then when the desired one is top of the list, press # to select a section based on heading.
I specifically tried to make this mostly Obsidian-agnostic - the algorithm to generate these note codes is very simple and only requires the note's path relative to the vault.
Here's the whole algorithm in Python:
import hashlib
def hash_string(s):
h = hashlib.sha256(s.encode()).digest()
n = ((h[0] << 16) | (h[1] << 8) | h[2]) % (32**4)
a = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'
r = ''.join(a[n // 32**(3-i) % 32] for i in range(4))
return f"{r[:2]}-{r[2:]}">Those codes let you quickly reference notes in your vault from other places such as hand-written notes.
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.
Directory codes could also be nested with this
> Those codes let you quickly reference notes in your vault from other places such as hand-written notes.
If not, what if I make another note with the same name after moving the original one, does it then become a collision?
I'm a very heavy daily user of Obsidian with about 8000+ personal notes organized across a fairly deep nested folder structure and can't envision a situation where I'd need something like this.
Littering my publicly accessible papers / blogs / etc. with highly idiosyncratic Obsidian shortcodes that only I have the means to access seems of limited use.
Hopefully the author will write another post going into specific use-cases for this extension.
Thanks for the feedback! I guess this plugin is a bit specific to how I use Obsidian [1], as I don't rename my notes quite as often as others do.
As I mentioned in the post, my main use case is being able to quickly reference notes in my hand-written journal. I've also used it a few times in some personal shell scripts.
Probably not a very useful plugin if you already live entirely in your Obsidian vault, though - in there good old [[wiki links]] are much more useful.
I've left a few comments so far on the rename problem, but yeah, it's a hard one to solve. I'll try to think of ways to improve it.
This preserves your goal of having the system rightfully not need another source of truth outside the markdown files, but also lets the markdown file carry the identifier across renames without adding a YAML block.
And it lets you find the note in the "open note" dialog box by typing the code, so no other kind of search interface is needed. Or even to find the note with any other filesystem utility if you have your reference code.
Were you inspired by the Zettelkasten Method for your plugin?
If only we had resource forks.
As for inspiration, I'm not really much of a note-taking system person. My system is just hyperlinking lots of notes together: https://ezhik.jp/hypertext-maximalism/ - this little plugin just helps with that outside of my vault.
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)))"
In a distributed system it's another matter.
I'm currently using 6 base-40 chars (upcase and lowcase letters, so e.g. "SXJwzQY") that represent an integer Unix time.
The base-40 alphabet is enough that all IDs up until year ~2099 will fit in 6 chars, and it's nicer to type on the phone when you only have to switch between two keyboard modes, the upcase and lowcase but not also the numbers and symbols mode.
Could you explain a bit more? If a box in the basement box is marked with 4 emoticons, how does this help you understand content, context, history of it?
If the codes are written by hand, then typing them into UI and manually searching for them could be tedious.
---
Emojis/Random Images on boxes, could be used to quickly, visually find the right box in a sea of identical gray boxes.
> 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.
I could see it being useful... until it said that changing the note name will change its code.
It's the exact opposite of how it should work. It's also the exact opposite of how Obsidian works, automatically updating references to a note when you rename it.
Interesting to hear that you think this is the opposite of how Obsidian works. I specifically opted for this approach so that these note codes are entirely independent of Obsidian itself and can be ported over to other solutions.
The other way to do it would be to store note codes in some vault-specific storage, but then those codes would be tied to Obsidian, which worries me a bit.
That said, I do want to figure out a nice way to improve it. One idea I've had was to introduce a cache of sorts, so that the plugin will remember all the older codes a note previously had. Do you think this would help your use case?
I understood that it provided a unique identifier for a note, that could be referenced elsewhere. Meaning that I expect it to last the lifetime of the note. Like a SSN for instance.
But when you talk about being tied to Obsidian, I'm not sure I follow. If it's an identifier to an Obsidian note, sure, the ID should be tied to Obsidian. But if it's an identifier to a .md file, then the ID should not be tied to Obsidian.
For the second case, it's not an issue: think about Obsidian as an IDE, and your vault as a GIT repository. You can create your own ID logic, idependant of Obsidian itself, but stored in the vault. Your pluging will implement this logic, and add the necessary requirements to make it work in Obsidian. And you could make a plugin for VSC that would implement the same logic, and adding the requirements to make it work in VSC.
In this case, I would expect the note ID to be the same, weither I access the vault (GIT repo) through Obsidian or VSC.
> 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.
You're right, but it's actually just 20 bits here, not even 32 bits.
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...
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?
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.
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 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.
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.
kuil009•4mo ago