GSoC 2015 Ideas

See also: Information about GSoC, for our student expectations, proposals guidelines and more.

Brief explanation: You have read this entire page, played a bit with Tox and thought of a super interesting Tox-related project idea that isn't on this page and on which you would like to work during this summer? Come to our IRC and tell it to us, we'll help you work out potential issues and help you improve your proposals. They might even be better than the ideas we've suggested here!

Expected results: To be determined.

Difficulty: You decide.

Mentor: You pick.

Project link.

Brief explanation: While Tox comes along, a lot of minor issues requiring a good bit of work remain. Quite a few popular messaging programs like Skype and Hangouts implement real offline messaging, where 1 person can send a message while the other is offline and then go offline and the other friend will get it. These programs are able to do it because of central servers, but the nature of Tox being a distributed network means we lose this option.

Your task would be to figure out a safe and sane solution to doing real offline messaging in a decentralized way and implement it.

Expected results:

• Research and write a document explaining how you will do offline messages.
• Implement your work.
• Help client developers implement your work.

Knowledge Prerequisite: C, distributed networks, writing secure code

Difficulty: Hard (Be aware that while this may sound easy, the actual work required to get this in to action is substantial)

Mentor: irungentoo

Brief explanation: Toxcore currently suffers from a number of serious issues when 2 Tox objects are used at once on the distributed network. Your task would be to research and implement secure ways of sharing data like secret keys, friends, and chats while making toxcore deal with the same peer having presence in multiple locations seamlessly.

Expected results: * Research ways of securely trading private data with peers (or whatever way of sharing identities you may have) * Implement a way of ensuring a peer can seamlessly appear in multiple locations without issue. * Implement a way of sharing data like friends and chat logs between either the same peer or multiple peers. (Based on step 1)

Difficulty: Medium

Mentor: irungentoo

Brief explanation:

WW91ciBnb2FsIHdpbGwgYmUgdG8gdHJ5IHRvIGJyZWFrIHRoZSBUb3ggbmV0d29yayBieSB3cml0
aW5nIGNvZGUgdG8gYXR0YWNrIGl0LiBGb3IgZXhhbXBsZSwgdHJ5IHRvIGZsb29kIHRoZSBuZXR3
b3JrIHdpdGggYm9ndXMgcGFja2V0cywgYXR0ZW1wdCB0byBkaXNydXB0IHRoZSBuZXR3b3JrIGJ5
IGNyZWF0aW5nIGxhcmdlIGFtb3VudHMgb2YgZ2FyYmFnZSBwZWVycywgZXRjLiBZb3UgY2FuIGVp
dGhlciB0cnkgdG8gY29tZSB1cCB3aXRoIHlvdXIgb3duIHdheXMgdG8gYXR0YWNrIHRoZSBuZXR3
b3JrIG9yIGFzayB5b3VyIG1lbnRvciBmb3IgaWRlYXMuICAK

Expected results:

• V3JpdGUgY29kZSB0aGF0IGF0dGFja3MgdGhlIFRveCBuZXR3b3JrLiAK
• VHJ5IHRvIGZpbmQgcG90ZW50aWFsIGlzc3VlcyB3aXRoIHRoZSBUb3ggbmV0d29yay4K
• SGVscCBmaXggZGlzY292ZXJlZCBpc3N1ZXMuICAK

Difficulty: SGFyZCAK

Mentor: aXJ1bmdlbnRvbyAK

Project link.

Also, please read the following section before submitting a proposal.

Since every mentor for different projects may have different expectations, this section describes some of the expectations the Tox4j team has regarding applications directed at it. These are mostly guidelines, and not following them is not a death sentence to your proposal. We are open to discussion. If you feel any of these guidelines are unreasonable, please let us know on the mailing list or in a private email to the mentor.

We want to give every proposal a fair amount of thought, so please try and make our life easier; it can only benefit you.

Important:

