Have another proposal not on the list? Let us know in #tox-dev on Freenode and we'll add it for you.
New? be sure to check out our summary about Google Summer of Code.
Brief explanation: A new library that provides standardized and secure way to save a user profile on a disc appeared just recently. Most clients are still saving all user data in raw, meaning that once a data file is stolen, you lose your “Tox account”, but with that library you can password-encrypt your data file when storing it on a disc. Currently, Qt GUI doesn't save the data file at all, so every time user runs the Qt GUI client – a new messaging profile is created, nothing carries over except GUI-specific settings. A student is to implement support of multiple profiles. This will require not only writing code, but also making a UI for login and import/export profile dialogs (though we do UI in code anyway).
Expected results:
Knowledge Prerequisite: C++ and Qt
Difficulty: Easy / Medium
Mentor: nurupo, #tox-dev on Freenode, <nurupo dot contributions at gmail dot com>.
Brief explanation: This project is more UI intense than other two projects. A student is to implement file transferring in Qt client. Toxcore library already provides convenient functions for sending and receiving files, so all is needed is to make the UI part – a nice file transfer manager widget, something similar to Firefox's download manager.
Expected results:
Knowledge Prerequisite: C++ and Qt, familiarity with Qt Widgets and SQLite
Difficulty: Medium
Mentor: nurupo, #tox-dev on Freenode, <nurupo dot contributions at gmail dot com>.
Brief explanation: A/v support was just recently merged into toxcore, so it's time to add a/v support in the Qt client. The main challenge here is to find a cross-platform a/v capturing solution, integrate it in the Qt client, make it work with toxcore's a/v API and make sure that it works right on major Qt-supported platforms.
Note that QCamera from QtMultimedia is deprecated since Windows XP+ and provides very limited functionality, which might not be enough for camera capture support.
Expected results:
Knowledge Prerequisite: C++ and Qt
Difficulty: Medium / Hard
Mentor: nurupo, #tox-dev on Freenode, <nurupo dot contributions at gmail dot com>.
Brief explanation: As AV support nears completion in toxcore, one of the major challenges is bringing this support to clients. The implementation being worked on means that clients will be responsible for things like capturing frames on their own, between OSes. The fun of this happens when we start to look at OSes with proprietary AV systems, like directshow in Windows.
Expected results:
Knowledge Prerequisite: Vala, GTK3+, C++ required
Difficulty: Medium / Hard
Mentor: naxuroqa, #tox-dev on Freenode
Brief explanation: Poison is a native OS X frontend for Tox written in Objective-C. While it is mostly functional, there is a ton of room for improvement. Because of this, it has been decided that the GUI will be rewritten from scratch, dropping support for OS X 10.6. This will allow Poison to utilize new APIs (i.e. AVFoundation) for cleaner, more modern code. Students will be able to work on both high-level Cocoa code as well as wrapping Tox API calls in Objective-C.
Poison 1.x featureset
Features wanted for Poison 2.0
Expected results: All features of Poison 1.x should be completed, hopefully with some wanted features as well. You won't be doing this all by yourself, of course.
Knowledge Prerequisite: You should be reasonably fluent in Objective-C and OS X APIs. Knowledge of C is required for working with Tox core. You should also have a good eye for design if you plan to work on the UI.
Difficulty: Medium / Hard
Mentor: TBD (but you should e-mail stal<at>tox.im for now)
Brief explanation: As Tox seeks portability between all platforms and architectures, a smaller goal we've established is making sure Tox runs on as many POSIX/ANSI OSes as we can. These range from the oddest research OSes claiming to be more UNIX than UNIX, to things seen not outside of the financial sector.(I'm looking at you, Plan 9 and AIX)
Expected results: The final outcome of this project will be a single Tox, able to work on any Unix like OS it's thrown on without issue.
Knowledge Prerequisite: C, basic understanding of POSIX command line interfaces, able to deal with vms ran off our build infrastructure via ssh.
Difficulty: Easy / Medium
Mentors: stqism, IRIXUser, #tox on Freenode IRC.
Brief explanation: Right now the current build system for the core library is using GNU autotools, this turns in to a mess of overkill and strange settings that end up being needed on some platforms. Funny enough, we used cmake before autotools, not pleasant. As the entire building process is less than a dozen steps, designing a Makefile or shell script to check for dependencies and compile would greatly reduce the issues we see using autotools on a frequent basis. This is important because it will show you how to maintain a larger project without needing to spend more time on making sure it compiles than working on the program itself. Efficiency in programming is vital for projects of this size, and ones far larger than this (think about how Windows, Mac OSX, and Linux are maintained), as adding new files, changing how one thing is compiled, or even just understanding what goes on during the compile process helps tremendously.
Expected results: This new build system will allow for easier builds, without difficult complications or issues.
Knowledge Prerequisite: Shell scripting, UNIX makefiles, possibly a scripting language.
Difficulty: Medium
Mentor: IRIXUser, #tox on Freenode IRC.
Brief explanation: The current audio/video implementation in Toxcore does not scale well to changes in available bandwidth and down/up speeds. With proper congestion control, we'll be able to maintain a fluid connection on everything from a 100 gbps line to 1xRTT. Note that students will be dealing with vp8, and not concepts like frame capturing.
Expected results: Tox's audio/video implementation will be able to utilize adaptive bitrate streaming.
Knowledge Prerequisite: C, understanding of the TCP/IP suite, understanding of adaptive bitrate streaming.
Difficulty: Hard
Mentors: irungentoo, mannol, #tox-dev on Freenode IRC.
Brief explanation: Arguably one of the most important projects in Tox, security is our namesake. Your job will be able to break stuff, find buffer overflows, exploit the protocol, making sure to fix what you find. This will include trying to find ways to exploit Tox's protocol in a way to harm clients or the network, and trying to find ways to exploit Tox as a compiled library, finding vulnerabilities that could lead to intrusion, man in the middle (MitM) attacks, problems with encryption, exposure of decrypted messages, and more. As a security-minded project, this is arguably one of the more long-term important goals of Tox, as anyone could make an instant messaging service, but not one that can completely ensure security in messaging.
Expected results: While not professionally security audited, the student done security audit will allow us to keep working on what we do, knowing that anything we may of missed will be addressed as soon as possible.
Knowledge Prerequisite: C, C++, good understanding of code security principles.
Difficulty: Hard
Mentor: irungentoo, #tox-dev on Freenode IRC.
Brief explanation: Working side by side with the relay team, the Android students will be responsible for designing a client based off the Tox API. The goal of this is to experience what goes on when building a graphical user interface (GUI) from the ground up, when all the necessary APIs are provided already. This means that instead of worrying on how to implement a networked messaging protocol (if it isn't your field, perhaps), you can learn exclusively on how to build an interface that works, and conforms to Android's exceptional Design Guidelines. There will also be the experience of integrating a well-designed app with Tox's API, which may involve learning about context managers, threads, storing data, and more. Learning how APIs and front-end applications are separated, and how to integrate them together properly, results in an excellent, polished end result.
Students working on an Android client using the relay system will also be using a theoretical API, being written along side with other students. Because of this crazy setup, cooperation with the relay team will be great and is a valuable experience, as everyone will always be working alongside someone in a professional workplace.
Expected results: An Android client utilizing the relay draft portion of the Tox API.
Knowledge Prerequisite: Java, Android SDK, Basic understanding of P2P networks.
Difficulty: Medium
Mentors: astonex (mark [at] tox [dot] im), irungentoo, stqism, TBD, #tox-dev on Freenode IRC.
Brief explanation: Working side by side with the relay team, the iOS students will be responsible for designing a client based off the Tox API. As with Android, iOS developers are also encouraged to follow certain iOS Design Guidelines. This is valuable, because going on to design other iOS apps for example, you'll already be accustomed to how things should look, and what you can branch off from to make your own innovative features. This will also involve integrating Tox's API with your user interface, so that the heavy lifting is all done on the network side, and you can focus on making a brilliant looking application that is both functional and appealing. This is also valuable because of learning how APIs and front-end applications co-mingle and intertwine to result in a completed application. Students working on an iOS client using the relay system will also be using a theoretical API, being written along side with other students. Because of this crazy setup, cooperation with the relay team will be great and is a valuable experience, as everyone will always be working alongside someone in a professional workplace.
Expected results: An iOS client utilizing the relay draft portion of the Tox API, this will both show off a Tox client that could go in an app store, and fully functions.
Knowledge Prerequisite: Objective-C, xcode.
Difficulty: Medium
Mentors: irungentoo, stqism, JmanGuy, #tox-dev on Freenode IRC.
Brief explanation: A major issue in Tox is the fact that leaving your PC to Tox someone on the go requires manually transferring a key and getting setup, this KILLS adoption. So, we proposed a solution. A possible solution is the friends list server, a distributed system for sharing blobs abstracted behind credentials a user is familiar with (like a password).
Keep in mind, a student is free to propose his own solution to the problem.
Expected results: Using an optional library, clients will be able to sync with others without issue.
Knowledge Prerequisite: Possible C, possibly a scripting language.
Difficulty: Easy / Medium
Mentor: stqism, #tox-dev on Freenode IRC.
Brief explanation: Right now the peer to peer Tox network runs on lossless UDP connections on port 33445. In mobile devices this leads to large use of data, leading to poor battery life. As well, iOS limits apps to a single TCP socket, harming adoption. One possible solution is encapsulating API calls in JSON over HTTP, bypassing potential blocks on corporate firewalls and mobile ISPs without the need for NAT holepunching.
It goes without saying, the HTTP relay is a draft, students are free to suggest whatever they may feel works best.
Expected results: With the completion of this, next generation mobile clients will be able to chat without the issues the typical Tox network brings.
Knowledge Prerequisite: Java, Python or C, optional understanding of the Tox API (we will teach you).
Difficulty: Medium
Mentors: irungentoo, stqism, #tox-dev on Freenode IRC.
Brief explanation: The keyserver system is just one approach on dealing with public keys something user friendly. This idea is the backend for the Tox Keyexchange Protocol(TOXKP), and while drafted, has not been started. This server shares its data with other servers using a distributed hash table much like the Tox network.
Expected results: A client using libtoxdata will successfully be able to communicate with a Tox keyserver, able to push and pull data using an assigned secret.
Knowledge Prerequisite: Java or Python, minimal understanding of the TCP/IP stack
Difficulty: Medium
Mentor: stqism, #tox-dev on Freenode