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.

▲

jlaternman a day ago | parent [-]

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!

▲

Ezhik a day ago | parent [-]

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.

	▲	jlaternman 2 hours ago \| parent [-]
		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.