Whatever happened to URI Schemes?


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:

  • https://example.com

The "scheme" is https - it tells the computer "Open the web browser and load the specified resource."

You may also be aware of:

  • mailto:me@example.com

This tells the computer to open the email app and fill in "me@example.com" as the destination address.

Also fairly common are:

  • tel:+447700900123 open the phone dialler and prepare to dial this number.
  • sms:+447700900123 open the text message app and use this number.
  • skype:terence.eden open 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."

URI Support

Firstly, it's not all bad news! There are a few apps which do have rudimentary URI support.

WhatsApp

There is an undocumented URI Scheme:

  • whatsapp://send/?phone=447700900123

In repeated testing with friends, it performed inconsistently. Sometimes it would open a chat window, other times it gave an error.

Telegram

Again, an undocumented URI Scheme. This is how to look up users by username:

  • tg://resolve?domain=edent

In tests it worked reliably across all platforms.

WeChat

The popular Chinese messenger has the bare minimum of a scheme:

  • weixin://

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:

A web browser showing an error message that it didn't understand a protocol

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.

The telgram website attempts to redirect the user to the 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?
  • Security
    • 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?

Federation

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.

Problem Statement

I want to share a link with someone so they can talk to me on my preferred chat app.

Solution

Let's create a new URI scheme - chat:

It is short and it doesn't tie itself to a specific action (videocall:, text:, 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

chat:+447700900123

  • An internationally formatted E.164 phone number.
  • The +CountryCode at 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

chat:me@example.com

  • This will open the "example.com" chat app.
  • Possible confusion with an email address (see later)?
  • Might be more sensible to use account@com.example? But users are unlikely to understand that.
  • It could be chat:@shkspr.mobi and 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

chat:+447700900123@whatsapp

With specific actions

chat:me@example.com?body=URL%20Encoded%20String

  • This pre-fills a message to be sent to the specific user.
  • Identical syntax to email's mailto:
  • Could also include base64 encoded data for images and other attachments.

With multiple participants

chat:me@example.com,+447700900123,alice@example.org

  • Start a chat with several participants.
  • Again, identical to email's mailto syntax.
  • Could also be combined with the ?body= above.

Ephemeral Support

chat:me@example.com?timeout=60&body=This message will self destruct

  • Requests that the receiving client will discard the message after a timeout specified in seconds.
  • It is up to the receiver to comply with this request.

And Then...

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.


Share this post on…

What links here from around this blog?

What are your reckons?