Progetti della Google Summer of Code di GNUnet

In qualità di progetto GNU, GNUnet ha partecipato per molti anni al Google Summer of Code (GSoC). In questa pagina sono elencati tutti i progetti attuali, passati e conclusi. Chi volesse partecipare e candidarsi per una delle idee per il 2020 elencate di seguito o per un qualsiasi progetto passato che non è stato ancora concluso (oppure con un'idea propria), può contattarci nel canale IRC o scrivendo alla mailing list.

Transport Next Generation (TNG): Communicator plugins

Il team GNUnet sta attualmente lavorando sulla riscrittura di un livello di trasporto per sistemare problemi con la connettività. Questo nuovo componente è attualmente in sviluppo con il nome "TNG". Ciò che attualmente è conosciuto come "transport plugins" sarà rappresentato dai "communicators" nel TNG. I communicators sono processi con una API definita che permette di connettere i peers con un protocollo specifico. Il protocolli primari che sono già implementati sono sockets UNIX, sockets UDP e sockets TCP. Per una rete resiliente reale, altre opzioni di connettività come WiFi mesh, Bluetooth, HTTP(S), QUIC o altre alternative oscure come radio sono richieste. In questo progetto, l'obiettivo è di selezionare, implementaree testare nuovi communicators. Finchè TNG non è ancora pronto, i communicators possono, in base alla progettazione, essere sviluppati e testati con l'API attuale. Ci aspettiamo che al progetto lavorino molti studenti in quanto ci sono tanti protocolli da scegliere. Gli obiettivi consistono in:

1. Decidere quali communicators implementare.
2. Testare i communicators.
3. Documentazione.

1. C
2. Conoscenza di HTTPS, QUIC, Bluetooth o 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