All existing messengers have their pros and cons, but each of them pulls the blanket to its side due to incompatibility with others - and users suffer from this.
XMPP could be the only standard, but unlike E-Mail, it appeared relatively late and did not manage to reach enough audience so that corporations could not refuse it. After all, they there quickly realized that without retaining the audience within their own ecosystem, they would not earn much. And besides, it must be admitted, XMPP had enough flaws due to the abundance of extensions, many of which, despite their importance, remained in experimental status, and some even duplicated each other.
Having lived in the “new brave world” a dozen messengers in the smartphone, and having felt all the flaws of this state of affairs, we are finally ready for something new.
And yes, we need a new standard!
Perfect Future Messenger meets the following requirements: ensuring reliability, security, through open development and decentralization, portability (cross-platform), multiprotocol (ability to connect to other communication networks) and user-friendliness.
Why is everything so bad?
But first, let's see, why not everyone just switch to one already popular == centralized messenger, be it a conditional WhatsApp, or, say, Telegram, which has a considerable audience in Russia.
Of course, a centralized building allows owners to earn more, and thus not only pay back the development, but also invest significant money on advertising and even glorification of practically absent functions , such as security services, for example. However, at the same time, the owner may suddenly decide to close the service, the tractor to move the wire from the data center, or simply the messenger may be banned in the territory of a certain country. Not necessarily for political reasons, perhaps at the request of conditional holders, there may be many reasons. It’s good if, despite the insignificant size of the market, Telegram continues to work in Russia with varying success, but this is due to the personal accounts of the owner, and in case of blocking the same WhatsApp, Facebook is unlikely to invest significant amounts to bypass blockages.
It is difficult to speak immediately for all centralized instant messengers, collecting one size fits all. There is an absolute evil with a proprietary client, server and protocol that even work on only a few of the most popular platforms and have no encryption. There is also a relative good, for example, the Signal messenger, which is completely open, but the servers do not support the federated mode, because of which all depend on the central server with all the ensuing consequences. Here, the classification according to a different principle should be carried out, but this is beyond the scope of this article.
Well, why not go on to something federal. For example, the same Matrix. I will not talk about HTTP Long Polling, poor server fault tolerance, and the blatant reticence of the client interface — these are all solvable tasks, even if they are not trivial (at the global level, this does not change anything). I like the fact that developers have taken into account XMPP experience and are developing uniform specifications instead of a heap of independent XEPs, but this is just one of the shortcomings of XMPP. Another problem is the classic device of the federated network, when we have to choose a server and trust its owner, that he will ensure the server’s performance and will not shut it down. And in the case of the next failure of the data center, we will be cut off from the world, not being able to communicate with the past account on another server. Even if you create a new account, and somehow transfer your contact list from the old server to it, when communicating, you will have to somehow confirm again that this is really you, and not someone who seems to be you.
In this case, maybe, completely abandon the servers? There are a number of instant messengers based on serverless technology. A special case here is the popular Firechat in narrow circles, which uses a mesh network of wifi and bluetooth devices to communicate with users. This messenger really works well when all users are concentrated, for example, on the square. But this is a rather specific situation and even if one imagines a situation when every inhabitant of the planet installs an application - this creates a lot of other problems, from discontinuity of the mesh network according to geographical features and the speed of exchanging messages with distant users, to the amount of necessary data stored on the devices. But, probably, this messenger is knocked out of the total mass and in our comparison is superfluous. It is more experimental than user-specific.
There are also projects such as Tox, trying to implement a p2p messenger. This approach allows you not to worry about the safety of the server, and blocking such an instant messenger is almost impossible. Tox has a lot of problems, but this is a very interesting project that has its own niche. It makes no sense to list the specific disadvantages of Tox, because the project is developing and despite the fact that p2p services are much more difficult to develop, if you set such a task, you can come up with various interesting architectures for building such a network: with its own advantages and disadvantages, different requirements for the width of the Internet channel and the amount of space on the device, with super nodes, simultaneous input from different devices and even the delivery of offline messages. But there will always be a common traffic redundancy compared with the client-server architecture and increased battery discharge on mobile devices due to the need to constantly hold a large number of connections and various calculations.
Thus, even though p2p is an interesting technology, it will prove inefficient if necessary, say, send your coordinates to rescuers, being somewhere on the tree in the taiga with almost no internet connection and 1% battery charge.
How to fix it?
Therefore, I want to present a hybrid client-server architecture, which took the best of the existing approaches, and avoided their shortcomings.
So, in order for our instant messenger with the minimum necessary resources to work on mobile devices, we will use the client-server model, where the maximum computational operations and resources demanding for traffic are concentrated on servers, and on the client side the data is decrypted and displayed to the user.
Addressing
Each user receives his address in the format of E-Mail, or XMPP, that is, nickname @ domain. But unlike the above services, the indication of the domain does not carry the same important address role in this architecture.
Domains are more likely used as nickname registrars in order to exclude the option when all existing nicknames can be used intentionally or unintentionally.
On the Internet, domains cost money, which does not exclude mass registration, but significantly reduces its scale. In centralized services, the entrance is often tied to a mobile phone, which is also not an exclusive factor, but SIM cards are also not taken from the air! And in this connection, by the way, it is interesting how they are going to deal with this in the https://toxme.io/ - service for Tox, which allows associating long keys with a short nickname. I see no reason why they cannot be spammed with billions of junk nicknames.
In addition, a domain can make sense for different accounts for home and work. Or for the organization of internal corporate network.
From the user's point of view, in order for someone to write, you need to know his full login or public key.
From the point of view of the server software, if a user is requested by his key fingerprint, the server searches in its table for the login associated with it, if it is requested immediately by login, respectively, this step is skipped. Then the login and the address of the server to which the account is currently delegated is matched. If there are no such records, it is considered that the server that is specified after @ in the login is responsible for the account.
User Profile
The client application stores a user profile representing:
- Full user login
- List of duplicate servers
- Public and private user key
- Profile information, such as contact list, chat and user profile settings
The public keys of each user are distributed between each of the servers in the federated network. The user can log in to any of the servers, since the authentication is not the password hash stored in the server database, but the user's private key.
The authorization procedure is as follows: the server sends a random set of data to the client, encrypted with the client’s public key, the client decrypts with its private key, and sends the hash of the decrypted data to the server. If the data hashes match, the server authorizes the user. At the same time, if the user has changed the server to which he is connecting from last time, then all the servers of the federated network are notified of the new location of the user.
The absence of the need to remember a password (however, the client allows you to encrypt a private key) both simplifies the interaction with the messenger and creates the risk of losing your keys. To avoid this, it is recommended to duplicate them to other devices of the user. Nothing prevents you from chatting under one account at the same time from several devices, the only restriction is that all of them must be connected to the same server, otherwise the architecture will become too confusing. But this is hardly a big minus.
Browser add-on
For many products, the vulnerable point is a web application. And this solution certainly has a lot of flaws. Such a chat will not be loaded while you are offline, then you will need to wait for a full download, and the address may be blocked, or the server may crash. Manually sort through addresses - I would not particularly like to.
And the option is not excluded that the attacker hacks the web application and embeds code that will merge all your data - after another part of the application decrypts it for you, and you don’t even know about it.
In this regard, I propose to abandon the web application as such, and suggest installing a browser add-on, in which all these flaws are by definition absent.
In addition, the absence of the need for server owners to configure the web client will lower the entry threshold for creating their own server. Every household has its own server!
Transports
Who needs an instant messenger in which there is no one to communicate with? There are interesting projects of unusual messengers, but the problem of lack of an audience does not allow them to gain at least some popularity. As a result, most of the time messengers with a large audience get even more of the audience, and messengers with a small audience lose it. And most often this situation can only change significant investments in advertising.
Well, besides, this situation requires the installation of another messenger, when you need to urgently contact someone who is not in other networks.
Therefore, the server must support the work of transports to third-party networks.
If the user specifies the data to connect to his accounts in other messengers, he will appear in the contacts of people from those networks that he connected.
Connection to third-party networks is made on the server side, and in the client contacts are displayed as the most common, with minimal differences — for example, the icon of the network from which the user is from.
As a disadvantage, it becomes necessary to trust the server with your data to connect to third-party networks. Not everyone is ready to delegate their authority to a third-party server, so it is necessary to strongly encourage the creation of your own servers.
Cryptography
Of course, the decentralized device of the network does not allow to do without encrypting all the transmitted data, because we can not be sure that even a trusted server does not have a tab in it that merges all the data.
It has already been stated that the key pair of the user is used for authorization, all messages sent to other users are also signed with the sender's private key and encrypted with the public key of the receiving party.
Nothing new here, using standard GPG encryption.
The issue of encryption in groups has not yet been resolved, but you can probably use the mechanism used in Signal.
What has been done
At the moment, we have already created a Python server using Tornado, which implements the basic functions of the messenger, there is a slightly frozen web version that needs to be converted in addition to the browser, there is a library on Rust, on the basis of which the client works with the QML interface.
Connection to the server is done using WebSockets, in which the data is serialized by default into a binary representation format of the CBOR data, but when establishing a WebSockets connection, it is possible to request another format, say, protobuf.
I also consider it important to note that the client uses a division into a list of chats sorted by the date of the last messages widely used in modern messengers, and a traditional roster, with the sorting of contacts into categories. With the active use of the messenger, you have to interact with a large number of chats, and it becomes difficult to search for them in the ever-changing list order. In the same Telegram partially solves the problem of fixing the selected chat at the top of the list, but this is only a temporary solution to the problem.
→ Here are the repositories that contain our work