Using Hook With Missive
Missive is a “team inbox and chat tool that empowers teams to truly collaborate around email”. It is developed by a 🇨🇦 Canadian company based in Quebec city.
Hook enables you to link Missive items to and from anything that is also linkable. Currently this requires adding this integration script. We plan to include this in Hook itself, depending on the feedback we receive from Missive users (so far so good).
This page provides some of the technical details about linking with Missive. For usage examples and why this matters, see .
Copy Link, Copy Markdown Link and Hook to Copied Link
Copy Link and
Copy Markdown Link in Missive return links of the form
Hook to New > Missive
This command is not currently available. It requires an API for creating linked objects.
Search for Missive bookmarks in Hook
To find Missive items you’ve processed with Hook, simply
- invoke Hook
- enter search mode (with ⌘F or a click)
url:missiveand hit the return key
Your Missive bookmarks will show up in the search results.
Limitations, and information for Missive developers
Currently, Hook controls Missive app using UI scripting. This is a suboptimal form of inter-app communication. For instance, in this case if the user changes the keyboard shortcut for getting a URL from Missive, the script would not work. Also it involves delays.
This is because Missive is not currently a URL-friendly app. It lacks a local application programming interface (API) for linking emails and other items. URL-friendly apps meet the requirements described here.
In short, URL-friendly apps have an API ( application programming interface) that provides:
- a method to get the name and URL or ID of the currently selected item;
- a method to open the item using the URL or ID; and
- a method to create a new item, based on an input label; as output, they return the URL or ID and the name of item. (The name is returned in case they need to modify it for some reason).
Background: RFC-5322 is the RFC that standardizes email transmission. It implies that each received email has a standard ID. The RFC specifies the form of message IDs.
Special considerations apply to the URL-friendliness of e-mail apps.
First, there is no need to provide method #3 (to create a new item). That is because the RFC-5322 ID of an email cannot be determined before the message is sent.
Second, email apps need to provide a method to open or select an email based on the email’s RFC-5322 compliant ID. If the app has its own URL scheme for emails that does not include the RFC-5322 compliant ID, to be fully URL-friendly the app still needs to provide a method to open the email by RFC-5322 compliant message ID. That would allow users of the email app to utilize email links they receive from people who use a different app (like Mail.app).
Third, if the email app has both local and web URLs, such as
mail.missiveapp.com, there needs to be a publicly defined way to map one URL to another.
You can understand the idea here: a URL is not very useful if it can only be used in a silo. The point of the Manifesto for Ubiquitous Linking is to enable linking of information between apps. E-mails are abstract information objects that may be represented/read in many apps (browsers, different email apps).
URL-friendly email apps
URL friendly email apps are listed here