UUID for note links in URL scheme

Feature requests
14

@davecan

I think everyone here already quite well appreciates (and have even already expressed) your concerns - lifelong knowledgebase, interoperability with other apps, etc… - thus UUIDs in filenames was only ever seriously considered by fanantoxa and he quickly realized that it wasn’t the way to go after being made aware of the previous discussion on the issue.

Moreover, it seems to me(/us?) that your concerns are good arguments for a well-thought-out UUID mechanism. As described by OP, the current external link format is utterly useless for interoperable-use outside of Obsidian since renaming files - as will inevitably happen for most people - immediately breaks the links. Any feasible workaround for this - e.g. a system-wide search/replace - is laughable and bound to fail due to user-error. It is for these reasons that UUIDs need to be not just a community plugin (which is perhaps a necessary starting point for the sake of expediency/proof-of-concept), but built-into the core functionality of Obsidian.

Of course, proprietary UUIDs in some hidden database, however they may be implemented - there are many apps mentioned above, like Onenote, Bear, Zotero etc… - cannot realistically be carried forward if we decide to migrate to another app for whatever reason. YAML seems to solve this problem nicely, as it does for metadata generally - the UUID information is just sitting there in plaintext, ready to be parsed and integrated into the other app (something that has to be done anyway with filenames and other linking formats).

Once the UIDs come into play [[Note A]] could link to any of many (for the sake of argument let’s say dozens ) of notes that happen to have the same name but unique IDs

This isn’t an inevitable outcome for UUIDs, especially if done through a plugin since Obsidian (actually, the filesystem) already blocks using same filepaths. If someday UUIDs were to be baked into the core of Obsidian, as should be done, it would have to still adhere to this unique filepath restriction. YAML makes this even easier.

I’m not smart enough to actually design the architecture for implementing this, but hopefully @fanantoxa can get us to a good starting point and if we can get enough support for this crucial issue, perhaps the Wizards of Obsidian will be able to polish it off.

Does this address your concerns? If not, what is missing still?

15

So I’m not opposed to the concept of a UID in principle, just that it not interfere with inter-note linking as it currently works. That’s all. I do understand the underlying concern about external links.

A UID for external links could be generated and stored in the internal index they already maintain as long as it is exportable to at least one format (e.g. JSON or CSV) when migrating to another app.

I’m not even sure the export would really be needed though, since another app would probably generate its own UIDs anyway. For example, why would Bear jump through hoops to import and honor Obsidian’s UIDs when they may be in very different formats? They would then be expected to do that for many such tools, as would the other tools.

So it should probably be expected that when switching apps then of course the UID would break and the links would need to be updated.

Which implies to me that UIDs could be supported and remain an internal part of the tool rather than exposed in YML where an end user can inadvertently tamper with them and break things accidentally.

16

The point of YAML, however, is that it is interoperable - that if anyone moved away from Obsidian to another tool, the obsidian:// links that are pasted elsewhere - word docs, task managers, zotero, etc… - wouldn’t break. All that would be necessary is a simple global find/replace for obsidian:// to the new protocol.

I agree that Bear or whoever is unlikely to implement that, but maybe that’s more reason to stick with Obsidian or for new apps to adhere to this sort of interoperability standard, which YAML headers seems to be a major part of.

Anyway, whatever the case, I doubt anyone here is at all opposed to it being an internal part of the tool, but I have low expectations of that happening any time soon. So, if @fanantoxa or someone else can figure out a plugin that can handle this in a reasonable way, with YAML seeming like the best way to do that (can a plugin access the internal index?), that would be a great starting point.

I see no reason why note linking couldn’t stay exactly as it is, but obsidian:// links use a UUID that points to whatever the note name happens to be. Again, this is precisely what all of these other apps do, for good reason. Its somewhat bizarre that this was not how Obsidian was designed from the start.

17

IMO to achieve a robust note-taking system that can be used in various ways (and also linked to/re-used by external tools), it’s crucial to:

  1. have a unique & stable identifier for each note
  2. write notes that are as self-contained as possible

“self-contained note” means that the note’s body text (or its metadata) contain all relevant information (including things like citation info and, of course, the note’s ID) – ideally in a format that can be easily searched and/or parsed (see also this related zettelkasten.de discussion).

As also discussed in this reply, if the note’s ID is included in the note itself, it will always travel with the note and will not get lost if you transfer your note into environments where there’s no file path info, like a database, a single text file, or an app that stores files internally using its own naming scheme. Your notes would still remain intact and can be retrieved again w/o loss.

In the same sense, it’s also beneficial if the note ID gets included in the file name itself since this helps with third-party file-based integrations.

1 Like
18

@msteffens

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?

1 Like
19

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).

3 Likes
20

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

21

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.

22

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;

obsidian://open?vault=my%20vault&file=Project%20X%20Reference

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;

obsidian://open?vault=my%20vault&id=7cf7f411-28a8-43e2-85e3-6da816fc2afd

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.

4 Likes
23

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?

3 Likes
24

Hi,
My post was merged from a separate request so I didn’t see this. But I am glad there is a consensus :wink:

  • Jorgen
2 Likes
25

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?

5 Likes
26

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.

5 Likes
27

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).

Proposed solution

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.

Current workaround

Find and replace text in 3d party program.

1 Like
28

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.

EDIT
Now I think what I can allow open any note using any frontmatter field(s) and not only id

9 Likes
29

Hi!.. what would be convenient UUID schemes to our notes, looking into publishing them in the WWW in the future?

30

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

31

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.

2 Likes
32

I think what you are looking for is the Advanced-URI plugin. It supports adding the uid field automatically.

5 Likes
33

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?

1 Like