This is a translation of this article in French.
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, or just the phone number currently in use. Smart isn’t it?
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 so end-to-end encryption is a good compensation for all this generosity.
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, though.
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:
- Telegram (They played both bonus points from the start and they are pretty clear on how they get their contacts, in the FAQ:
Q: Who can I write to?
You can write to people, who are in your phone contacts and have Telegram.
For more ideas:
And for those who are not lazy, there is real Instant Messaging, there is XMPP.
Thanks to liori and lool0 for the help and corrections.