Isotoxin: a free Tox multi-protocol messenger

You must have heard of Tox. Let me remind you: this is a free secure p2p protocol for transmitting messages, audio and video streams between participants in a Tox network. In fact, this is an alternative to skype. When I first heard about Tox, my degree of dislike for skype was still not too high, but I had already started looking for alternatives. I really liked the idea underlying Tox: we write a protocol with all the necessary goodies, and you write clients to it. When the first clients for the Tox network appeared, I thought: “hell, I can do it no worse!”. In general, pushed by hostility to Skype, I took up the project of my dream messenger. Now, when the first commit was 19 months old in my local hg repository and the 414th commit was made, I finally ripened before telling Habr to a wide audience about this client.

What is done

• Full support for all the current features of the tox protocol, including video calls (except for changing nospam, but I strongly doubt that there is a person in the world who really needed this opportunity to use)
• Own protocol for communication within the local network (it was created mainly for debugging the plug-in system, but it is quite functional: everything is the same as in tox, except for video)
• Support for the simultaneous operation of several protocols (for example, you can have two tox connections with different IDs at once)
• Standard features of a spherical messenger, such as saving history, avatars, emoticons, notification of the arrival of a message, etc.
• Advanced features such as metacontacts, audio / video calls, desktop sharing, group chats, message search, file transfer
• Profile encryption with a password. A profile is a file, sqlite base, with all settings and message history.
• Support for "skins" in the interface
• Automatic updates

Of course, much remains to be done, but what has been done is quite enough for comfortable use.

Development

I have quite a lot of experience in C ++ and programming under Windows. It is foolish to neglect this experience, so development was started in C ++ and under Windows. However, realizing the importance of supporting different platforms, I immediately decided to minimize the dependence on winapi and other windows-only capabilities. My text rendering doesn’t even use GDI, but my own is written. To read fonts, the FreeType library is used. The whole GUI, all controls - everything is written from scratch and is not tied to the system. All work with winapi windows is taken out in a separate place and is abstracted as much as possible from the interface logic. The problem is small - learn to write under Linux. So far, I don’t have time for this. Maybe there are those who want to port?
From the very beginning I conceived a modular architecture. The executable should have been able to only GUI and nothing more. All network affairs were entrusted to the modules. Simply put - the usual plugin system.
One of the difficulties encountered during the development process is the complete reluctance of the tox kernel to build under Visual Studio. The whole thing turned out to be in dynamic arrays of C99 standard. irungentoo, the core kernel developer, rejects any request to remove these arrays from the code, saying: “C99 is standard. If msvc does not support it, then this is his problem. " If you are interested in my personal opinion, then I consider dynamic arrays to be evil, because they kill the constancy of the sizeof operator. So I completely understand the developers of the msvc compiler and their reluctance to communicate with dynamic arrays. So, I had two ways: to collect toxcore separately through cygwin (as other Tox client developers do under windows) or remove dynamic arrays from the code myself. I chose the second path and as a result I came into the worldThis repository. This is not a direct fork of toxcore, but a kind of assembly from the necessary libraries (libsodium, opus, vpx), which is easily and painlessly assembled by the msvc compiler (supported in 2013 and 2015).
Almost all of Isotoxin’s code was written by me alone, with the exception of a few points written by my friends, as well as third-party libraries. The features of C ++ 11 are actively used. In connection with the release of the update for the 2015th studio and the correction of some critical bugs for me, I plan to completely switch to this compiler in order to use constexpr and C ++ 14 to the fullest.

Architecture

