Good evening fellow hackers, the Tox-project[0] has recently come to my attention and I'd really like to share it with you, as it is a project housing a great potential to finally replace Skype for all your IM, VoIP and MoIP needs.
For everyone who is not yet familiar with it: tox-core provides a C-API handling all the IM-related stuff in the background (afaik even logging), making the development of Tox-clients very simple. There are numerous clients for Tox, the two most popular are Venom[1] (GTK) and toxic[2] (ncurses). Apart from the cmake-build-system, the former is good and has a decent user-interface. The latter however, being the only CLI-client, leaves a lot to ask for. This is the reason why I am bringing up this topic: If we start discussing and developing a clean, suckless client for the tox-core by now, it may just be ready when the tox-core reaches the aimed feature-set for broad use in a few months. First of all, I'll discuss the problems of the given toxic-client (and why it's unfixable) before I bring in some suggestions for a new design: 0) It's GPL'ed (well, I learned to love MIT/X) 1) auto*hell 2) messed up ncurses-rendering (check it out, the flashing makes me sick) 3) hardcoded nodes Well, I'd probably send in some patches (like so often), but I just can't live with the fact this client is missing out on so many opportunities we haven't really seen before, and that's where my ideas for a rewrite come along: 0) MIT/X license of course 1) Makefiles (!) 2) ncurses needs to be discussed. A design like we have with ii would be very creative, but (imho) not very pleasant in everyday life with a proper secondary interface on top of it. Handling files for IO is great for writing IRC-bots and the like, but most people would definitely prefer a small, clean and suckless client for everyday use (and most probably, written in ncurses). We discussed ncurses before and we might want to look into termbox[3] for that matter. 3) allow the nodes to be specified in the config.h. this gives much greater freedom to the user while still keeping it simple if you go for the defaults. 4) *VoIP* on the terminal. I know of no CLI-IM-client implementing VoIP-facilities when the protocol offers it. Most of the time, using the CLI limits you in this regard and it's definitely time to break those unnecessary handcuffs. Tox-VoIP isn't ready yet (only call-auditing is still missing), but from what I read in the code it handles the streams with SDL. Combining this with Alsa should be feasible (maybe even over SSH). 5) *Videochat* on the terminal. This could be done by spawning a small player-window (just like mplayer without X; SDL probably offers it), allowing the window manager to do the window management, unlike Skype, which tries to do it for you (and does a horrible job). 6) config.h details: As stated above, a list of nodes. What I could also think of is a compile-time-definition of the user-related-details, so you might just able to carry your statically-linked toxic-client around on an USB-stick with all your presets already set in the central config.h. This could be a huge step over the common Skype-configurations, which depend on the user moving the multitude of config-directories around each time he switches computers if he wants to keep his logs; Everything else (nick, friends, avatar) is handled on the servers, which we haven't got here. Additionally, the config.h of course would store the audio- and video-devices to use and other things I can't think of right now. 7) The UI should be really simple. Unlike toxic, I would scrap the prompt and just include a log-window. Entering commands should be possible by pressing TAB or something else in the chat-field, changing it to a prompt. Looking at the toxic-code, a _lot_ of time has been spent on implementing the prompt (read prompt.c). This is one case of unneeded complexity which could easily be dealt with by just handling it all in one field. You can find a sketch of what I was thinking about right below: ## chat window ## [friend's name] [status] [status message] ([call status] (...)) -------------------------------------------------------- chat log -------------------------------------------------------- text field -------------------------------------------------------- [log] [contacts] [chat1] [chat2] [chat3] ## log window ## [client name & version] ([call status] (...)) -------------------------------------------------------- log -------------------------------------------------------- prompt (it would directly jump into this mode) -------------------------------------------------------- [log] [contacts] [chat1] [chat2] [chat3] ## contacts window ## [client name & version] ([call status] (...)) -------------------------------------------------------- 1 [friend 1] [status] 2 [friend 2] [status] 3 [friend 3] [status] (...) -------------------------------------------------------- special friend prompt for quick access (tab-complete, number, w/e, ...) -------------------------------------------------------- [log] [contacts] [chat1] [chat2] [chat3] *tl;dr*: Please let me know what you think about this concept and if you agree or see it completely different. I worked on quite a lot of patches in the last few days to fix toxic, but I just found it to be broken beyond repair (in suckless-terms). It should be a good reference for implementing tox-core. Releasing a client under the well-renowned suckless-name would definitely bring in more trust into the Tox-IM-protocol, and, if it turns out to be successful, in turn make the suckless-philosophy more popular. It was only coincidence that I heard of this great piece of software, let's proceed and make something with it! Cheers FRIGN [0]: https://github.com/nurupo/ProjectTox-Qt-GUI [1]: https://github.com/naxuroqa/Venom [2]: https://github.com/Tox/toxic [3]: https://github.com/nsf/termbox -- FRIGN <d...@frign.de>
