Structure of Links?

I’m new to Hook and notice that the Hook links, however robust in functions, seem a bit verbose in plain text context and I can’t totally understand the roles played by different parts. My first observations are:

  • After the invariable hook://file/ prefix comes first a hash of the pointer to the file.
  • In the end, the n parameter indicates the file name.

My questions are:

  • What are other parameters (e.g., the p parameter) for? Is there additional parameter in Hook file links other than above ones?
  • Are all parameters essential for Hook to be fully functional?
    • For example, I tried to remove the n (presumably is simply the file name) parameter from a link and the remaining part works as well as the original. Does that mean the n parameter is optional and will there be an option to create a link without it?
    • The question is of practical importance because as a Chinese user, the n parameters are always encoded tokens of Chinese characters that don’t give any useful information as in English contexts and take lots of room in markdown editors.

Thanks in advance!


Thanks for being interested in Hook.

The information encoded in URL was not designed to be human readable. It was intended for Hook to be able to locate the file in various situations. To make sure a link to be robust, please do not delete any part of the URL. In some situations, Hook is able to locate the file without consulting all parameters, that is why your experiment worked.

If you use MarkDown, the Copy Markdown Link command will output both the title and URL in the format of [title](URL), where title is not encoded. So the reader of the markdown would only see the meaningful title instead of long URL with proper MarkDown viewer/editor.

Best regards,

Brian Shi

CogSci Apps Corp.

Are there any specific dangers in removing the n= or filename parameter? I’ve tried this and the links persist just fine, but I’m wondering if there is some future scenario where this would cause issues.

For reference, I’m using Roam and for privacy reasons there are certain filenames I don’t want in that database. (E.g., Links to local pdf or docx files with a student’s name in it.)

This is a good reason why I suggest it would be extremely helpful if there were an option to remove any specific Hook from the database. I know that @LucB has suggested this is not desirable since there can be other hooked files, but I think that is a risk that can be assumed by the user if desired.

I didn’t mean to imply that we would not support it. I do agree with the usefulness of deleting hooks, and we do intend to support this. We’ll simply provide the user with a dialog box so they understand the implication of their action.


Deleting a hook would enable the concept of a “temporary hook”. I’ve no idea if this is a useful concept, mind. :slight_smile: But someone here might tell us why it’s “gosh, darn it, what I always wanted”. :slight_smile: And then we all learn.

Indeed this is my main use of Hook.

For maintaining a “long-term” database of links, I prefer Devonthink or similar software where the relationships among the links are very clearly defined and may include groups, tags, smart groups, and other advanced features.

In my workflow, I see Hook shining as being able to very quickly establish “short-term” links - things like documents I need to review today, emails that I need to respond to shortly, notes that I need to review. Hook excels in being able to very quickly add such items to what becomes essentially my “short-term to-do list” with direct links to to-do items in a variety of forms/applications.

Hook works great for this purpose, but there is no need to have the data sitting around in a database long-term, especially if some of the items or item titles may contain personal or confidential information.

1 Like

There are too many use cases to list re why it’s useful to have a DB of links. Here are a couple:

  1. Track Issues More Productively – Hook. The issue web is already a hub for all active members of software development teams on a project . Visit the issue and quickly access links to (and navigate from):
  • documents in the version control system (e.g., SVN) related to the feature (e.g., specs, release notes)
  • related forum posts of one’s company (possibly the source of the issue) that originated the issue, or where the issue is discussed
  • related external web pages (e.g., a pertinent standard [RFC , etc.], third party product or organization)
  • academic papers on the subject (e.g., in research gate)
  • key email(s) (e.g., if the issue came in via email, or management has sent a directive related to the issue)
  1. Better Note-taking in the note-taking app of your choice– Hook, again, bidirectional linking
  2. Instead of writing in web forms, write in your favorite editor (even the best web apps are zero for writing compared to something like BBEdit), and keep a local record of what you’ve submitted to web forms (so you can search it later, re-use it.) that is bidirectionally linked (if the website goes out of business you still have your source, and it’s easier to find because you have Hook , launchers and spotlight that can access it locally):
  3. etc.

Why “long term”? Because as far as the brain is concerned, long term can actually be an hour from now, or after you reboot your computer. Compare the excellent discussion of intermediate consciousness in A Mind So Rare: The Evolution of Human Consciousness by Merlin Donald | Goodreads. One of the unique features of humans is their intermediate and long-term consciousness. Hook extends that, and it extends long-term working memory. (BTW, launchers also maintain a DB of information you access. They serve a related purpose to Hook. Here at CogSci Apps, we use Alfred and LaunchBar.)

1 Like

Those are all great use cases @LucB

My main concern is privacy/confidentiality. There are all sorts of professional and personal reasons why it would not be a good idea to have an ongoing list of every document or URL which I have Hooked at some point. Surely I am not alone.

I totally understand your desire to warn users of the consequence of deleting a Hook. But it truly is essential that your users have the ability to bypass that warning and easily delete any Hook(s) at will.

As for those items for which I do want a database of links, that may well become much more useful in Hook when you add the planned tagging system. Right now Hook does not seem to be a good fit as the “primary” database of links because it is too easy to forget that a Hook exists for a certain item.

1 Like

Yes, as noted that will be supported in an upcoming update to Hook.

Well, based on the feedback we’ve received, there is a huge % of users (the majority I suspect, and we are preparing a survey that will assess this hypothesis) who use “hooks” (bidirectional Hook links presented in the Hook window). Hook window links need to be recorded in a database.

One needs to keep in mind that Hook’s DB is just on the user’s own computer. If the user chooses to sync links, user can choose whatever sync / copy tech they want. CogSci Apps is not party to that. If enabled, Hook sync simply writes to a folder, you decide how to copy it over (could even be a USB drive, no need to even use a cloud service) or dynamically sync it.

As for forgetting what’s hooked: yes , it’s true that one might and will likely forget some of the hooks (and Hook providing more cues will be helpful–we are working on that, and have contributed some code for that re DEVONthink), but in a huge number of extant use cases, such as the ones I mentioned, habitual use of Hook is a good way to get to that expectation that there is or may be a hook (e.g., if you use a bug tracking system daily, as many in the software industry do). Moreover, there are other clues, like Finder tags. Also, there’s a folder for the docs created via Hook to New. For Finder docs, there is the option (a) to add a Finder tag, (b) to use a special prefix or suffix (so the filename itself would be a clue as to the item being hooked to something). So there are many cases where there’s information to suggest that an item is Hooked. There are other indicators too. Morever, there is a search function in Hook.

But yes, we do intend to go further than this, and develop other bookmarking features. (Hook is not a traditional bookmarking app. It is pushing the boundaries of what bookmarking is all about.)


On the “temporary hooks” front I do a lot of customer projects where I want to “put the project to bed”…

I might well have created hooks to the “CPU” presentation Markdown, the “DDF” presentation Markdown etc - for easy retrieval while working on the project.

When I move to the next customer’s project I probably don’t want those hooks “cluttering up my life”.

I put “cluttering up my life” in quotes because I’m not sure that’s a meaningful thing. It seems to me it is. So I would consider these hooks as ones I’d want to be temporary.

(To complicate things slightly, I usually have 2 or 3 such projects on the go.)

Off topic a little, when working on a customer project I will have my metaphorical fingers in two completely different sets of folders:

  • Raw materials served by Apache/PHP from ~/Sites/Studies .
  • Presentations being built in ~/Documents/Customers .

I would think a dashboard with hooks to both destinations a better way of coping than 2 Finder windows. (I could build such a dashboard in eg Keyboard Maestro - and throw it away at End Of Job.)

1 Like