Signal's new(ish) URI Scheme
By @edent
· signal url · 5 comments · 350 words · read ~962 times.
A few years ago, I idly wondered "Whatever happened to URI Schemes?". Older communications protocols didn't rely on http. You can use mailto:me@example.com to send email, sms:+447700900123 to send a text message, and skype:terence.eden to use Skype. There are dozens of these sorts of protocols.
But modern apps seem to prefer making everything an https: link. That way, if the user doesn't have the app installed on their phone, they get taken to a friendly landing page - rather than seeing an error message.
The Signal messaging app launched signal.me URls for this purpose back in 2021. It allows you to share a link like https://signal.me/#p/+447700900123 and have your signal client open up a chat with that person.
Then, towards the end of 2022 they added support for their own scheme! sgnl (although it doesn't appear to have been submitted as an IETF draft, and isn't listed on IANA).
It has exactly the same layout as it's https sibling: sgnl://signal.me/#p/+447700900123
Of course, not everyone has (or wants) a phone number. So Signal are adding support for usernames.
Sadly, they've taken the same xenophobic attitude as GitHub and insist that only good ol' American letters and numbers can be used. No fancy accents, right-to-left languages, or Korean Hangul.
Nevertheless, it will be interesting to see if this prompts a surge in Signal take-up. Especially important as Signal are dropping SMS support
@Edent That Signal page, https://signal.me/#p/+447700900123, loads zero external scripts. There are only two small inline <script> elements on the page, but that’s it. It’s funny how much this surprised me. Signal Messenger Contact
@Edent posting your phone number in order to be contacted feels like a really bad idea though, something of a privacy nightmare. It's annoying to change and it will be misused. I wonder if the best way to publish your telephone number if you really want to do that is with a vcard - over https of course, if you wanna mention protocols. But I wouldn't.
@EdentEven for "official" URI schemes, the usability with no client installed is awful; implementations tend to run a web portal for invitations. I was there with xmpp: (RFC 5122) and ended up with the same solution, minimal Javascript creating buttons from the anchor: https://yax.im/i/#georg@yax.im XMPP Invitation
@Edent By the way, installed PWAs can automatically register themselves as protocol handlers with the operating system: https://developer.chrome.com/articles/url-protocol-handler/. This works for the safe-listed schemes (https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme), as well as for
web+*. Some example apps that use it: https://developer.chrome.com/fugu-showcase/?api=protocol-handlers. URL protocol handler registration for PWAs - Chrome DevelopersApple deprecated URI schemes as an app interop scheme in favor of Universal Links, where an app claims ownership of a portion of https:// URL space (e.g. Google Maps would claim https://google.com/maps by via https://google.com/apple-app-site-association).
A major reason for the change was that sneaky AdTech tracking SDKs were surreptitiously probing for whether URL schemes were supported to detect what apps you have installed on your phone, for nefarious fingerprinting purposes.
Unlike custom URL schemes, Universal Links fall back to the web version so there is no reason to provide an API to see if they are supported by a native app or not.
Apple still allows apps to use custom URL schemes to integrate with other apps, but only a limited number of allowlisted schemes that must be statically predeclared in the app's Info.plist metadata submitted at app review time. WhatsApp is big enough to make the cut, but they also support Universal Links via the wa.me domain and https://wa.me/apple-app-site-association).
More comments on Mastodon.