GSoC 2016 Ideas

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

This project is collection of all Tox Project infrastructure.

Brief explanation: Improve the project website at https://tox.chat to include more information, to become more maintainable, and to keep an efficient and friendly design.

• Prefer static content generation.
• All dynamic information provided in HTML should have machine-readable (e.g. JSON) alternatives.
• Build and test the website (render-tests) on a continuous integration platform (e.g. Travis CI).
• Ensure that the website is fully accessible without JavaScript. Use of JavaScript to improve the user experience is permitted, but not at the cost of NoScript users.

Expected results:

• The website should become a useful information source for average users, power users, and developers, without confusing the first group or annoying the last group.
• Automatic browser tests should avoid render bugs.
• Integrate various information sources, e.g. https://nodes.tox.chat.
• Implement and integrate additional information sources.
  • DHT map with geolocation to show approximate Tox user locations.
  • Traffic statistics from bootstrap nodes.
  • Any other ideas you may come up with.

Knowledge Prerequisite: HTML, CSS, any server-side web framework

Difficulty: Easy

Mentor: zero-one

Toxcore, Repository, Protocol Docs

Brief explanation: Design and implement a testing interface for Tox Protocol implementations.

The testing interface will be specific to each component of Tox Core but independent of the language used. In the simplest case (recommended), this means that the language boundary is at the process level. The test runner will invoke interface functions in the process running the implementation. The implementation will process the test input and produce an output that is then validated against a model or a reference implementation.

All Tox Core implementations will need to implement the interface.

Expected results:

• Design document and interface specification.
• A complete set of functional tests for every component of Tox Core as specified in its specification.
• Optionally, but highly recommended as a means for self-validation: implementation of the provider-side in libtoxcore.
• Optionally: a testing interface for multiple nodes with different (or the same) implementations to run in a simulated environment.

Knowledge Prerequisite: $language

Difficulty: Medium

Mentor: irungentoo for the libtoxcore side + see language/mentor table below.

Brief explanation: Using only the Tox Protocol Specification, write a complete implementation in a memory-safe language.

Language choices are currently:

Safe-D is D where all public entry points are @safe and no internal functions are @trusted. Bold languages are ones that have a beginning of an implementation.

Expected results:

• At least all DHT (including Onion Routing) behaviour.
• For all components, tests must be written. Ideally using property based tests in combination with example based tests.
• For all larger components, an external interface common to all implementations of that component. This will be used for the common test infrastructure to validate each implementation.
• Improvements of the documentation.

Knowledge Prerequisite: $language, Networking, Security

Difficulty: Medium

Mentor: See table above.

Brief explanation: Based on Jfreegman's work on DHT-powered group chats, this project will implement group audio/video chats.

Expected results: Audio/video group chats implemented in one client implementation (e.g. qTox, uTox, Antox).

Knowledge Prerequisite: C, Networking

Difficulty: Medium

Mentor: mannol

Brief explanation: This project will add multi-device support to toxcore. You can start with the project proposal here or propose your own implementation.

Expected results: By the end of the summer, Toxcore will need to be able to: 1) group devices together, 2) send messages to multiple devices, and 3) the groups must be able to keep histories and contact lists in sync. Additionally at least one of client will need to implement basic multi-device support. (uTox STRONGLY suggested, other clients may require the student to find a mentor better acquainted with that client.)

References: https://docs.google.com/document/d/1op6zGR0KYdF7tTWSSX79KQieJu30vLZ6XG327kIBhxQ/edit

Knowledge Prerequisite: C, some knowledge of networking, data syncing, security/crypto.

Difficulty: Medium to Hard

Mentor: grayhatter

Brief explanation: Improve data and battery usage for mobile Tox clients.

Toxcore currently uses a large amount of network traffic to keep the DHT connections alive. For mobile applications, this is not acceptable, and for “Doze” on Android or vanilla iOS it's entirely infeasible, because background processing is very limited. This project involves using GCM or equivalents to wake up the mobile Tox client and build connections. To make it usable, some changes to libtoxcore are required to speed up building DHT connections. Endpoint hints can be encoded in GCM data packets. Further investigation could be done in making TCP relays or a similar concept use less traffic.

Expected results: Antox uses no traffic and battery while idle and uses traffic proportional to the message volume when active.

