GNUnet's Google Summer of Code projects

As a GNU project, GNUnet has participated in the Google Summer of Code (GSoC) for a number of years. This page lists all current, past, and finished projects. If you want to participate and apply for any of the ideas for 2020 below or any past project which is not yet finished (or even your own idea), please contact us on the mailing list.

Transport Next Generation (TNG): Communicator plugins

The GNUnet team is currently working on a transport layer rewrite in order to fix core issues with connectivity. This new component is currently developed under the name "TNG". What is currently known as "transport plugins" will in the TNG be represented as "communicators". Communicators are processes with a well defined API that allow to connect peers over a specific protocol. The primary protocol which are already implemented are UNIX sockets, UDP sockets, and TCP sockets. For a truly resilient network, other connectivity options such as WiFi mesh, Bluetooth, HTTP(S), QUIC or even more obscure alternatives such as radio are required. In this project, the goal is to select, implement and test new communicators. While TNG is not yet ready, communicators can, by design, be developed and tested against the current API. We expect that this project can be worked on by multiple students as there are a lot of protocols to choose from. A QUIC communicator has been written as part of GSoC 2023. The tasks would consist of:

1. Deciding which communicators to implement.
2. Test the communicators.
3. Documentation.

1. At least one new communicator.
2. Documentation of communicator protocol and how to use.

1. C
2. Knowledge of HTTPS, Bluetooth or WiFi.

Single-process peer

For special platforms such as Android, GNUnet must be usable as a single-peer shared library. Since GNUnet's design fundamentally revolves around a multi-process model that communicate via IPCs, this requires a major change in how GNUnet processes are instantiated. A lot of progress in this direction has already been made but some issues still remain. The project tasks are to:

1. Get familiar with the GNUnet scheduler and envisioned single-process architecture.
2. Implement the single-process scheduler and main loop.
3. Demonstrate the functioning of this change (e.g. in a simple Android App)

1. A new single-process shared library to link against.
2. Documentation on when and how to build the single-process library.
3. A demo application.

1. C
2. Socket programming
3. Scheduler and IO

Pluggable REST service components

In the process of supporting a single-process GNUnet peer, the subsystem REST plugins have been consolidated into a single, large REST server that depends on all subsystems. In this work, the student should define and implement a new architure that runs each subsystem's REST interface in its own service, thus making the REST service more resilient and easier to extend. The planned projects tasks are to:

1. Get familiar with the existing REST service.
2. Plan a multi-processes architecture for REST services.
3. Test and document the use of the new architecture / REST service layer.

1. A new multi-process REST service architecture.
2. The current REST service is modified or replaced with a multi-process service per subsystem.
3. Architecture and usage documentation.

1. C
2. Socket programming

gnunet-gtk gtk4 upgrade

Our GTK interface for GNUnet is written using libglade and Gtk. It is currently designed and compatible with Gtk+3 with already possibly including a variety of deprecated functions. In this project the requirements for a Gtk4 migration shall be worked out and the codebase migrated to the most recent stable Gtk4 release. The difficulty of this project largely depends on the students proficiency with build tools and Gtk. There non-exhaustive task list would be:

1. Get familiar with the existing gnunet-gtk architecture.
2. Get familiar with Gtk4 and work out a migration path.
3. Migrate gnunet-gtk to gtk4.
4. (Optional) Ad-hoc UI improvements where applicable

1. C
2. Gtk
3. User interfaces

Integration of GNU Anastasis into the GNU Taler wallet

The goal of this project is to enable users to store their GNU Taler wallet backup encryption keys in the GNU Anastasis distributed key backup and recovery system, and to use GNU Taler to pay GNU Anastasis service providers for key storage and recovery. The project will focus on implementing the GNU Anastasis user interface on Android inspired by the existing Gtk+ and WebUI and integrating the result with the rest of the GNU Taler Android App.

Mentors: Christian Grothoff (GNU Anastasis) and Florian Dold (GNU Taler)

Required Skills: Android UI development

Duration: 350h

Difficulty level: medium

Migrate gnunet-qr from Python 2.7 to C using libzbar

Python 2.7 is reaching its end-of-life, and we want to get rid of the dependency on Python. The existing gnunet-qr tool is a rather simple wrapper around python-zbar, which itself wraps libzbar. The goal of this project is to directly use libzbar to scan QR codes for GNUnet / the GNU Name System (see also #5562).

Mentors: Christian Grothoff

Required Skills:

Difficulty level:

Report:

Unfinished/Abandoned as gnunet-qr was moved to C outside of GSoC.

GNUnet Web-based User Interface

Implementation of a Web-based UI for GNUnet similar to GNUnet-Gtk with a yet to be determined framework such as Angular2. This includes the design and implementation of not yet existing REST APIs that expose the GNUnet API.

Mentors: Martin Schanzenbach

Required Skills: C, JavaScript, CSS

Difficulty level: medium

Report: GSoC 2018: GNUnet WebUI