Pretty much what the subject says - I am finding that when I move an Obsidian note to a new folder, all of the hook links break and the note is no longer linked.
I was using it extensively with the daily note plugin, then I move my daily note to another folder at the end of the day. If I activate hook in that new location, none of the links show.
Am I missing something?
That is a drag, Craig.
As noted on Using Hook with Obsidian – Hook:
The current integration of Hook with Obsidian makes use of
obsidian://links
rather than hook://file/ URLs. (We go to some lengths to ensure that hook://file/ URLs can cope with the movement of the files to which they refer, and even further.)
as background: When you use the Copy Link command, Hook returns a URL that has a “scheme”. The scheme depends on the app and how Hook interacts with the app. We have documented the Principles That Determine the URL Scheme Returned by Copy Link for a Given App . Generally, if an app defines its own URL scheme,that is what Copy Link and Copy Markdown Link link will return. For instance, in DEVONthink, hook returns x-devonthink-item URLs by default. In OmniFocus, you get OmniFocus:// URLs. In Obsidian you get obsidian:// links. In web browsers you tend to get http:// or https:// URLs.
App developers are implicitly responsible for doing their best to ensure their URLs remain valid. Hook cannot guarantee the integrity of URLs of third party apps (as implied on the apps page). For instance, if you copy a link to a website, and the website developer changes the URL for that resource, then the link will break. However, I would be very surprised if the URLs served by established apps like DEVONthink, OmniFocus and the like were to break. we ourselves do our best to maintain the validity of the URLs (hook://file/, etc.) we define.
In any event, I have updated Using Hook with Obsidian – Hook to note this issue.
The issue warrants a bug report with Obsidian. (I recall doing some tests, and thought I had tested renaming of files, but my notes are sketchy on that. I would have thought that brittle links would be quickly discovered by Obsidian users. So perhaps this is a recent bug.) Meanwhile, I would recommend if you can, re-establishing the previous directory structure, until Obsidian rectifies the issue, assuming they will. On the Linkable Mac Apps – Hook we list Obsidian as: “
Obsidian”, linking that entry to Using Hook with Obsidian – Hook. There we note that Obsidian is still beta software.
I got in touch with one of the co-founders about this. However, I would recommend discussing on their forum or discord service. The community there will be able to help.
Looking at the obsidian:// URLs again, I am reminded that they code a relative pathname without an ID that might be used for tracking.
We used to have a liaison between Obsidian and Hook communities. (that’s an informal volunteer role.) If an avid Obsidian + Hook user wants to take up that role, that would be particularly appreciated given that Obsidian is still in Beta and moving fast.
Thank you @LucB for addressing this. Yes, I confirmed that the Hook links use the relative pathname (as I was trying to build a Keyboard Maestro script to open a created Obsidian file as well) and not only do the hook links break, but a regular link to the Obsidian note pasted in an Omnifocus task also breaks for that reason.
It definitely sheds some light on if Obsidian will be able to be a permanent use in this situation.
I posted at the Obsidian forum as well. Obsidian Links when you rename a file Hook breaks (actually, all of them seem to break) - Feature requests - Obsidian Forum
The Hook scripting could be changed to fallback to opening the note name (Obsidian will find best match path) if opening the absolute path fails, but that doesn’t seem a good solution to me.
There’s a suggested workaround here, but not a great one.
Is it maybe possible that hook support the Advanced URI Plugin?
There is one problem in using this plugin. If you invoke hook in Obsidian, you invoke the default URI and not the Advanced URI
I prefer obsidian:// links over hook:// links, because the first open in Obsidian, and the second do not; they open files in the default Markdown editor, which cannot be Obsidian, AFAIK.
I do no like the default obsidian://hook-get-address script much because it uses the macOS clipboard, and I’m not in favor of installing extra plugins, like the Advanced URI plugin.
So, I had a go of my own at solving this.
The solution I implemented works without the clipboard, generates fairly stable obsidian:// URLs, and is quite a bit faster than the built-in script. Caveats:
You will definitely need to modify it to accomodate your own situation - especially the paths to the Ruby interpreter and the script itself need fixing - but hey, maybe it’s of use.
Fantastic, @voostindie ! I agree using the clipboard is problematic.
We at CogSci Apps agree using the clipboard is problematic.
I prefer obsidian:// links over hook:// links, because the first open in Obsidian, and the second do not; they open files in the default Markdown editor, which cannot be Obsidian, AFAIK.
We at CogSci Apps also concluded it cannot be Obsidian.
That’s an issue for a lot of people.
I’ve listed the trade-offs between the 3 URL schemes for Obsidian in a table in Using Hook with Obsidian – Hook, and in other text there. The default script does not support Reveal File in Finder or Hook to New. Can your proposal handle Hook to New?
I would appreciate feedback from any Hook and/or Obsidian user on the Using Hook with Obsidian – Hook page, as I’m not a regular Obsidian user myself.
After reviewing your approach, we’ll link to it on the latter web page.
And in related news, we published Hook 3.4.3 before I noticed your post:
Just tried @voostindie’s script which works great! Hook to New support would be amazing
Wow, that was a quick response! Don’t you, you know, celebrate the weekend? 
Anyway: I just updated to the latest Hook and examined the “Get Address” for Obsidian (I can read AppleScript; just not write it). That’s some impressive bit of coding! Unfortunately it does not work for me though. It doesn’t actually change the implementation of the 3 modes that were described earlier in the article.
For now I think I want to settle on obsidian:// links, but using URLs that are a bit more stable than the default.
My script is a small improvement (IMHO) over the default (obsidian://) implementation in two ways:
obsidian://open?vault=a&file=/path/to/name.md becomes obsidian://open?vault=a&file=name).This obviously doesn’t work if multiple documents in the same vault have the same name. But, I can live with that.
As for the “Hook to New”: I can’t make that work I’m afraid. I would need to know in which vault the file should be created, if any. Because the vault is part of the obsidian:// URL.
I believe there are two ways to really solve this:
hook://file/ links with Obsidian.One of my professors used to say: “Every problem can be solved with an indirection”. Over the years I’ve learned that to be true.
What I think we need is something like what “Choosy” is for web browsers: a file handler for Markdown files that, when triggered (e.g. from Hook) implements a bit of fairly simple logic:
If we’d have that, most issues would be fixed, I think… Unfortunately this requires native macOS coding (in Swift) or something, which I do not master at the moment. Otherwise I would do it myself and stick it on GitHub.
So, my own comment above made me think… I Googled around a bit and found OpenIn (it’s also in the App Store). This is like “Choosy”, allowing you to set up different rules to match URLs against, manipulate them and them open them in specific browsers. Except that it doesn’t only work on URLs, but on any kind of file.
I guess you see where I’m going with this.
It took me some experimenting, but now I have normal file links to Obsidian documents, which is awesome, because they are much more stable (hook://file/...), and they also work outside of Obsidian, like when I’m selecting a Markdown file in the Finder.
Here’s a new gist that modifies my previous one to return plain file links.
I set up OpenIn to take control of all .md files, and I set up a rule that matches all Markdown files in vaults and opens these in Obsidian. (This took some puzzling, but in the end it worked turned out to be pretty simple. See the gist above for details.)
And it doesn’t stop there! I have configured OpenIn to use iA Writer by default, except when the file is opened by Obsidian itself. Then I use Marked 2. Which is precisely how I like it.
Regarding your Hook: alternative “Get Address” script for Obsidian that returns file links · GitHub
The built-in Hook script uses the
obsidian://hook-get-addressURI
handler that’s built-in to Obsidian,
It might be more informative to say that the script can use obsidian://hook-get-address . By default , it does not use it. By default it uses the native obsidian:// URL. It has options to use obsidian://advanced-uri or hook://file/ URLs.
and that sucks, because it messes
up the clipboard and has all kinds of timing issues. It’s slow.
This criticism on the other hand applies to the default integration with Obsidian, and only to it.The obsidian://hook-get-address and hook://file/ integration does not rely on the clipboard.
The table in Using Hookmark with Obsidian – Hookmark lists the tradeoffs, including whether the clipboard is used.
You’re completely right. My comments in the Gist apply to the Hook version from Friday, when version 3.4.3 was not yet released, including the new scripts .
I’ll update the gist accordingly.
Also, my criticism apply to Obsidian, definitely not to Hook.
Ah sorry didn’t realize/remember that. Things are moving fast 
. @bchend reminded me that we had a similar integration originally . she wrote to me saying:
The previous script [that we wrote] also returns Obsidian URL scheme.(It can return Hook file thought). The difference is that the current script get Obsidian url from Obsidian action, the previous one get it from obsidian library file.
then we changed to using the clipboard method when it became available.