Explore Projects

This project aims to develop a user-friendly interface for configuring and managing popular VPN protocols like WireGuard and OpenVPN on Linux servers within the Cockpit web interface. By simplifying the process of setting up and managing VPNs on Linux servers, this project will enable users to easily and securely connect to their servers. I will collaborate with the Cockpit community to develop the necessary backend functionality and user interface features for the project.

<p>The Haskell IDE Engine is a Haskell backend for IDEs, which utilises the Language Server Protocol to communicate between clients and servers.</p> <p>This projects aims to create a test framework that can describe a scenario between an LSP client and server from start to finish, so that functional tests may be written for the IDE engine. If time permits, this may be expanded to be language agnostic or provide a set of compliance tests against the LSP specification.</p>

<p>This project is based on the idea of the simplest form of micro-frontends that we can provide our users with our services like Cloud Registry, TRS, DRS, etc. As TRS/DRS backend services are still in development for GSoC this project is mainly focused on implementing open source clients for the Cloud Registry specifications as Web Components these Components can also be used later for Tool Registry Service (TRS) and Data Repository Service (DRS) specifications by adding the more functionality to these components. This will provide the Microservice~Micro-Frontend architecture to the organization.</p>

This project proposes various new features for the haskell language server(HLS). While HLS already comes with the most important ones, a few haven’t been implemented yet. These important unimplemented features of Language Server Protocol(LSP) have to be implemented. Namely, Semantic Highlighting, Folding ranges, Linked editing, Change Annotation, Document links, and Completion / Code Action / Code Lens resolving.

<p>The main aim of this project was to develop an iOS app on top of the SUSI.AI Server functionalities. The server makes use of different skills which are defined in the Skill Data Repository. The app will have functionalities such as replying intelligently to user's queries, helping users in their day to day lives, hot word detection, and training, synchronizing settings across all the clients and much more.</p>

The Debezium Management Platform currently deploys pipelines only to Kubernetes. This project adds host-based deployment support, enabling users to deploy Debezium Server pipelines to bare-metal servers and cloud VMs via SSH and Docker. The implementation integrates into the platform's existing event-driven architecture by adding a new EnvironmentController for host targets, an SSH-based provisioning service that validates and prepares remote hosts, a lightweight agent deployed on each host for managing the Debezium Server lifecycle via REST APIs, and a status polling mechanism for monitoring deployments. Key deliverables include the host registration API, automated provisioning with remediation, the Debezium Host Agent, Docker-based deployment engine, config drift detection, and comprehensive integration tests using Testcontainers.

LitmusChaos is an open-source chaos engineering platform for Kubernetes, enabling users to test and improve the resilience of their cloud-native applications. The task is add unit tests for Chaoscenter Web and test cases for the Authentication Server. The GraphQL API documentation will be updated with the latest APIs, while the GraphQL server's APIs and handler functions will be optimized to reduce code duplicacy. Additionally, comprehensive documentation and video tutorials will be created for local development setup, promoting easier onboarding and collaboration. - Expected outcome: The expected outcome of this issue is an improved Chaoscenter Web and Authentication Server with added unit tests, updated GraphQL API documentation, and optimized APIs and handler functions. The enhancements will result in a more reliable, efficient, and user-friendly chaos engineering platform, promoting better collaboration within the community.

<p>BioJS is a library of over two hundred JavaScript components which enables users to visualise and process data. BioJS currently has two websites:</p> <ol> <li>Biojs.io: it lists all the components (npm packages) of BioJS with detailed information and visualisation(s).</li> <li>Biojs.net: it is an informational website for the BioJS organisation.</li> </ol> <p>BioJS.io gets the data of all the components through a middleware called workman. The development of a new workman has already been initiated which needs to be completed for integration with the frontend. I propose to create a new frontend website for BioJS and to integrate it with the backend/middleware to get the data in the most optimized way. The website will be developed using VueJS which makes it easy to maintain and the website will merge the currently existing websites and produce a consistent and modern UI and a better UX.</p>

