ratox ratox is a client implementation of the rather popular tox protocol. Unlike other clients relying on GUIs as an interface to the user, ratox is developed with the UNIX-philosophy in mind and allows complete interaction through named pipes.
Repository: | http://git.2f30.org/ratox/ |
Maintainers: | 2f30 |
Language: | C |
Operating Systems: | Linux, OSX |
NOTE: Some of these features are not intended to be developed in ratox itself but rather in external scripts[1] that are built upon ratox.
ratox has not been updated to use the new Tox API yet, and must be compiled against the old api, which is available here here as a zip and as a tar.gz file. However, installing the old API alongside the contemporary API can be confusing and potentially cause conflicts. There are a few ways to work around this and get a binary of ratox running.
This one is time and space consuming, but it's also relatively easy and offers an environment in which you can continue to build against the old API for as long as it works. As of the time of this posting(2015/9/23), it's still possible to send messages between an official version of nTox from the Debian repo and a home-compiled version of ratox built in a chroot. This means that the old API still works, for now. For any fledgling programmers and admins new to the concept of a chroot, it's a way of using a directory on your computer as if it were your root filesystem, which allows you to install the dependencies you'll need to build ratox without interfering with your real root system.
You'll need to install the debootstrap and chroot packages from your package manager. Just do
sudo apt-get install debootstrap chroot
or install via your own preferred package manager.
First, create a folder for holding your old Tox API project workspace. This will be the base of your chroot filesystem.
mkdir -p ~/oldtox_workspace/
Next, use debootstrap to install a basic filesystem into that folder. debootstrap will retrieve and set up a base Debian system into the workspace folder.
sudo debootstrap <your-distribution-codename> oldtox_workspace
You'll have to mount the /proc and /sys pseudo-filesystems in your guest before you can compile ratox. You can do this two ways, depending on what you need.
If you are going to be using the old Tox API frequently, then you may be better off adding your chroot's /proc and /sys pseudo-filesystems using your base system's /etc/fstab. This will cause them to be mounted automatically.
proc /home/you/oldtox_workspace/proc proc defaults 0 0 sysfs /home/you/oldtox_workspace/sys sysfs defaults 0 0
If you're just wanting an environment to compile Ratox in so you can use it, perhaps to write more nuggets or even something like Catox, a Ratox-Based Tox client, then I recommend creating a helper script which you can run to mount the pseudo-filesystems and launch into the chroot automatically.
#! /bin/sh sudo mount proc $HOME/oldtox_workspace/proc -t proc sudo mount sysfs $HOME/oldtox_workspace/sys -t sysfs sudo chroot oldtox_workspace
apt-get install build-essential libtool autotools-dev automake checkinstall check git yasm libsodium13 libsodium-dev
If you're running an oldstable or LTS, your distribution's package manager may not have libsodium yet. You can do a couple of things to change that, and since you're in a chroot the consequences are pretty minimal. If you can't install libsodium from your package manager, you're choices are to:
libsodium has minimal dependencies and compiles in the pretty much the classic autoreconf, make, make install pattern.
git clone git://github.com/jedisct1/libsodium.git cd libsodium git checkout tags/1.0.3 ./autogen.sh ./configure make check sudo make install cd ..
You can also get it from Jessie while still keeping most of your system on oldstable.
echo "deb http://ftp.debian.org/debian jessie main" | tee /etc/apt/sources.list.d/jessie.list
And make sure that apt knows to only use Jessie's packages when instructed to.
echo "Package: * Pin: release a=oldstable Priority: 999 Package: * Pin: release a=stable Priority: 500 " | tee /etc/apt/preferences
Remember these steps are only necessary on oldstable(Debian 7 “Wheezy”) and older versions of Ubuntu.
You'll also need to install the Tox AV libraries to build ratox. Here's how to work out it's dependencies, including on older versions Debian based systems.
sudo apt-get install libopus-dev libvpx-dev pkg-config
If you're on an older version of Ubuntu and you do not have access to libopus through the repositories, the simplest way to get it is though the Ubuntu SDK team's private package archive. Only follow these steps if you don't have access to the packages through your repository.
sudo add-apt-repository ppa:ubuntu-sdk-team/ppa && sudo apt-get update && sudo apt-get dist-upgrade sudo apt-get install libopus-dev
git clone https://chromium.googlesource.com/webm/libvpx cd libvpx ./configure make -j3 sudo make install cd ..
wget http://downloads.xiph.org/releases/opus/opus-1.0.3.tar.gz tar xvzf opus-1.0.3.tar.gz cd opus-1.0.3 ./configure make -j3 sudo make install cd ..
For this part, we first need to retrieve the old Tox API. It's available as a "Release" from Github, dated March 11.
From within your chroot, wget the old API as a tar.gz.
wget https://github.com/irungentoo/toxcore/archive/api_old_version.tar.gz
Now untar and gunzip it.
tar -xvzf api_old_version.tar.gz -C toxcore-old cd toxcore-old
Finally, you can just compile and install toxcore.
autoreconf -i ./configure make sudo make install
All that work you just did makes this step really, really easy. Just
git clone git://git.2f30.org/ratox cd ratox make sudo make install
and that's it. You now have a ratox binary you can use, study, modify, or package as you see fit.
An old, but possibly still useful way of using ratox, catox
SSH over TOX for the practical paranoid
On the sender side (the client): 1) cd into the friend's directory (the server) 2) nc -lv 1234 > file_in < file_out
On the receiver side (the server): 1) cd into the friend's directory (the client) 2) cat < file_out | nc localhost 22 > file_in
Now on the client run the following: ssh -o ProxyCommand=“nc %h 1234” user@localhost
Screencasting using ffmpeg and mplayer
On the sender side: ffmpeg -f x11grab -r 10 -s 1366×768 -i :0.0 -vcodec libx264 \
On the receiver side: mplayer -cache 1024 file_out
You may have to play about with the cache size.