When I just started writing the first lines of Isotoxin's code, my plans completely lacked the desire to open source. However, there was a contradiction with the license GPL3 , under which it was proposed tox core . What is the contradiction? In short, this license requires you to open the source code of a program that uses the library under this license. The obvious solution to this dilemma is to move the protocol implementation into a separate dynamic library (dll) and open the source for that dll.
But I decided to go a little further and did not limit myself to just dll. As a result, the following architecture was born.
1. isotoxin.exe- clean GUI. At first, I did not want to open its source. To increase the degree of trust in this file, I even decided to completely deprive it of the ability to work with the network. Later, when I nevertheless refused to be closed, work with the network was returned, but only for one purpose - checking and downloading updates.
2. plghost.exe - Small exe'shnik that loads the dll-ki protocols. More precisely - only one dll. It is launched directly from isotoxin.exe and communicates with the latest means of interprocess communication, translating its commands into the protocol dll and sending back the result.
3. proto. *. Dll - Actually the protocol dlls. Implement a single interface.

This architecture has advantages and disadvantages.

Merits.

• Differentiation of code responsibilities. You can’t just take and call any protocol function from the GUI and vice versa. This disciplines and helps to write clear and safe code with a minimum of errors.
• Reliability. Protocol errors leading to crashes will not drop the GUI. In the event of plghost.exe crash, the latter is simply reloaded. The user may not even notice the problem.
• Security. The user - paranoid - can impose on plghost.exe with different rules for working with the disk, for example, completely restrict writing and reading. Everything will work as if nothing had happened, and even if an attacker can use the protocol implementation vulnerability to access the code, he will not be able to leave the sandbox.
• For the future - support for the simultaneous operation of both 32-bit and 64-bit protocol implementations. It is enough to collect the 64-bit version of plghost.exe. T.O. the release of a 64-bit version of Isotoxin (and I do not exclude that this will happen) will not entail the need for an urgent release of 64-bit versions of third-party protocols, if any.

Disadvantages. And what about without them.

• Significant complication of the code and its debugging. The simultaneous debug of several exe-shnik is not sugar.
• Extra file (plghost.exe)
• System resource requirements are slightly higher. Nevertheless, launching an additional exe on each working protocol is not free.

The list of shortcomings turned out to be somehow small and not serious. I could not think of anything more than that. And, therefore, I consider the choice of architecture to be correct.

Appearance

I admit, the designer from me is awful, so I immediately put in the program the ability to change the appearance. Simply put, skins are supported. So far, only one topic is available. Alas, my time for everything is not enough at once. In the near future I plan to make support for coloring the topic. Under the spoiler are a few screenshots of Isotoxin.

Benefits

It is clear that every developer tries to praise his product. I will try to be as objective as possible. At present, qTox should be recognized as the most popular and feature-rich among all clients supporting the tox network. However, Isotoxin bypasses qTox on almost all counts (excluding, of course, non-windows support).

• Portability. At some point, qTox ceased to be portable. Perhaps the portability was returned to him again, I do not know, did not check.
• XP support. qTox can no longer be run under Windows XP. For some, this can be a problem. Isotoxin works under XP without problems
• Stability. Isotoxin almost does not fall. Every fall is my personal tragedy. Until I get to the bottom of the cause of the fall, I do not calm down. qTox has fallen, even without active use
• Additional features that are not in the protocol. In my toxcore fork , I introduce new features, of course, with backward compatibility. When Isotoxin detects Isotoxin on the other end of the wire, these features are turned on. One of these features is an unlimited message length (other clients follow the recommendations of the creators of the kernel and cut long messages with a space)

There is much more, but I will not describe everything in order not to clutter up the article and not turn it into an advertisement.

Plans

There are many plans for the future. In addition to adding protocols (I really want to add Telegram and jabber), there is a great desire to port to Linux. For a knowledgeable person this should not be a problem. As I wrote above, I do not use any special features of Windows. In general, the idea is to make a full replacement for skype.

References

Project site: isotoxin.im
Project forum: isotoxin.im/forum
Project site on the i2p network: isotoxin.i2p (here, sometimes, intermediate versions appear)
Source code: github.com/isotoxin/isotoxin
Blog dedicated to the project: isotoxin-dev .livejournal.com