LibreHealth Toolkit has no visual way for non-developers to build healthcare forms without writing code. I will build a drag-and-drop form designer using vanilla Web Components and Lit, consisting of a form-designer-canvas, component-palette, properties-panel, and FhirDataBinder. The designer will let users visually assemble FHIR- bound healthcare forms, export/import JSON schemas, and preview forms in real time , all without requiring the end user to write a single line of code.

This project aims to improve the handling of transposed diffuse irradiance and optical loss modeling in the pvlib-python package. Currently, pvlib’s transposition models provide inconsistent output, with some providing only total sky diffuse radiation (e.g. isotropic), while others allow for outputting the isotropic, circumsolar, and horizon components. Due to this, the ModelChain workflow only allows users to define a single angle of incidence (AOI) model, and then applies the resulting incident angle modifier (IAM) to total irradiance, limiting physical accuracy. The proposed GSoC project will start by standardizing the outputs of diffuse transposition models already implemented in pvlib, introducing a consistent interface to return circumsolar, isotropic, and horizon components. Building on this, the project will extend ModelChain to support component-specific IAM calculations, enabling more accurate modeling of optical losses by distinguishing between direct and diffuse contributions. These enhancements will improve both the flexibility and accuracy of pvlib simulations while maintaining full backward compatibility. The project will include comprehensive testing and documentation to ensure reliability and ease of use.

This project introduces an AI-powered agent that automates the transformation of API responses into structured UI schemas and functional UI components across various frontend frameworks. Using Multiple LLM-Based Agents, the system eliminates the need for manual UI creation by intelligently analysing API responses and generating corresponding UI structures. Additionally, it enables dynamic modification of UI components based on user prompts, allowing for customisation in design, layout, and behavior. By seamlessly integrating these capabilities into a unified workflow, the project streamlines frontend development, reducing manual effort and accelerating the UI generation process with a single-click solution. The project also aims to create a simple one-click API Request to Tool Generation pipeline that can enable external AI agents to interact with APIs without any manual coding Deliverables: • A Modular AI Agent Creation & calling mechanism for apidash's future AI-based tasks • One-Click solution to generate UI components from an API Response • One-Click solution to automatically generate API Tools to be used in various Agentic Frameworks like Langchain, Autogen and so on.

Users who want to understand how the AFS cache manager resolves each element of a path (plain directory, mount point, or symlink) must manually run fs examine and fs lsmount on each component separately, or write wrapper scripts. This project implements a new fs pathinfo subcommand in C that walks a given path, iteratively resolves each prefix using the existing pioctl interface (VIOC_AFS_STAT_MT_PT, VIOC_FILE_CELL_INFO, lstat), and reports the type of each component in a human-readable format consistent with existing fs output. Deliverables include: the subcommand implementation integrated into src/venus/fs.c, support for both relative and absolute paths, a -verbose flag, a fs_pathinfo(1) man page in POD format, and a regression test suite covering all major path resolution scenarios.

Executive Summary: Create a Comprehensive FHIR facade Layer For OpenELIS Global. The Challenge: The Synchronization Gap The current architecture utilizes a HAPI FHIR JPA "Sidecar" which functions as a secondary, disconnected data store. This results in: Data Latency: Clinical data is trapped in a "sync queue," delaying real-time care coordination. State Drift: Risks of "Split-Brain" where the LIS database and FHIR store disagree on patient records. Resource Waste: Redundant storage of the same data in two different PostgreSQL schemas, increasing infrastructure costs by ~40%. The Solution: Real-Time Native Facade I propose a Native FHIR Facade embedded directly within the OpenELIS Spring context. This transforms OpenELIS into a FHIR-native server without the need for a secondary database. Core Innovations: HAPI Plain Server Integration: Swapping the heavy JPA engine for a lightweight RESTful controller. Live Resource Mapping: A FhirTransformService that maps OpenELIS Domain Objects (Java 21 Records) to FHIR Resources on-the-fly. Atomic Transactions: FHIR writes (POST/PUT) share the same @Transactional context as the LIS, ensuring 100% data integrity. Technical Implementation Stack Language: Java 21 (leveraging Pattern Matching for cleaner transformation logic). Engine: HAPI FHIR (Plain Server Library). Mapping: Manual POJO transformation or MapStruct for high-performance throughput. Validation: Native HAPI FhirValidator to ensure compliance with regional Implementation Guides (IGs).

