Isotoxin: a free multi-protocol messenger with Tox support

You must have heard about Tox. Let me remind you: this is a free protected p2p protocol for transferring messages, audio and video streams between members of the Tox network. In essence, 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 begun searching for alternatives. I really liked the idea behind Tox: we write a protocol with all the necessary buns, and you write clients to it. When the first clients appeared for the Tox network, I thought: “damn it, I can do it no worse!”. In general, prompted by the hostility to Skype, I took up the project of the messenger of my dreams. Now, when in my local hg-repository, the first committee turned 19 months old and the 414th committee was made, I finally matured to talk about this client to a wide audience Habr.

What is done

• Full support for all current capabilities of the tox protocol, including video calls (excluding the nospam change, 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 (created mainly for debugging the system of plug-ins, but it is fully functional: everything is the same as in tox, except for the video)
• Support for simultaneous operation of multiple protocols (for example, you can have two connections to tox 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 meta contacts, audio / video calls, desktop sharing, group chats, message search, file transfer
• Password encryption profile. A profile is a file, sqlite database, 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 the development was started on C ++ and under Windows. However, realizing the importance of supporting different platforms, I immediately decided to minimize dependence on winapi and other windows-only features. I don't even have text rendering using GDI, but my own. For reading fonts library FreeType is used. All GUI, all controls - everything is written from scratch and is not tied to the system. All work with winapi windows is placed in a separate place and is abstract as much as possible from the logic of the interface. The problem is small - to learn how to write under Linux. So far I have no time for this. Maybe there are willing to port?
From the very beginning, I conceived a modular architecture. The executable file should have been able to only GUI and nothing more. All network files were assigned to the modules. Simply put - the usual plugin system.
One of the difficulties encountered during the development process is the complete unwillingness of the tox kernel to build under Visual Studio. The whole thing turned out to be in dynamic arrays of the C99 standard. irungentoo, the main developer of the kernel, rejects any requests to remove these arrays from the code, saying: “C99 is a 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, since they kill the constancy of the sizeof operator. So I fully understand the developers of the msvc compiler and their unwillingness to communicate with dynamic arrays. So, I had two ways: collect toxcore separately via cygwin (as other Tox client developers use under windows) or remove dynamic arrays from code myself. I chose the second path and as a result this repository came to light. This is not a direct toxcore fork , but some kind of build from the necessary libraries (libsodium, opus, vpx), which is easily and unscrupulously assembled by the msvc compiler (2013 and 2015 are supported).
Almost all the Isotoxin code is written by me alone, except for a few moments written by my friends, as well as third-party libraries. C ++ 11 features are actively used. In connection with the release of the update to the 2015 studio and fixing some bugs that are critical 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 the Isotoxin code, I had absolutely no desire to open the source code in my plans. However, there was a contradiction with the GPL3 license, under which the tox kernel was offered . What is the contradiction? In short, this license requires you to open the source code of the program that uses the library under this license. The obvious solution to this dilemma is to put the implementation of the protocol into a separate dynamic library (dll) and open the sources of this dll.
But I decided to go a little further and not limited to only dll-Coy. As a result, the following architecture was born.
1. isotoxin.exe is a clean GUI. At first, I did not want to open its source. To increase the level of trust in this file, I even decided to completely deny it the ability to work with the network. Later, when I still refused to be closed, work with the network was returned, but for only one purpose - checking and downloading updates.
2. plghost.exe - A small exe'shnik that loads dll protocols. More precisely - only one dll'ku. It is launched directly from isotoxin.exe and communicates with the latest interprocess communication tools, translating its commands into the dll protocol and sending back the result.
3. proto. *. Dll - Actually dll'ki protocols. Implement a single interface.

This architecture has advantages and disadvantages.

The merits.

• Separation of code duties. You can not just take and call any function of the protocol from the GUI and vice versa. It disciplines and helps to write clear and safe code with a minimum of errors.
• Reliability. Protocol errors leading to a crash will not drop the GUI. In the case of plghost.exe crash, the latter is simply downloaded again. The user may not even notice the problem.
• Security A paranoid user can impose plghost.exe with different disk rules, for example, to completely restrict writing and reading. Everything will work as if nothing had happened, and even if the 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 simultaneous operation of both 32-bit and 64-bit protocol implementations. It is enough to build the 64-bit version of plghost.exe. So the release of the 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. Simultaneous debag of several exe-shnik is not sugar.
• “Extra” file (plghost.exe)
• System resource requirements are slightly higher. Yet running an additional exe's for every running protocol is not free.

The list of shortcomings turned out to be somehow small and frivolous. Nothing beyond this, I could not think of. And, therefore, I consider the choice of architecture correct.

Appearance

I admit, the designer of me is awful, so I immediately put in the program the possibility of changing 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 Isotoxin screenshots.

Benefits

It is clear that each developer tries to praise their product. I will try to be as objective as possible. Currently, qTox should be recognized as the most popular and rich in capabilities among all clients that support the tox network. However, Isotoxin bypasses qTox on almost all items (excluding, of course, non-windows support).

• Portability At some point, qTox stopped being portable. Perhaps the portability was returned to him again, I do not know, did not check.
• XP support. qTox can no longer run under Windows XP. For some, this can be a problem. Isotoxin works under XP without problems
• Stability. Isotoxin is almost not falling. Every fall is my personal tragedy. Until I get to the bottom of the cause of the fall, I do not calm down. qTox I fell, 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 too, these capabilities are enabled. One such opportunity is unlimited message length (other clients follow the recommendations of the creators of the kernel and cut long messages by a space)

There is a lot more, but I will not describe everything in order not to litter 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 under Linux. For a knowledgeable person this should not be a problem. As I wrote above, I do not use any special features of the "Windows". In general, the idea is to make a full replacement for Skype.

Links

Project website: isotoxin.im
Project Forum: isotoxin.im/forum
Project site in the i2p network: isotoxin.i2p (here, it happens, intermediate versions appear)
Source Code: github.com/isotoxin/isotoxin
Blog dedicated to the project: isotoxin-dev.livejournal.com