• If you do not understand the idea, but think that you might be interested, please come and talk to us on IRC (#tox-gsoc-students) or send an email to the mailing list (don't say “can you explain more?”, but ask specific questions about things you want to know).
• We want to see that you put some thought into the project, you have a rough idea of what it entails, and that you understand the project idea written on this page. We have put a lot of thought into the idea, so we would like to see you spend some time thinking about it, as well. We do not want to see something that is essentially a copy of the idea, reworded a little.
• Don't write large amounts of text saying nothing with a lot of words. We're not a university, so we don't grade you based on word count. Be precise and to the point.
• Structure your text with headings in bold. Preferably copy the wording from the GSoC page. This makes it easier for us to compare the proposals. Use bullet lists if appropriate.
• Run a spelling checker. We don't mind if your English is not grammatically perfect, but running it through a spelling checker is the least you can do.

Furthermore:

• We are very interested in relevant skills. These include functional programming, security, mobile systems, and many others. Do list the ones you feel are relevant, but don't go on and on about them. We are more interested in your ideas about the project itself. One or two paragraphs about your background is enough.
• We are not very interested in your ability to cough up buzzwords, so filling your proposal with Enterprise Service Bus, JavaBeans and other corporate transportation or coffee-related words will not help.
• If you can, try to come up with an approximate timeline for your project.

Criteria:

What we are (ideally) looking for in students.

• Technical skills
  • Having adequate technical background to complete the project.
  • Being able to quickly acquire new skills, learn new programming concepts, familiarise oneself with a foreign codebase.
• Communication skills
  • Able to express your ideas and questions clearly and precisely.
  • Comfortable discussing your ideas with other developers.
• Vision
  • Having ideas that go beyond the ones listed on this page.
  • Having ideas that go beyond GSoC.
  • Be realistic in your proposal, but there is room for a “future work” section at the end in which you talk a bit about your vision.
• Ownership
  • You feel that the project is yours, you stand behind it, you own it.
  • Consequently, you won't let it go after GSoC. We hope you love your project as much as we love ours.

Last but not least:

Stay tuned for changes to this wiki page. We regularly add new information here if we feel that it could benefit all students. We want to give everybody equal chances, so we do our best to share information widely.

Brief explanation: Design and implement a high level library (HLAPI) based on tox4j targeting the JVM. The idea here is to create a fat layer of logic between the low level API and the concrete client implementation.

Among its responsibilities are:

• Friend lists: adding/removing friends, associating predefined and arbitrary bits of information with them (e.g. birthday)
• File transfers: state (paused, running, cancelled), meaning (avatar, inline image/sticker/audio message, data transfer, …)
• User profiles: managing user profiles, user-specific settings (global settings like autostart are out of scope)
• Chat logs: storage protocol, full text search, statistical data, …
• Protocol implementation for communication with toxdns services (e.g. toxme.io)
• Custom Tox protocol extensions: e.g. location sharing, recommend friends, …

Examples of what the library will NOT do:

• Actual file system I/O. It will expose an interface that the concrete client can implement to provide functionality such as creating, opening, and deleting files
• Direct user interaction. All communication goes through specific programming interfaces without human-readable information. The task of making human sense of the API is up to the client. (In particular this means internationalisation is done by the client, not by the library, although the language setting can be in the library).
• Audio/video frame gathering from devices. This is done by target-specific APIs (e.g. the Android SDK).

Required:

• It must take care of everything that isn't the interface.
• It must implement all the client logic, and only leave the most low-level implementation details (i.e. storage backend, database backend, audio/video, and other I/O or platform-specifics) to the concrete client implementation.
• It must be easily usable from Java.
• It must use only Java 6 library features (for Android compatibility).
• The design must account for testability.
• A simple GUI or Android client based on the library for demonstration purposes.

Design/implementation guidelines (exceptions will be made for certain components that can't comply, but the majority of the code should follow them):

• Referential transparency for all functions: calling a function with the same argument twice needs to yield the same result, i.e. foo(bar).equals(foo(bar)) must always be true.
• Every function must be total; the use of the Java throw statement or the Scala throw expression is not permitted.
• The use of null is not permitted, except when interfacing with external libraries, which must be properly wrapped as not to expose nullability to the rest of the code.
• If a function is partial (i.e. it cannot return a valid output for every input), it can return an Option, a Try, an Either, or a custom error handling type.
• For every data structure (type), there must be a generator function that creates a random valid instance of that data structure. This will be used in property-based testing.
• Correct by construction: creating a new object must guarantee that its state is consistent and correct. In particular, this disallows a common Java idiom: creating an empty invalid object and making it valid by calling setters. If object creation can fail, the constructor function needs to be partial.
• “No raw ints”: The use of int or other primitive data types is highly discouraged. Prefer to wrap them in a value class with appropriate operations explicitly defined and checked on them (e.g. class FriendNumber)
• “No raw loops”: The use of raw for-loops is highly discouraged. Prefer to use generic library functions.
• “No raw getters”: Getters are often a sign of poor encapsulation. Expose operations rather than data.
• “No string-typing”: Provide concrete types and functions for specific functionality. Prefer specialising to generalising. String-typing includes the use of the Object type, which is highly discouraged.
• Small specific functions: Write small, independent functions that perform a single small task. If a function is larger than a single screen (~50 lines), it's probably doing too much work.

Optional:

• It should be written in Scala.
• It should be incorporated into the main tox4j repository.
• The implementation should be well-tested. Use a combination of property-based testing and unit tests to increase confidence.

Recommended reading:

• http://fsharpforfunandprofit.com/posts/designing-with-types-intro/
• https://pavelfatin.com/design-patterns-in-scala/

Expected results:

• Have a working high level Tox client library for the JVM.
• At least milestone 4 achieved.

Milestones:

1. Design document (possible collaboration with Android client).
2. User information setting/retrieval.
3. Buddy list and message sending.
4. Storage and database backends.
5. File transfers.
6. Simple Android or desktop GUI app.

Knowledge Prerequisite: Scala, Java (these are both easy to learn if you know other languages)

Difficulty: Medium

Mentor: iphy

Brief explanation: Design and implement an Android client based on the above-listed high level API. This project is largely independent of the high level API project, but requires the two students to closely collaborate on the API design.

Since the “working” part of this project depends on the implementation of the HLAPI, this is not a strict requirement for the student to pass. However, the UI must function correctly, and must perform the right calls into the HLAPI. This project will not implement any of the things mentioned above in the HLAPI idea.

Required:

• It must use the High Level Client Library.

Optional:

• It should be written in Scala using Scaloid.
• It should be tested using a UI testing framework.

Recommended reading:

• http://www.usabilityfirst.com/usability-methods
• Search for any of the words on the above website using your favourite search engine.

Expected results:

• Have a working Android client for Tox.

Milestones:

1. Design document (collaboration with HLAPI).
2. UI mockup (any format permitted: can be PDF, HTML+CSS+JS, actual Android code, etc.).
3. UI implementation (on Android).
4. Data store and other platform specific APIs adapted for consumption by HLAPI.
5. Buddy list, messaging, etc. working.
6. Audio/video working.

Knowledge Prerequisite: Scala, Java

Difficulty: Medium

Mentor: iphy

Brief explanation: Create a full implementation of the ToxCore interface without networking.

Currently, our tests rely on the toxcore C library to establish a network connection between two instances by performing LAN discovery. This is a fragile process that can take anywhere between 4 and 10 seconds. After that, friend connections need to be established, which takes another 4-10 seconds. Even with a generous timeout of 60 seconds, some of our tests occasionally time out, because toxcore got confused or due to random network issues.

The tests currently take anywhere between 20 and 40 minutes, if they are ran in parallel (this sometimes confuses toxcore, causing it to never establish a connection, thus exceeding the 60 second timeout). Running them sequentially takes over 1 hour.

The purpose of this project is

• Get an executable specification of the ToxCore API definition.
• To achieve reproducible test results in the HLAPI (see above) tests.
• To speed up our tests by eliminating network setup time.

Requirements:

• May use any JVM language.
• Must behave like a real Tox instance in an ideal network situation.
• Must support creating multiple instances that can communicate with each other.
• Optional: simulate different network situations.
• Optional: ToxAv mock in addition to the core mock.

Design restrictions:

• The behavioural model must be separate from the execution model.
• The behaviour must be modelled as directed (cyclic) graph.
• The program state must support checkpointing and detailed transition tracking.

Expected results:

• All tests that succeed with the real implementation also succeed with the mock.
• All tests that currently time out no longer time out.
• For the student to pass, milestone 3 must be achieved. Milestones after 3 are optional.

Milestones:

1. Single-client non-network tests work.
2. Bootstrap tests work.
3. Messaging tests work.
4. File transfer tests work.
5. ToxAv mock: audio/video tests work.

Knowledge Prerequisite: Java

Difficulty: Medium

Mentor: iphy

Project link.

Brief Explanation: Tox is meant to be user friendly to the average and less-than-average computer literate user. qTox needs a lot of touch ups, bug fixes, UI improvements, and feature parity with both Skype and uTox. This summer-long project will entail multiple sub projects of varying difficulties and required skills, such as:

• Overhauling the audio input and output code; potentially using some uTox code. Experience with OpenAL is preferred.
• Overhauling the video input and output code, and friendly interaction with web cams. Perhaps some uTox code can be used. Experience with OpenCV preferred.
• Chatform improvements: currently the layout and spacing of the chat form isn't adjustable; additionally, many improvements can be made, such as displaying images inline and implementing stickers. Some code from Quassel may be used. Experience with Qt is preferred.
• Screenshot button: Implement a screenshot button that allows users to image a select portion of their screen without resorting to using external photo editors. This will require the use of the Windows, Mac OS X, X11, and possibly Wayland and/or Mir APIs.
• Desktop and operating system integration. All the OSs that qTox support have their own APIs for doing neat things that users expect, such as desktop notifications, and we need to implement support for those things.
• General bug fixes. There's a lot of minor bugs piled up which may take significant time to track down and fix. This is somewhat lower priority than the above projects.

Knowledge Prerequisite: Experience with C++ and Qt is a prerequisite for all the above tasks. qTox supports GNU-Linux, Mac OS X and Windows equally, so writing cross platform code is also a must. These requirements are in addition to the preferred (but not necessarily requisite) experience above.

Difficulty: Medium

Mentor: bunslow (aka Dubslow) bunslow@tox.im, tux3

Although that may seem like a lot for one student over the course of a summer, some progress is expected to be made between now and summer. Additionally, together with the following qTox project, there may well be two students working on qTox simultaneously.

Proposals: The ideas above are only a starting point for your proposal; after you review qTox and its code, you will likely have other things you think need to be fixed as well. Your proposal should specify what you intend to fix, drawing from both the ideas above and your own experience and opinions. In addition to the questions listed here, I'd like you to answer the following questions:

• Are you familiar with Qt and C++? If so, please mention and link past work.
• Do you have experience with either or both of OpenAL/OpenCV? Working with them will likely be a part of the project.
• If you don't have experience, are you capable of learning large, new APIs quickly and effectively?
• Have you worked on a team before, either in the libre/open source world, or in an office/academic environment? No pull request is perfect, so acting on feedback from others is important.

Brief Explanation: A student will enable users to stream their webcams, an area of their screen, or any media file, composited and arranged as the user wishes. Tox is a pipe that media flows through and we will allow the user to take advantage of this and come up with uses we could never dream of, rather than restricting users to a few predetermined use-cases.

Expected Results:

• qTox allows selecting arbitrary combinations of media files, webcams, and desktop, as video sources to composite and stream into one-to-one- and group- calls
• qTox provides a graphical interface to arrange the feeds spatially
• qTox provides an in-call interface for managing the playback of media files selected as sources

Note that there is at least one open source/libre software project that provides similar features, namely OBS MultiPlatform. It may well be possible to borrow code from or collaborate with that project.

Knowledge Prerequisite: Qt, multimedia framework

Difficulty: Hard

Mentor: TBA

Brief Explanation: While qTox works well on OS X, it lacks a lot of features like toolbar support, badges support, etc. These features and many other features that would make qTox even more enjoyable on OS X are all well documented and supported by Qt via the QtMacExtras package and other OS X APIs like CoreFoundation. While a student would be required to own a Mac, getting started with Qt Creator and working on qTox has a fairly low learning curve as many of the complexities of C++ are abstracted and made easier by Qt libraries itself.

Expected Results:

• qTox supports standard OS X badges
• qTox supports NSStatusbar
• qTox supports other native OS X features as the student and mentor see fit

Knowledge Prerequisite: Qt, C++, OS X

Difficulty: Easy

Mentor: Sean sean@tox.im

Project link.

Brief explanation: The original author of uTox ported uTox to Android as an experiment, however that port is far from complete. The code for this experimental Android port lies dormant in the uTox codebase waiting for someone to use it to turn uTox into an Android application that is actually usable. The difficulty of this lies in the fact that uTox is a C program and most of the Android APIs are Java.

Expected results:

• Port all the unported uTox functionality to Android.
• Improve usability on Android.

References: Android specific code Latest apk

Knowledge Prerequisite: C, Java, Android.

Difficulty: Nightmare

Mentor: irungentoo

Brief explanation: Your job will be to improve support and usability on Windows. There are a lot of improvements to do to make uTox integrate well in Windows. Some examples are adding features such as start on boot and doing that fancy file transfer thing with the taskbar when transferring files (copy a file somewhere on Windows 7+ and look at the taskbar, that's what I mean).

Expected results:

• Improve usability on Windows.
• Make uTox a better client.

Knowledge Prerequisite: C, Windows API

Difficulty: Medium

Mentor: irungentoo

Project link.

Brief explanation: A lot of the initial design of toxme was rushed and not as complete as we like. Because of this, stuff like overaggressive caching makes it hard to distribute and searching lacks features like lookups by location and email. Your task would be to fix this from the ground up, replacing sqlalchemy with a proper replicating database, adding entries like location and email, and implementing searching.

Tips: Being Python, it's fairly easy to underestimate how much work is actually required.

Expected results:

• Switch toxme to a new replicating DB
• Find a way to transfer data between the existing sqlite db and it
• Safely add support for location/email/etc
• Work out a way to validate and correct user supplied info (email, checking and fixing locations, etc)
• Design a UI and a backend to search through this data based on user privacy settings
• If time permits work out a Tox bot to do authentication/ownership of an ID to allow resets if one forgets his/her password

Difficulty: Medium

Mentor: Sean sean@tox.im

Project link.

Brief explanation: Your task would be to work with its maintainer to implement audio and video chats with our desktop clients.

Expected results:

• Add toxav support to the Objective C bindings
• Implement 1 on 1 audio calling
• Implement 1 on 1 video chats
• implement ringtones and audio notifications for calls
• Optional: Implement group audio chats

Difficulty: Medium

Mentor: Dvor d@dvor.me

Project link.

Brief explanation: With this idea the student would implement full video chats from both an external window or rendered on the terminal. Please be aware that this isn't particularly difficult, but it will require a lot of trial and error figuring out how best to render a video frame on a command line.

Expected results:

• Make Toxic work with the video portion of libtoxav
• Access the webcam in a platform agnostic way
• Display an X window to show the streamed video of the other recipient if requested
• Work our how to best take a video frame and display it on a terminal.
• Integrate this in to the Toxic UI

Difficulty: Easy

Mentor: mannol mannol@tox.im

Brief explanation: Although there are good libraries for crossplatform audio capture, it looks like there is no single library that provides good crossplatform video capture, not even mentioning desktop capture, so all Tox clients have to implement their own ways of doing these things. (For video capturing, libraries such as GStreamer, OpenCV and QtMultimedia were considered, but all of them fail short in some aspect). By writing a library that would do audio, video and desktop capture, it would ease the burden of developing the same thing over and over in clients, as well as push client developers to improve the library if they find something missing in the library, making this feature available to everyone using the library.

Expected results: Although the goal of this library is to implement native audio/video/desktop capture for Windows/OS X/Linux, it's a too big task for GSoC, so we have prioritized some specific platforms and features.

• Implement video and audio capture for Windows and OS X

References: A work in progress specification of what the library should be able to do and what back-ends we'd like it to use.

Knowledge Prerequisite: C/C++, Obj-C. It's required to have at least two webcams, Windows 7 or newer and OS X 10.7 or newer. Knowledge of library development and familiarity with Windows API and OS X API are not required, but welcome.

Difficulty: Hard

Mentor: nurupo, tux3, irungentoo

Brief explanation: Write a multiplayer game or add multiplayer support to an existing open source one using Toxcore for the networking. This video game should also have a competitive mode that can be used by devs to settle their differences. If you choose this idea, we ask that you come speak to us via IRC before submitting your proposal.

Expected results:

• Multiplayer game that shows off how good toxcore is at dealing with networking.
• Video game should have at least one mode where players can compete against each other.

Difficulty: Medium

Mentor: irungentoo

Brief explanation: Write a Tox client in preferably C# using SharpTox that follows all Modern UI best practices and conforms to the modern feel and styling of Windows 8+ applications. Please make sure this is a real native application that would support modern UI features like proper snapping, OSK support, ETC. You're also expected to make use of as many features from the core library as possible. Not only standard features like one to one conversations are expected to be implemented, but also audio/video and groupchats.

Expected results:

• A proper modern UI client

Knowledge Prerequisite:

• Familiarity with C# and the .NET framework in general.
• Experience with WPF or Windows.UI.Xaml (not required, but welcome).

Difficulty: Depends

Mentor: Impyy impyy@tox.im

Brief explanation: If you own a device that Tox isn't usable on yet and you want to make a native client for it or if you think all our clients suck, this idea is for you. If you choose this idea, we ask that you come speak to us via IRC before submitting your proposal.

Expected results:

• Working Native Tox Client

Difficulty: Depends

Mentor: irungentoo