<p>This project aims to extend the current DSL based component code generator to also generate RoboComp components that can be run in the browser. The new components generated will be using javascript and as an html file should be able to be deployed in the browser and also to communicate with the non JS components already developed earlier (laser, keyboardcontroller, joystick etc.). It is an interesting diversion from current robotics technologies based on C++/ python to use JavaScript to code some highly concurrent components.</p>

The eventyay platform consolidated its talk and video components into a single codebase, but the integration between them remains manually wired and fragmented. Organizers must manually keep talk rooms and video rooms in sync, there is no system for assigning MCs to video rooms, and the video interface shows no speaker or session context — all four gaps confirmed through direct codebase audit and live instance testing. I will build the missing integration layer and deliver: an event-driven room sync system using Django signals and the existing Channels broadcast infrastructure, a full MC assignment system with model, API, admin UI, and email notifications, and a speaker metadata pipeline that pushes TalkSlot data into the Vue.js video interface in real time. Having worked in this codebase, I noticed these gaps firsthand while testing my own PRs — creating a room in the talk component and switching to video still requires manual coordination. I've worked with the exact role-assignment and notification architecture this project replicates for video rooms.

Solidity is a language for Smart Contracts used by the Ethereum Solidity compiler. Solang is a new implementation of the Solidity compiler, which can target wasm on more blockchains. Solang is written in rust and uses a generated Solidity parser. Modern IDEs provide syntax highlighting, symbol definition, errors, warnings etc. This is often done via the Language Server Protocol. There are no good implementations of a language server for Solidity, however using the parser and resolver of Solang, this can change. The idea of this mentorship is to extend the Solang Compiler project so it can run as a language server, that implements the Language Server Protocol.

<p>RoboComp is an open-source robotics framework that affords the tools to create software components. These components communicate through interfaces and can be generated and modified by the tool Robocompdsl.</p> <p>Components’ configuration and parameters are specified in a CDSL file, that is used by Robocompdsl to generate the component in one of the three possible languages: Python, C++, and C++11.</p> <p>Until now, these components could only be created executing the tool from the command line. The aim of this project is to develop Robocompdsl-gui, a graphical interface for Robocompdsl to make the user experience more enjoyable and to avoid programming errors.</p>

<p>This project will improve the CDT for eclipse by using cquery or clangd language server for getting source code analysis of a C++ project.</p>

This proposal aims to modernize Apache Airavata's administrative features by migrating the current Django-based portal to a React based single page application. This migration includes implementing features crucial to admin functionality, such as workspaces, groups, and settings.

<p>This project aims to try and detect anomalies that occur in a CoreDNS server using a machine learning model developed in Keras. This project would help automate the process of anomaly detection, and reduce the necessity to write anomaly detection 'rules'.</p>

<p>The aim of this project is to augment the functionality of the Issues tab in Chrome Devtools by giving users the ability to Hide issues in the Issues Tab. This feature will promote a better developer experience, clean the UI of the issues tab and improve the usability when the amount of added issues is high.</p>

This proposal aims to significantly enhance CircuitVerse's user experience and technical foundation by migrating core UI elements to reusable View Components, optimizing search performance and UI/UX using Hotwire/Stimulus, improving overall site navigation with Turbo Drive, fixing UI bugs, streamlining user flows, and implementing RTL language support.

gRPC is an industry-standard API abstraction and runtime. Currently, tremor supports interfacing with the outside world over WebSockets, HTTP/1.1, or target-specific connectors. Adding support for gRPC will allow generalizing a whole lot of client and server connections and making interfacing with other cloud-native applications easier. The goal of this project is to add support for such generic gRPC based services.