I also agree with @jprint that this is an important feature.
It appears to me that MarginNote (at least the macOS version of MN) already has something like this internally, and the main issue is how it’s surfaced or exported for our use. Right now, it’s pretty much concealed. It might not be difficult to change this.
I did a little bit of sleuthing around and here are my findings. First, if I export a MS-Word file, it contains hyperlinks with URLs that look like this:
The last element of the path is the UID of a note in MN. If I click on the link or otherwise open it, MarginNote opens my document that contains the note, and MN seeks to it. If the MN app is closed, it launches. This is all good.
Under the hood, MarginNote uses an industry-standard SQLite database, which stores everything in tables. The database is buried in the ~/Library folder (the standard place, more or less).
I looked inside the MN database on my machine and did a few SQL queries. There is a ZBOOK table with rows for each book, and a ZBOOKNOTE table with rows for all the notes. The two tables are linked via a key called ZTOPICID. So, the UID of the note also gets you to the book that contains it. That is, both books and notes each have a UID.
I also looked at the Tinderbox UID requirements, which @jprint helpfully suggested a few months ago. I just scanned it briefly, but it seems to me that the MN links pretty much meet these requirements as UIDs.
In sum, I believe MN already implements the UID functionality, and the issue is more how it’s being exported. I may be missing some finer points in this thread (e.g., is the URI already provided by MN enough to also satisfy the requirements of x-callback? I’m not sure about this), but it looks like improving export features could go a long way to tackle the issue of surfacing UIDs.
For example, adding a menu pick in MarginNote to copy the URI of the currently-selected note to the clipboard — this would be a simple addition, and it would allow us to easily grab a URI to any note.
My feeling is that improving the export options might be the best approach to this. This has been discussed in other threads. E.g., fix the issues that @jprint summarized here.
Next, providing RTF export would allow MarginNote to easily interoperate with many different text editors. (In fact, there is already an RTF export but it saves all the notes in individual files, which is not desirable for many applications.) Greater control over the formatting of the export is also very important. E.g., having a preferences page for export and giving us a bunch of options there would be very welcome. XML format export would also be good as it can be transformed into many other formats.
Ideally, MarginNote could have a template or plugin architecture for handling exports, such that either expert users or third-party developers could create their own export modules — that’s how I would approach it, at least.
What does your team think about this, @marginnote ?