A few days ago, I ranted about how chat apps have poor support for URI schemes.
By “Chat Apps”, I’m talking about the new wave of messengers – WhatsApp, WeChat, Telegram, Wire, and the like.
What do I mean by “URI Scheme”? You’re probably familiar with:
The “scheme” is
https – it tells the computer “Open the web browser and load the specified resource.”
You may also be aware of:
This tells the computer to open the email app and fill in “firstname.lastname@example.org” as the destination address.
Also fairly common are:
tel:+447700900123open the phone dialler and prepare to dial this number.
sms:+447700900123open the text message app and use this number.
skype:terence.edenopen the Skype app and contact the specified user.
There are hundreds of URI schemes in use. Older chat apps like ICQ and AIM made use of schemes – yet modern chat apps mostly ignore them. Why?
At the moment, there’s is literally no way I can send you a link which says “This is my account on Wire, chat to me using the app.”
Firstly, it’s not all bad news! There are a few apps which do have rudimentary URI support.
There is an undocumented URI Scheme:
In repeated testing with friends, it performed inconsistently. Sometimes it would open a chat window, other times it gave an error.
Again, an undocumented URI Scheme. This is how to look up users by username:
In tests it worked reliably across all platforms.
The popular Chinese messenger has the bare minimum of a scheme:
That will launch the app, if installed. That’s it. There’s no way to target a specific user.
When it all goes wrong
We take it for granted that everyone who clicks on a link has a web browser and email client installed. If they’re on mobile, they probably have the ability to make phone calls and send SMS.
So what happens if you don’t have a chat app installed? This hot mess:
It’s pretty much the same on Android or iPhone – the user is sent to an unhelpful error page.
Why not use an HTTP resolver?
Both Telegram & WhatsApp let you look up a user on their website and then redirect you to the app.
If you open that in your browser, it will take you to the provider’s site and they will then redirect you to their app.
This introduces a number of problems.
- An extra step which adds latency.
- It forces everything through the browser – so you have to wait for that to load, resolve, and close before you can chat.
- Leaks metadata.
- Your ISP now knows that you’re doing a lookup.
- Increases vendor lock in.
- What if Telegram decides that it will only allow lookups from registered users?
- What if Telegram lies about the resolved account?
- It doesn’t actually work
- There’s no way for a website to tell if the user has an app installed.
- The user is often redirected to a URI they can’t open.
For now, it seems that using an HTTP resolver is the least worst option. It can easily be shared and understood by users – and it doesn’t tie the receiver in to a specific technology like Android Intents.
But, for the future – perhaps there’s a better way?
Given that WhatsApp, Wire, Allo, Facebook and many others all use the Open Whisper Systems protocol, it seem bizarre to me that they can’t communicate with each other. Imagine if your iPhone couldn’t make calls to your friend’s Nokia – unacceptable!
Similarly, all the major voice/video calling apps are converging on WebRTC to pipe your call around the world. The app is merely the user interface. You may prefer to use OutLook, I prefer Gmail – but they both use email as the underlying communications platform.
I’ve explained before why using a mobile phone number is a poor choice of identifier (mostly because the user doesn’t own it and can’t transfer it overseas) – but given that’s what most people use now, it makes sense to include it as an option.
I want to share a link with someone so they can talk to me on my preferred chat app.
Let’s create a new URI scheme –
It is short and it doesn’t tie itself to a specific action (
voice:), or to a specific protocol (Signal, WebRTC).
When clicking on a
chat: link, your device will either:
- Open up your chat client.
- If you have several installed, give you a choice of chat client.
Let’s take a look at some examples:
Just a phone number
- An internationally formatted E.164 phone number.
+CountryCodeat the start is mandatory.
- This is to disambiguate between users with similar numbers but provided by different countries.
This assumes that both parties are on the same chat app.
If I’m on WhatsApp and my friend only has WeChat installed – what happens? Well, part of Federation means that you can talk across different chat apps.
Named account at a provider
- This will open the “example.com” chat app.
- Possible confusion with an email address (see later)?
- Might be more sensible to use
email@example.com? But users are unlikely to understand that.
- It could be
chat:@shkspr.mobiand let my domain manage where I want the chat to be directed.
- Could just use “me@whatsapp” – does a hierarchy need to be imposed?
A name can also be a number
With specific actions
- This pre-fills a message to be sent to the specific user.
- Identical syntax to email’s
- Could also include base64 encoded data for images and other attachments.
With multiple participants
- Start a chat with several participants.
- Again, identical to email’s
- Could also be combined with the
chat:firstname.lastname@example.org?timeout=60&body=This message will self destruct
- Requests that the receiving client will discard the message after a
timeoutspecified in seconds.
- It is up to the receiver to comply with this request.
Are URI Schemes the future once more? I think they have to be. Messaging app providers will shut down (MySpace), people will migrate away from platforms (ICQ), phone numbers and email addresses will change – but people will still want to chat with the minimum of fuss.