Knowledge Prerequisite: C, Scala

Difficulty: Medium

Mentor: irungentoo for libtoxcore, iphy for Antox

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 (iphy, sonOfRa, subliun) on IRC (#tox-dev) 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 code base.
• 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. 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.

Come talk to us early. As part of the vetting procedure, we will require you to either improve our code in a specific place or write a small sample application using our APIs. This shows whether you are capable of quickly getting around new code, which is important in the type of work we expect.

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: Merge the two Android clients Antox and TokTok. The TokTok was designed with separation of UI and logic in mind, while in Antox, it is still largely a mix of Android and pure JVM code. We would like to focus on a single Android client, so the goal here is to either change Antox to use design ideas from TokTok, or reuse Antox code in TokTok to reach feature parity, so we can drop support for one of the clients.

Expected results:

Required:

• Strict separation of presentation and business logic.
• A set of use cases the client must support.
• Behaviour based unit tests for the business logic and instrumentation tests for every use case from the above set.
• Written in Scala, as both Antox and TokTok are currently in Scala.

Optional:

• Separation from the low level ToxCore.
• Support one alternative protocol, e.g. IRC or XMPP, as the backend.

Recommended reading:

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

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

Difficulty: Medium

Mentor: iphy

Brief explanation: Create a full implementation of the Tox core protocol running on the JVM.

Alternatively: use a different safe language not targetting the JVM, such as OCaml, Haskell, Rust, Coq, to implement the protocol. In this case, Scala and Java knowledge is not required.

There is a beginning of an implementation in progress, but so far only a small part of the DHT specification was implemented. This specification has also since changed.

This project is large and can be split among multiple students. Depending on the number of applicants and their skills, a sensible split could be:

• DHT and Onion Routing
• Network backends: TCP and lossless UDP, including congestion control
• Friend connections: the crypto handshake and basic packets
• Messenger functionality: higher level protocols such as file transfers

No design document is required for this project, as all the information should be in the protocol specification. If any information is missing, it must be added to that specification after discussing with irungentoo.

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 \/, 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 (or scala.Any) 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.

Expected results:

• Fully tested Tox protocol implementation compatible with the reference implementation in libtoxcore.
• A ToxCore interface implementation using the above work as backend.

Knowledge Prerequisite: Scala, Java

Difficulty: Medium

Mentor: iphy

Brief explanation: Create a formal specification and JVM implementation of a higher level protocol on top of Tox network packets.

The idea here is to build an abstraction on top of (limited size) Tox packet protocol for applications such as:

• Arbitrary length text messages.
• Streaming protocols (e.g. file transfers (lossless) and audio/video (lossy)).
• Games (e.g. Tic-tac-toe).
• Remote UI elements.
• Distributed file systems.

The protocol should be specified in a machine-readable format that can easily be used to generate parsers and generators for various languages, so that it can be implemented in every client. A reasonable backwards-compatibility policy is part of the design to be created by the student. Existing RPC technology can and should be leveraged if possible.

Design/implementation guidelines from the above project apply.

Expected results:

• Design document and protocol specification.
• Fully tested implementation in a language targetting Java byte code.

Knowledge Prerequisite: Any JVM language (preferably Scala), Networking

Difficulty: Medium

Mentor: iphy

Brief explanation: Create a network protocol, possibly based on the above abstraction, for multi-device support.

One idea here could be to use distributed consensus with eventual consistency to synchronise information between Tox clients. The same mechanism can be used for messaging (sending a message equals synchronising logs) and profile information synchronisation.

This idea requires a formal protocol specification and a design document.

Design/implementation guidelines from the above project apply.

Expected results:

• Design document and protocol specification.
• Fully tested implementation in a language targetting Java byte code.

Knowledge Prerequisite: Any JVM language (preferably Scala), Distributed systems

Difficulty: Hard

Mentor: iphy

Project link

Brief explanation: Create a Tox client for OS X using objcTox wrapper.

Expected results:

Using existing Objective C wrapper for toxcore, create a fully functional client for OS X. Client should be written in Swift and should have following features:

Required:

• 1-to-1 messages
• audio calls
• video calls
• file transfer

Optional:

• group chats

Knowledge Prerequisite: Swift, Objective C

Difficulty: Medium

Mentor: dvor, chuongv (backup mentor)