So, do you have a particular suggestion for how to implement a feature like this? Does a YAML UUID tag, as has been somewhat settled on here, suffice for you?
IMO, the note metadata are a good place for the note‘s ID, e.g. like this:
--- id: NOTEID ---
Ideally, this ID would be provided by the app itself. But even w/o this I think it‘s good if each note has one, and other tools/plugins can build upon this.
On a sidetrack (about IDs): For my own use case, I wanted to base my note IDs on timestamp-based IDs (and not UUIDs). This is since timestamp-based IDs have the huge advantage that they can be generated manually, w/o the need for a machine. However I’ve wanted millisecond precision to allow for automated ID generation (e.g. on import) w/o the need for manual intervention. Still, the IDs shouldn’t get too long, and stay somewhat readable/recognizable.
To suit the above, my IDs take the note’s creation date (but any date will suffice) with millisecond precision in its reverse base32-encoded form (after Crockford). For comparison, here’s an example:
1) UUID: 9B5D722E-4C58-441F-997F-C086B097E2C7 2) shorter timestamp: 202104130930 3) longer timestamp: 20210413093059456 4) my ID based on (3): 1T5F-CGC0-8PQJ
The encoding keeps the IDs short while still maintaining precision. While these IDs are not as intuitive as pure date-based IDs, I find them more legible than the longer timestamps – the inserted hyphens & the 4char-blocks (together with the fact that it’s digits and letters) actually make them more recognizable for me. In any case, I find them more manageable than UUIDs and sufficient for a PKM use case. And since this system is based on timestamps, these can be also used (if notes are generated manually or externally).
Seems reasonable enough and in-line with what has generally been proposed here previously. I wouldn’t be opposed to a date-based ID, though I think I’d prefer something that looks like gibberish (1 or 4) rather than legible (2 or 3). I’m pretty sure Obsidian already handles metadata like Create Date - I wonder if that could be leveraged in some way?
Which tools do you use to implement this currently? It sounds like its not Obsidian
For base32-encoding, I’m currently using AFBase32. And, for manual conversions in my text editor, I’m using a similar Perl module. I’m also aware of a Ruby library but I haven’t tried that. An example screenshot with these IDs in use can be seen here.
To workaround the potential issue of breaking Obsidian URLs, it might be an option for a tool or plugin to specify a separate URL scheme (or amend the current URL scheme), then use this (together with the note ID from the note’s metadata) for external URLs. The resolver would then need to either transform to standard Obsidian URLs, or resolve the note itself directly.
Hi, we can use URI’s to open a note, make a new note, search, but I am concerned for longer lasting links. For example I have a note in my vault called “Project X Reference” and I link outside of obsidian to open this note for my project stuff;
This might be a long lived note, and at one point I change the title, because I either split up the project in multiple sub-projects, or I change the title from “Vacation” to “Krete Vacation 2021”. In that case the obsidian URI is broken. I have to know where I left it to restore the link.
I want to propose linking to a YAML ID inside the note, or can even be in the Alias YAML metadata where there is a static ID, or generated ID (like a UUID)
The note will be:
--- id: 7cf7f411-28a8-43e2-85e3-6da816fc2afd --- # Vacation Krete 2021
Where I can refer to the static generated obsidian ID. That way longer lived notes that are referenced outside of the obsidian vault, will not break.
Als for the URI scheme, maybe something like;
For now I need to be mindful that I do not change titles too much if for example URI’s are shared, or I need to tag a label somewhere that I know it is a static reference, but it would be awesome if obsidian can be robust enough to reference longer lasting notes that might travel and change titles a few times.
Thanks Jorg, but using YAML for the UUID was already proposed many times above. Glad to see that you’re also in agreement!
@thomaskern Can I suggest you edit your OP and/or the title to include the suggestion to use YAML for the UUID?
My post was merged from a separate request so I didn’t see this. But I am glad there is a consensus
Looking at the way that Obsidian links work - the reference in the Obisdian URL is to a relative pathname. If you rename the Obsidian note (or move it, or re-name the folder), the link breaks.
This impacted my use of Hook, but also something as simple as posting a link to an Obsidian note into an Omnifocus task.
Any thought on using a Unique ID to craft these links, so that the note will maintain the same link?
I second this request. Currently, I try very hard to never move an Obsidian .md file, but it’s frustrating to not be able to reorganize as my Vault grows. I’m a big Hook user.
Use case or problem
Obsidian has an internal link looks like obsidian://open?vault=Test&file=Text.
It is not a good idea to made links name-dependent because:
Page can be with typo
Page can be renamed
In this case we can’t get access to page from another program and inside links that was made in plugins (like Katex).
Solution 1. Create a link with note hash that will be permanent and use a table hash - name. Once name will be changed nothing happened.
Solution 2. Find and replace all text in all notes - find: obsidian://old_name – replace: obsidian://new_name.
Find and replace text in 3d party program.
Asked by @moberaptor to create a plugin that will create and open UID notes by UID.
Currently, it only opens notes by UID. In the future would like the ability to generate those UID for your notes.
Now I think what I can allow open any note using any frontmatter field(s) and not only id
Hi!.. what would be convenient UUID schemes to our notes, looking into publishing them in the WWW in the future?
I didn’t use the plugin since i can not find it from the community list.
Imho the note’s id should be auto generated, unique, and implemented in frontmatter as discussed.
But may I suggest to use nano-id instead of uuid?
And i also like the idea of using note’s id for the url of notes in Obsidian Publish beside of obsidian-uri. This will make the url of notes unaffected by the change of note’s name
I just ran into this issue when trying to store Obsidian URLs in my task manager, and I immediately realized that would be extremely fragile, especially for work in progress that’s likely to be refactored (files moved, renamed, etc.). Obsidian should store a UUID in YAML frontmatter and use that ID for the URL. Glad to see it’s already being discussed.
I think what you are looking for is the Advanced-URI plugin. It supports adding the uid field automatically.
Hi! I am using Advanced-URI as you suggested. Thanks.
Is there a way to copy the UUID in YAML with a keyboard shortcut ?
I also pose this question in How to set a shortcut to copy the value of a specific key in YAML front matter?
It would be nice to have external links that magically work everywhere and don’t rely on any app-specific functionality but I feel we are looking for a complex solution for a rather simple problem here.
There is an easy 100% bulletproof way to refer an Obsidian note in any app or even on a piece of paper. It worked for original author of Zettelkasten and it works even better with computers we have nowadays. It does not depend on any databases, URI schemas or paths.
All you need is a unique ID anywhere in your note. You use it in a plain textual form anywhere you want to “link” to that particular note. Then you use search to find it. It’s only marginally more cumbersome than a link but it’s infinitely more reliable and future-proof. It can be automated to some extent too.
Personally, I use a YYYYMMDDHHmmss ID in my YAML frontmatter. When I see such an ID in another app, a click to select it and 1-2 shortcuts take me to an open Obsidian app that has already found a note I wanted to see. Works on my tablet and phone as well, although with slightly different mechanics of course. And if I give up Obsidian, none of those connections will be lost and searching will remain just as easy.
I agree with you, I use an approach absolutely similar to your one
I put it the UUUID of the exactly the same format in the main body the main body, Then , if I refactor I put a new UUID just above the spot the text I am moving and then again at the top of the piece moved itself. The Moved text will get its own UUID when formed but have an imbedded reference to the original text (and even located to where it was in original. Not enough experience to know if this extra step is really useful but it should provide a useful 'return to source" if I ever want to cite the document for external use or to go back to it again myself).
Your approach shows how flexible really simple solutions can be. Sounds like you are using those strings of digits as markers / bookmarks rather than IDs, which should still keep such “links” relatively reliable when referring notes from outside. You are just sacrificing a bit of speed but gaining extra context when searching.
Personally, I prefer to rely on standard wiki-links to keep traces of refactoring within my Obsidian vault. Refactoring is always a dangerous moment regardless of the linking mechanism in use as it’s meaning that’s getting shifted around. I find that most references I make from outside are either ephemeral (tasks in task manager for example that will be closed in a matter of days, so I may even use
obsidian://links for those) or they are links to notes with relatively “fixed” meaning: project hubs, lists, literature/reference notes for particular sources, howto’s for particular problems etc. I may move things around and add content in those notes but their general meaning remains the same. When I feel I’m stepping into a dangerous territory, I may do a system-wide search to see what I was linking to and why, pick refactoring strategy accordingly or adjust those links.
As for IDs, I prefer to keep them a 1-time instance in my system so they are actually unique and there is no ambiguity when searching. It ensures a direct 1 to 1 link when referring from outside. I also keep them in a fixed place in a fixed format for the ease of programmatic access in case I need it.
I don’t see why bookmark and ID approaches can’t be used simultaneously though. It would only take adding something extra to the main permanent ID to make a search for it unique.
L_20200529153042would only return one result but
20200529153042 markers would then return both the original note and all the references to it within the vault.