|
|
|
|
@ -0,0 +1,170 @@
|
|
|
|
|
---
|
|
|
|
|
title: "Best IM of the world"
|
|
|
|
|
date: 2015-06-13T12:00:00+09:00
|
|
|
|
|
tags: [IM, XMPP]
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
__This is a translation of [this article in French](https://nl.movim.eu/?blog/edhelas@movim.eu/urn:md5:f34f066261bc7ea4ff7840470c1b5b4d).__
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Although Instant Messaging (also known as IM) has been in our everyday life
|
|
|
|
|
for a while now, I am under the impression that we limit ourselves to old
|
|
|
|
|
habits or features that we could update to offer our users innovative and
|
|
|
|
|
modern services they all dream about.
|
|
|
|
|
|
|
|
|
|
Here I will share some groundbreaking ideas of mine that flourished as I have
|
|
|
|
|
worked for a few years in this field. You are free to do whatever you want
|
|
|
|
|
with them. Maybe they could be a base for some next generation application
|
|
|
|
|
and revolutionize our communication process.
|
|
|
|
|
|
|
|
|
|
Fasten your seatbelt and let's go!
|
|
|
|
|
|
|
|
|
|
## 1. Redesign Authentication!
|
|
|
|
|
|
|
|
|
|
Let's be honest, credentials are crap, registering an account is counterintuitive
|
|
|
|
|
and annoying. The first thing I would suggest is to rethink the whole
|
|
|
|
|
registration process. This little form you know, that every user must fill in
|
|
|
|
|
on each service, website or platform he wants to log in for the first time.
|
|
|
|
|
|
|
|
|
|
To tell the truth, when the user face this registration form, he hesitates,
|
|
|
|
|
it's always a burden to have to fill in these fields. Why not just remove this
|
|
|
|
|
step? The first time a user logs in, we attribute him a unique identifier (a
|
|
|
|
|
number). We would then invite him to fill in his profile, since he would
|
|
|
|
|
already be logged he would much easily give in information needed to complete
|
|
|
|
|
this step.
|
|
|
|
|
|
|
|
|
|
The point is to manage to correctly uniquely identify the user before getting
|
|
|
|
|
any input. Impossible? It depends what your target platform is. Say we want to
|
|
|
|
|
build an IM service for mobile phone, we can use the [IMEI][1], or just the
|
|
|
|
|
phone number currently in use. Smart isn't it?
|
|
|
|
|
|
|
|
|
|
[1]: https://en.wikipedia.org/wiki/International_Mobile_Station_Equipment_Identity
|
|
|
|
|
|
|
|
|
|
## 2. Federate the network?
|
|
|
|
|
|
|
|
|
|
The previous idea comes with some limitation. Since we want to make the
|
|
|
|
|
registration process execute automatically, we can't ask the user where he
|
|
|
|
|
wants to register his account. We don't want to make the user choose, that will
|
|
|
|
|
lead him to hesitate, and would increase the chances that he would leave.
|
|
|
|
|
|
|
|
|
|
The best solution is certainly to skip this step as well. We would have a
|
|
|
|
|
unique server where every account is created. This way we would have one user,
|
|
|
|
|
one cell phone, one unique account, one service.
|
|
|
|
|
|
|
|
|
|
Better, don't you think?
|
|
|
|
|
|
|
|
|
|
## 3. Add new contacts
|
|
|
|
|
|
|
|
|
|
Once again, users are lazy, and once the account is created they always have
|
|
|
|
|
to add in or invite people they want to talk to. This long and tedious process
|
|
|
|
|
can discourage even the most brave. It would be nice to already have a contact
|
|
|
|
|
list ready for use, with whom the user could talk right away.
|
|
|
|
|
|
|
|
|
|
Where can we find such a list? There must be something on the phone that we
|
|
|
|
|
can use, like a phonebook. Bingo! Let's take the whole list of contacts, send
|
|
|
|
|
it to our server, match it to phone numbers that are already registered and link the
|
|
|
|
|
accounts. This supports our idea of the phone number being the unique
|
|
|
|
|
identifier.
|
|
|
|
|
|
|
|
|
|
Nobody will have any problems with the fact that we keep their phonebook on our
|
|
|
|
|
server in exchange for the great service we provide, right?
|
|
|
|
|
|
|
|
|
|
## 4. Respect the users
|
|
|
|
|
|
|
|
|
|
The previous idea is quite appealing, but it can scare users who are concerned about
|
|
|
|
|
their privacy, and their contacts that wouldn't like their numbers to be sent to a server that they
|
|
|
|
|
don't know about. What can we do to reassure them about handling their personal data?
|
|
|
|
|
|
|
|
|
|
There is one word that can calm everyone down: encryption. If
|
|
|
|
|
communications are encrypted it shows that we do care about their privacy,
|
|
|
|
|
right? We can guarantee them that communications between our users and the
|
|
|
|
|
server will be encrypted. A bit of SSL/TLS here and there and we're done!
|
|
|
|
|
|
|
|
|
|
We can go a step further in this direction to prove our good faith and show
|
|
|
|
|
that we want a modern and innovative service, and encrypt every single
|
|
|
|
|
message! It doesn't really matter since we already have:
|
|
|
|
|
|
|
|
|
|
- the user's phone number,
|
|
|
|
|
- his profile,
|
|
|
|
|
- his complete phonebook with all the attached data (email, address, etc.),
|
|
|
|
|
- and also the entirety of his exchanges (sender, receiver, sending time,
|
|
|
|
|
receiving time, reading time, answering time, weight of the content, etc.).
|
|
|
|
|
|
|
|
|
|
And as we know, [metadata is by far more important than the data][2] so
|
|
|
|
|
end-to-end encryption is a good compensation for all this generosity.
|
|
|
|
|
|
|
|
|
|
[2]: http://www.souverainetenumerique.fr/projet-de-loi-sur-le-renseignement-quelles-perspectives-pour-la-confiance-et-la-s%C3%A9curit%C3%A9-sur
|
|
|
|
|
|
|
|
|
|
## 5. Bonus idea: Open the platform
|
|
|
|
|
|
|
|
|
|
In order for us to maintain the users' trust, we can play the openness card, believe me it works
|
|
|
|
|
every single time. We need two killer arguments for this:
|
|
|
|
|
|
|
|
|
|
#### Provide an API
|
|
|
|
|
|
|
|
|
|
Of course! Some reworking of the communication protocol, a bit of
|
|
|
|
|
documentation in our Wiki and here it is! Openness. Users can now talk to the
|
|
|
|
|
world and write libraries in any language they want. Don't forget to have some
|
|
|
|
|
authorization protocol so you can strike off those who would try to look too
|
|
|
|
|
close.
|
|
|
|
|
|
|
|
|
|
#### Open our client applications
|
|
|
|
|
|
|
|
|
|
Open sourcing our clients would definitely guarantee transparency. Just do it.
|
|
|
|
|
We can then prove that encryption is applied correctly without any flaw. We
|
|
|
|
|
can keep a few backdoors in apps we compile and distribute while keeping the
|
|
|
|
|
codebase opened.
|
|
|
|
|
|
|
|
|
|
A nice ripple effect that we will gain from opening the codebase is
|
|
|
|
|
contributions, bugfixes and new features from the community. We keep a hand on
|
|
|
|
|
the API so we can monitor what comes in and goes out. Be careful of [not being
|
|
|
|
|
too chatty][3], though.
|
|
|
|
|
|
|
|
|
|
[3]: http://www.theguardian.com/technology/2015/may/28/marauders-map-chrome-app-tracks-facebook-messenger
|
|
|
|
|
|
|
|
|
|
## That's it!
|
|
|
|
|
|
|
|
|
|
Here are some ideas that will definitely help you in building the new IM
|
|
|
|
|
application on mobile, you can even try porting it to other platforms with a
|
|
|
|
|
few changes.
|
|
|
|
|
|
|
|
|
|
With the third idea, I can guarantee you exponential growth since you get an
|
|
|
|
|
entire phonebook each time a new user subscribes.
|
|
|
|
|
|
|
|
|
|
Playing the card of openness can be done later, in case problems concerning
|
|
|
|
|
privacy surface, so you can claim transparency. It will
|
|
|
|
|
depend on how open you want to be concerning your users' privacy.
|
|
|
|
|
|
|
|
|
|
## Nobody told me?
|
|
|
|
|
|
|
|
|
|
It seems there are already such apps:
|
|
|
|
|
|
|
|
|
|
- [WhatsApp](https://www.whatsapp.com/)
|
|
|
|
|
- [Telegram](https://telegram.org/) (They played both bonus points from the
|
|
|
|
|
start and they are pretty clear on [how they get their contacts][4], in the
|
|
|
|
|
FAQ:
|
|
|
|
|
|
|
|
|
|
> Q: Who can I write to?
|
|
|
|
|
>
|
|
|
|
|
> You can write to people, who are in your phone contacts and have Telegram.
|
|
|
|
|
|
|
|
|
|
- [Line](http://line.me/en/)
|
|
|
|
|
- [Viber](http://www.viber.com/en/)
|
|
|
|
|
- [WeChat](http://www.wechat.com/en/)
|
|
|
|
|
- [KakaoTalk](http://www.kakao.com/)
|
|
|
|
|
- etc.
|
|
|
|
|
|
|
|
|
|
[4]: https://telegram.org/faq#q-who-can-i-write-to
|
|
|
|
|
|
|
|
|
|
For more ideas:
|
|
|
|
|
|
|
|
|
|
- [Facebook Messenger](https://play.google.com/store/apps/details?id=com.facebook.orca&hl=en)
|
|
|
|
|
- [Google Hangouts](http://www.google.fr/hangouts/)
|
|
|
|
|
|
|
|
|
|
And for those who are not lazy, there is real Instant Messaging, there is
|
|
|
|
|
[XMPP](https://xmpp.org).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
__This article is also available [via XMPP](xmpp:ppjet@bouah.net?;node=urn:xmpp:microblog:0;item=22c35ed3c91fe721f83574df9a1a59bb).__
|
|
|
|
|
|
|
|
|
|
*Thanks to liori and lool0 for the help and corrections.*
|
Maxime Buquet