All: implement short callback url

[tiberiusteng]

When generating QR codes, the complete code size given the same module (pixel) size is proportional to text length. By shortening the callback url, we can either:

1. Reduce area needed for a code
2. Increase error correction ability of the code

The x-callback-url format currently used doesn't utilize fields other than id, so we can create a shorter format treating id as a resource name.

Since Joplin currently only uses hexadecimal representation of UUID as note/tag/folder identifier, we can use base64 encoding to reduce ~30% length of representation. The base64uri alphabet (RFC 4648 §5) is chosen so the encoded string don't need another round of URL encoding.

Above is a demonstration of the effect, created with TEPRA SPC10 (OEM version of Epson Label Editor) on a 24mm-wide label. There are 3 different URL formats with both 7% and 30% error correction.

1. joplin://x-callback-url/openFolder?id=1c876daccc294bd087b0e0c111b30166 (current x-callback-url format)
2. joplin://folder/1c876daccc294bd087b0e0c111b30166 (short format with hexadecimal id)
3. joplin://folder/HIdtrMwpS9CHsODBEbMBZg (short format with base64uri id)

We can observe that:

• (1) with 7% error correction takes 33*33 modules
• (2) with 7% is 29*29 modules
• (3) with 7% is 29*29 modules
• (1) with 30% is 49*49 modules
• (2) with 30% is 37*37 modules
• (3) with 30% is 33*33 modules

Reducing the item type part (folder, tag, note) to single character won't further reduce generated code size, so I choose to keep readability.

This pull request adds base64uri encode/decode, and ability to generate and handle new shorter format of callback URLs. Original callback URL format is no longer generated but the ability to handle them is not removed.

[laurent22]

Usually the url is processed using a url shortener before being made a qr code, which is a method that works with any url. I don't think creating shortcuts at the application level is the right approach

[tiberiusteng]

Anticipated use case of this is scanning physical printed QR code labels, possibly in an environment (temporarily) without external network access.

Imagine in a secured lab forbid mobile devices' with network access, but still can use QR code labels to refer equipment usage notes stored in Joplin.

[tiberiusteng]

On external URL shortening services, they eventually goes out of service leaving dangling links, adds tracking, and many of them doesn't support custom schemas like joplin://.

[laurent22]

I understand that using shorter urls would mean more compact qr codes, however it seems more like a minor inconvenience on a relatively rare use case. The big drawback for us is that there would now be two callback url formats to maintain, and this is not a minor issue. In general there's merit in using one and only one way to do something

[tiberiusteng]

I'm open to further refining the idea, tweaking implementation/library or refining documentation.

It's just because after some rudimentary experiments I found that shorter code (which can have larger pixels in the same area) and with more error recovery can be easier read, the label would be more tolerate to wear and tear; Later I found it's not that difficult to implement, as in this pull request (I was afraid that I probably need other libraries to do encoding/decoding, fortunately not).

The x-callback-url scheme is more verbose, but it doesn't provide more functionality (after all it's still hostname, path and query parameters) or broadly agreed endpoints/programming interfaces, while its additional length does not play well in this specific use case (physical code tag).

For reference, here's how Obsidian implements similar feature: https://help.obsidian.md/Extending+Obsidian/Obsidian+URI

[tiberiusteng]

Personally I'm using Joplin for packaging and inventory management, since it can't go to note with QR code scan, I was searching for my box label in it. After #9803 merged I can at least use x-callback-url labels on my box to link to a note.

I'm thinking to try implement something like joplin://search/box123-45 so the tag wouldn't bound to a specific (probably shared) note but a title/keyword, and the link is even shorter than using a note ID, but maybe after URL formats are settled, also it doesn't look straightforward to programmatically initiate search on app-desktop.

[laurent22]

Personally I'm using Joplin for packaging and inventory management, since it can't go to note with QR code scan, I was searching for my box label in it.

But even with a longer URL you could still do this, right? I understand it's nicer if you can print a smaller QR code but I feel it doesn't justify supporting a second format.

Happy to merge your other PR though once reviewing it is done.

[tiberiusteng]

On Android I can implement another app as a trampoline to generate joplin urls after scan a tag, but I don't know how to do this in iOS yet. It's always better to have the support in Joplin itself if possible.

I'm aware that joplin have used joplin:// for resources internally, but it seems internal/external usage of the schema is well separated, currently outside-facing callback URL handling are all in callbackUrlUtils.ts, we can add a comment section in it to describe both formats, it shouldn't be too difficult to understand.

Both format aren't normally manually entered, only used to programmatically open notes, so I don't think it will be visible to normal users. I never intended to make existing links fail.