Table of Contents

Administrators and Mentors

We will list the potential mentors in this place. For now, if you have any questions, please contact the GSoC administrators:

George Zaronikas (gzaronikas) and Ali Ok (@aliok_tr) .

Communication channels

Gitter    : JBossOutreach/GSoC - Gitter 

Please take note - These channels are about generic doubts. For project-specific doubts you will need to contact project mentors and channels specified in the project description.

Notes for contributors

Points to consider while choosing any project

1. You meet at least 50 percent of the requirements. The remaining skills can be honed on the go, so don't worry if you lack some.

2. You can relate to the project idea and you have used something related to the project as a user.

3. You are willing more toward learning the skills and less toward boasting about the skills you have already.

Suggested steps after choosing a favorite project

1. Start to use product/tool/API as a user or hello world client application.

2. Setup the development environment for the project and start to use your own build.

3. Look for newcomer bugs and try to get your head around them.

4. Let us know if you feel stuck at any stage.

Idea template (for mentors)

Project title

Summary of idea:

-Idea

-Feature A

-Feature B

Knowledge prerequisite: Languages/Technologies goes here

Github repo:

Skill level: Beginner/Intermediate/Advanced

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Associated JBoss community project(s):

Idea Proposals

Drogue IoT – CoAP TLS support

Summary of idea:

During last year's Google Summer of Code project, we got a CoAP protocol adapter contributed to the cloud side of the project. However, transport encryption was out-of-scope for the project back then, as that would be been too much for the summer. Building on last year's contribution, this year the protocol adapter could be extended to support CoAP transport encryption using DTLS.

• Learn how CoAP and DTLS are supposed to work
• Find a suitable DTLS implementation
• Extend the existing CoAP protocol adapter in the cloud with support for DTLS

We understand that the combination of Rust, DTLS, and CoAP isn't a mainstream topic. So it is ok for us to learn some of the technologies, during GSoC. However, you should have some basic understanding of what is required, and have a plan upfront. This is not a beginner project.

Knowledge prerequisite: CoAP, Rust, TLS, Kubernetes (not all, but some)

Github repo: https://github.com/drogue-iot/drogue-cloud/tree/main/coap-endpoint

Skill level: Intermediate

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann <jreimann@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Knative event source

Summary of idea:

Knative is a serverless framework for Kubernetes. Drogue IoT Cloud is providing IoT friendly APIs on the cloud side. As Drogue Cloud uses CloudEvents, both technologies can work together quite nicely.

However, in order to consume events from Drogue Cloud using Knative, one needs to use the Kafka Event Source. We would like to be able to offer a dedicated "Drogue IoT event source", which connects using OAuth2 or API tokens, and get only configured using the Drogue Cloud specific connection parameters. Also, sending back commands using a Drogue Cloud Sink should be possible. This can use the MQTT integration API of Drogue Cloud, in order to consume messages. And the command endpoint, to submit commands back to devices.

The goals of the project are:

• Create a Drogue Cloud sink and source
  • Backed by the MQTT integration API and the HTTP command API
  • Authenticating using OAuth2 and API tokens
• Documentation
• Example deployment using Helm
• Tests

Knowledge per-requisite: Go

Skill level: Intermediate

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Dejan Bosanac <dbosanac@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Quotas

Summary of idea:

Drogue IoT Cloud allows users to create device and send messages. However, that should be limited, according to a set of rules an administrator can configure. This should limit things like: Number of devices created, number of messages sent per second, number of bytes sent per second.

The goal of this project is:

• To come up with an RFC (mini specification) defining what quotas should exists and how they could be enforced
  • This should leave room for future extensions
  • Not all specified quotas need to be implemented during GSoC
• Implement
  • The configuration model
  • Enforcing of at least
    • Number of devices that can be created
    • One rate limiting quota: like number of messages sent in the last 4 hours
• Adapting existent Helm deployment scripts
• Document
• System tests ensuring the enforcement work

Outside of the scope is:

• Implementing new metrics: We already record some metrics. If more are needed, we need to decide this during the RFC phase, and we will implement that for you.

Knowledge per-requisite: Rust, Prometheus

Skill level: Intermediate

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann <jreimann@redhat.com>

Associated JBoss community project(s): Drogue IoT

Drogue IoT – Web Flasher

Summary of idea:

Part of Drogue IoT is a firmware for microcontrollers, written in Rust. The other part is a cloud side solution. Bring that in combination with a Web IDE, you might soon find yourself in a position that you want to flash a microcontroller over USB from your web browser. As a browser API for accessing USB devices attached to the user's machine exists, this should be possible in general.

The goal of this project is to bring together a hand full of projects and technologies, and create an frontend application, for the browser, to flash embedded devices. This needs to be done using Rust, and WebAssembly, so that existing code from https://probe.rs/, which can talk to devices, can be re-used.

• Make it possible to use probe-rs on a WebAssembly target
  • Allow using an additional USB implementation (vs the current libusb based one)
  • Implement an additional one using WebUSB APIs
• Create a frontend (single page) web application using Rust and WebAssembly
  
  • Allowing to select a firmware from the local machine
  • Flashing this to the device
  • Allow selecting a firmware from a remote endpoint (HTTP GET) too

Knowledge per-requisite: Rust, WebAssembly

Skill level: Advanced

Project chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann <jreimann@redhat.com>

Associated JBoss community project(s): Drogue IoT

EAT  - Testing Infinite Software Project Versions

Summary of idea:

The innovative part of EAT is creating the test once and testing with any version of the tested software. It may be firstly applied for the JBoss Servers, but, in general, a similar structure, can be used for creating tests about any software with multiple versions or for multiple software programs that have a part of the testsuite in common. EAT is a project under the ΙΔΕΑ statement.

Possible tasks for this project :

Go through the EAT workshop, extending the existing AT testsuites, creating a new testsuite using the AT Structures, apply to android new projects, etc (the students should make their proposals)

Github repo: https://github.com/EAT-JBCOMMUNITY/EAT

Contact / potential mentors: Panagiotis Sotiropoulos (psotirop@redhat.com)

Associated JBoss community project: EAT