GSoC 2014 Ideas

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.

Project link.

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:

• Login dialog is created.
• Users are able to create new profiles, either raw or encrypted.
• Users are able to login in any of already created in Qt GUI profiles.
• Users are able to re-log under different profile without restarting the application.
• Export/Import dialogs are created.
• Users are able to export their profile in raw or encrypted.
• Users are able to import both raw and encrypted data files.

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:

• File transfer manager widget is implemented.
• Users are able to send and receive multiple files.
• Users are able to drag'n'drop files for sending.
• File transfer manager stores its history in a SQLite database and is able to load it “on fly” (on scroll).
• A master file transfer manager that merges all user-specific file transfer managers' data.

Related issue: #68 #60 #85

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:

• Users are able to make a/v calls without much (any?) configuring.
• A/v works across all platforms Qt supports.
• Qt UI widget for a/v (video displaying, some control options such as mute, etc.), built with future support of group chat a/v conferencing in mind.

Knowledge Prerequisite: C++ and Qt

Difficulty: Medium / Hard

Mentor: nurupo, #tox-dev on Freenode, <nurupo dot contributions at gmail dot com>.

Project link.

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:

• Users will be able to make audio or video calls using the Tox client Venom.
• Users will be able to do this without playing around with any settings or configs.

Knowledge Prerequisite: Vala, GTK3+, C++ required

Difficulty: Medium / Hard

Mentor: naxuroqa, #tox-dev on Freenode

Project link.

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

• Single-window UI with optional secondary windows
• Looks like a native Mac citizen
• One-to-one and group chats
• Saving and loading of Tox core data
• Transcript view styled using WebKit
• Notification Center support

Features wanted for Poison 2.0

• Multi-window UI with each chat in its own window
• Customizable user interface
• Group chat user list + join/leave events
• Support for working Tox A/V
• File transfers
• Cleaner internals (with modern API usage)

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).

More details.

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.

HTTP relay draft.

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.

Protocol draft.

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