Explore Projects

The Mifos Payment Hub EE (PH-EE) is a massive ecosystem with about 42 Java repositories that run the open-source DPI payment infrastructure. But there’s a problem: over the years, these components have drifted apart. We have a mix of everything: Java 8 to 17, Spring Boot 2.1 to 3.2, and the old javax.* namespace. This mess makes the platform hard to maintain, full of security risks (CVEs), and prone to dependency hell where one tiny conflict can break the whole stack. My goal for this GSoC is to fix this once and for all. I will lead a systematic migration to a modern, unified baseline: Java 21, Spring Boot 3.4, Apache Camel 4, and Jakarta EE 10. To be sure that everything is perfect, the project introduces a three-level test framework: a BOM verification step (classpath purity check that fails on any javax.* artifact), WireMock + Cucumber integration tests for behavioral equivalence validation, and an end-to-end smoke test via Mifos Gazelle against a live k3s deployment. A platform BOM and a connector starter template standardize dependency governance and build configuration across all components, so the unified baseline remains enforceable after GSoC ends.

This project aims to implement a Visual Attribute Mapping System that enables users to automatically map node and edge attributes to visual properties within the GraphSpace interface. This system will allow users to generate meaningful graph visualizations where the appearance of graph elements directly reflects underlying attribute data — turning raw data into visual insight. There are two main components in this project: User Interface for Visual Attribute Mapping — A new Visual Attribute Mapping panel integrated into the GraphSpace Layout Editor. This interface will allow users to select graph attributes and map them to visual properties through an interactive configuration panel. Users will choose between Discrete Mapping (categorical attributes) and Continuous Mapping (numerical attributes). The interface will dynamically display configuration options based on the selected mapping type and visual property. Backend Support for Attribute Mapping — Backend services that read graph attributes, validate mapping configurations sent by the frontend, compute Cytoscape-compatible style rules, and store them via the existing layout update API. This component integrates with the existing update_layout controller and the style_json storage mechanism — requiring no new database tables.

This project aims to enable many authentication frameworks and add support for an authentication layer to Glee. This will give developers the ability to use Glee to create secure online applications with a variety of authentication choices. To accommodate future additions of new authentication frameworks, the authentication layer will be created to be modular and adaptable. After this project, when using Glee to build a server, the developer should be able to specify the authentication strategy they wish to support. Token-based authentication: This could be done using the jsonwebtoken npm package, provision will be made for both refresh and access tokens. Access tokens will be short-lived tokens, while refresh tokens will have longer life spans and allow for renewal of the access tokens. Basic authentication: This authentication strategy would be implemented from scratch. Certificate-based authentication: certificate-based authentication will be implemented from scratch. OAuth 2.0 authentication: OAuth 2.0 authentication will be achieved using the node-oauth2-server npm package. Session-based authentication: The viable option here will be to build the session-based authentication from scratch, as many of the options available such as passport-session, express-session, and fastify/session are all framework dependent.

The Mifos X WebApp is a powerful tool but it can be hard for people to use every day. A lot of institutions have a tough time with it because it is complicated and not easy to navigate, which slows down the people who work there. This project wants to make that better by putting an AI Assistant right into the Mifos X WebApp. The Mifos X WebApp will have an AI Assistant. You can think of the AI Assistant as a place where users can type what they need in language like finding a client making a loan or looking at a transaction and the AI Assistant will take care of the rest. The AI Assistant is powered by a kind of computer program and it talks to Apache Fineract through the Mifos MCP server. The AI Assistant also works with both cloud-based and on-premise models using Ollama so institutions that need to keep their data in their buildings can do that too. The main things we want to achieve with this project are an Angular chat interface built into the Mifos X WebApp, the Mifos MCP server integration, for calling Apache Fineract APIs in a way, an LLM layer that works with both cloud and local models, answers that are based on the current client, loan or user role, and good documentation and tests to go with the Mifos X WebApp and the AI Assistant.

openPIP is an open-source platform for hosting and visualizing protein-protein interaction (PPI) data. The current version is built on a PHP 5.6 / Symfony 2.8 stack that has reached end-of-life, making it difficult to maintain and extend. This project performs a complete rewrite of openPIP using modern web frameworks: a React single-page application frontend with Cytoscape.js for network visualization, a REST API backend (Python/Django REST Framework or Node.js/Express, to be finalized with the mentor), and a PostgreSQL database, all containerized with Docker. Key deliverables include: (1) a clean REST API replacing the 27 monolithic PHP controllers, (2) an enhanced data upload pipeline supporting PSI-MI TAB and CSV formats with drag-and-drop, real-time validation, and async processing, (3) a responsive React frontend with interactive search, network visualization, and an admin panel, (4) production-ready Docker Compose deployment, and (5) a data migration script for existing openPIP deployments (HuRI, YeRI). I have direct experience with the openPIP codebase, having created its deployment guide and migrated the platform from openpip.baderlab.org to openpip.usask.ca.

Problem: Git's "partial clone" is a lifesaver for huge repos because it lets you download only the files you actually need. But once you download a file (a "blob"), it stays on your disk forever. Currently, Git has no way to "un-fetch" these files. Over time, your "partial" clone starts looking like a massive full clone, and the only fix is to delete everything and start over. Solution: I want to build a "reverse gear" for partial clones. My project will add a safe way for Git to drop large, local files you no longer need, while keeping a "promise" that it can get them back from the server later. I’ll be focusing on three main things: Safety: Ensuring Git double-checks that the server still has the file before we delete it locally. "Promise" Contract: Updating Git’s internal records so it knows a deleted file isn't missing, just stored remotely. User Control: Adding this to git maintenance so users can easily reclaim space without being C experts. By the end of the summer, Git will have a new capability to prune local blobs safely. This includes the core C logic for identifying and removing objects, integration with the git maintenance command, and a full suite of tests to ensure no data is ever lost.

Modern printer testing remains heavily dependent on physical hardware, making it slow, expensive, and difficult to scale for regression testing. While OpenPrinting already provides a Go-based MFP simulator and a Python-based image evaluation framework, these components are not yet integrated into a unified, automated testing system. This project proposes to build an end-to-end, hardware-free print testing pipeline that bridges this gap. The system will be implemented as a Go-based orchestration tool that directly leverages the simulator’s internal libraries for efficient control, while embedding Python to execute advanced image evaluation. It will automatically load printer models, create CUPS queues, enumerate all supported print modes, execute print jobs, capture simulator outputs, and evaluate them against expected results. The pipeline will support both single and batch testing modes, enabling scalable regression testing and seamless CI/CD integration. It will generate detailed, structured reports with quality metrics (e.g., SSIM, PSNR) and pass/fail analysis. By transforming isolated components into a cohesive, automated system, this project will significantly enhance reliability, reproducibility, and scalability of printer testing in the OpenPrinting ecosystem.

<p>The main goal of this project is to create a component that has a clear API that can provide autocomplete feature for the jupyter kernel - mariadb_kernel. And also I hope that component can be easily integrated with not just jupyter, but also VSCode and Atom … etc popular editor. The main feature has two:</p> <ol> <li>can get the latest MariaDB keywords and functions for autocompletion. (implement new table in MariaDB's information schema, and can use SQL command to get the information)</li> <li>provide an introspection feature that can inspect the word's info and some real data.</li> </ol> <p>And this project autocompletion feature is based on mycli's autocompletion engine. Then do some enhancement on that. Such as:</p> <ol> <li>Database suggestion before 「.」. Ex: 「insert into db_name_to_be_completed.table_name VALUES (...) 」</li> <li>add global and session variable suggestions</li> <li>can suggest system default database, table, column. Ex: add column suggest for system table like mysql.user.</li> <li>Autocompletion about database_name.table_name_to_be_completed could suggest the table, which not in the currently selected database</li> <li>fix some bugs related to the word of the user is the column name and also is the keyword</li> </ol>

<p>The emergence of serverless computing moves cloud/edge to the next generation of resource sharing: function as a service. The innovation makes developer released from provisioning, updating, and managing servers under flexible scalability and fault tolerance. Also, the most influential outcome is no computing cost when idle, which is also known as pay as you go model.</p> <p>However, the performance is under critical to be improved, i.e., more servers required in existed serverless platform, high and not predictable round-trip latency, especially under high concurrency and keeping dependable.</p> <p>Here come some places to improvement, including shortened path, performance improvement on invoker, serialization elimination, and scheduling. In the first step, the picked-up topic: <strong><em>work-stealing and priority-based scheduling and direct connection for streaming capabilities</em></strong> will be a great and valuable choice.</p> <p>Goal on this project</p> <ol> <li>Work-stealing scheduling on load balancer.</li> <li>Direct connection for stream support.</li> <li>Priority-based work-stealing scheduling.</li> <li>Comprehensive tests to avoid bugs on concurrency and distributed failure.</li> <li>Performance tests and optimization.</li> </ol>

This is the tentative proposal submission for the Geant4-FastSim - Building an ML pipeline for fast shower simulation. This proposal discusses a detailed approach to implementing the Kubeflow End to End Pipeline for the existing framework. The proposal consists of a synopsis discussing how the proposed approach was thought and what were the key insights that motivated the steps mentioned. It further discusses the task that will be encountered throughout the Project timeline and the Major Deliverables that would mark the completion of the project. The Major tasks have been visited in detail in the proposal and these are used to determine the objectives for the weekly progress timeline in the project. The proposal tries to cover up all the adopted methodology's significant detail and come up with the most ideal way to tackle each and every task. Deliverables: End to End Deployed ML Pipeline on Kubeflow Meta Logger component throughout the pipeline to store and analyze the results Experimenting with existing and new algorithmic approaches that might improve the performance, throughput of the modeling pipeline Creation of a connector component for the transition from training phase into the inference phase. Iterative development of the Pipeline into a generalized workflow that is capable of scaling to newer versions of data as well support the integration of newer algorithmic experimentation Well documented results and analysis for motivating additional focus on the pipeline as well motivating the use of this pipeline for different projects \

Software acceleration utilizing specifically designed hardware components is a widely used technique for speeding up different kinds of kernels found in the targeted applications. An example of such kernels in High-Performance Computing (HPC) are algorithms involving the computation of sparse data structures. Sparse applications are difficult to accelerate due to their memory-bound nature, which means that the data is not accessed contiguously in memory. That implies many scatter and gather accesses to the comparatively slow memory. Consequently, dedicated hardware components capable of accelerating the scatter/gather instructions, are a key to improve the performance of sparse applications. The goal of this project is to achieve an FPGA-based acceleration of the vrgather RISC-V vector instruction (RISC-V ISA vector extension v1.0) using a bitonic network. The bitonic network is originally a sorting network that implements the merge-sort algorithm (add reference here). A number of inputs of the network can end up in any output after traversing it. When this concept is applied to a Vector Register File, the bitonic network can be used not only to sort a set of vector elements, but also to move data internally from one register to any other register. The scope of this project is limited to the execution and acceleration of the gather vector instruction, in which the variability of the vector length needs to be considered.

<p><em>The aim of this project is to implement a backend for museums &amp; exhibits that utilizes Physical Web technology. </em>The backend will allow visitors to access information about exhibit pieces without the need to install any apps. Physically, this will be accomplished using Eddystone beacons located near each piece. We focus on developing the software used with the beacons.</p> <p>To achieve this, we will create an Android App that allows museum curators to configure Physical Web beacons they want to deploy and upload the content that will be served. The app will support combinations of text, images, audio and video - it will use Google Drive for its storage backend. The app will also allow the curators to create a map of the exhibition &amp; beacons - also stored on Drive.</p> <p>Once activated, the beacons will direct visitors to the URI of a webapp that we will also develop. The webapp will run on a server that connects to the Google Drive folder created by the Android app. This webapp, run on the museum’s servers, will use the map along with Web Bluetooth technology to learn the user’s location (by listing nearby beacons and their signal strength) and display to the user the content most relevant.</p>

Performance evaluation of DLTs is a complex process stemming from the inherent complexity of distributed systems. One way to mitigate such complexity is the separation of concerns: use task-oriented solutions for different aspects of the process: - The System Under Test (SUT) is deployed in a representative operating environment. - A dedicated, purpose-specific load generator tool submits representative requests to the SUT. - The SUT is closely monitored during the load generation process, and the measured data is typically stored for post-mortem analysis. - A detailed analysis is performed on the measured data using dedicated data analysis techniques. A summarizing report is the typical final output of the process, containing insights about the SUT. Hyperledger Caliper provides capabilities to integrate lightweight components that can retrieve aggregated results from external components and incorporate them into the generated report. The goal of the project is to provide a single entry/exit point to the performance analysis (once the SUT and its monitoring are configured) by: Providing an open, well-designed, and thoroughly documented side-car service for the detailed performance analysis of distributed Fabric transaction traces. And integrating it into the Caliper load generation and response measurement process as part of the final report. The project will heavily build on the PSWG's Performance Sandbox, aiming to "standardize" its flow and methodologies independently

APPLICATIONS ARE CLOSED. Please apply again in the Fall! We will post more information when it is available. Linux is the most widely used operating system in the world. The core software component of the Linux operating system is the kernel. Some of its roles include managing hardware interactions, virtualizing system resources, and enforcing security constraints. In effect, the Linux kernel powers almost all of the world's top supercomputers, android phones, and an innumerable variety of other computers. This course will introduce students to the Linux kernel development by focusing on device driver development, particularly character devices and the /proc and/sys interfaces. This will give students hands-on experience working with internal Linux kernel APIs for hardware access, memory management, DMA and interrupts, among other, and provide an overview of some of the core features and components of the kernel, such as scheduling, system calls, the boot process, and hardware description trees. Gaining an understand of the inner workings of the operating system and how to make changes to it will give students an invaluable perspective on how computers work behind the scenes, which will reveal a new layer of understanding to apply to any future software engineering practice. This is a new format of the following courses we created: https://www.uml.edu/catalog/courses/COMP/3085 or https://www.uml.edu/catalog/courses/COMP/5170

The goal of this project is to provide a Model Context Protocol (MCP) server that is suitable for production and exposes expected REST endpoints from the European Nucleotide Archive (ENA) as organised, schema-driven tools for AI systems. Although ENA offers robust REST APIs for biological data access, direct integration with AI agents frequently results in inconsistent queries, low reproducibility, and lack of validation. In order to overcome this, the project implements an MCP-based interface layer that ensures predictable execution, provides a strict input/output schemas, and enables secure, secure communication with ENA services. A dynamic tool registry for flexibility, Pydantic for schema validation, httpx for asynchronous API communication, and a response normalisation layer for consistent outputs are all features of the FastMCP-built system. To ensure scalability and production readiness, it will also include a comprehensive error handling, testing, and containerised deployment using Docker and Kubernetes. A fully functional MCP server with several ENA capabilities (such as study, sample, and run queries), thorough test coverage, developer-friendly documentation, and a deployable system that is simple to interface with AI clients are some of the key deliverables. This project will enable more dependable AI-driven scientific workflows by improving the reproducibility, traceability, and accessibility of biological data.

This project aims to make the Ubuntu Desktop Provision installer fully accessible to visually impaired users by addressing key accessibility issues in its Flutter-based interface. Currently, the installer lacks proper screen reader support, suffers from poor keyboard navigation, and fails to provide audio feedback, making it unusable for blind and low-vision users, especially those relying on Accessible-Coconut, a Ubuntu-based distribution developed by Zendalona. The solution involves fixing both architectural and UI-level problems in how Flutter components interact with Linux accessibility frameworks (AT-SPI). It will include: - Implementing semantic accessibility wrappers - Ensuring proper focus and navigation flow - Enhancing screen reader feedback using Orca - Improving the accessibility of complex UI components, such as partitioning - Conducting extensive user testing and providing detailed documentation Deliverables - A fully accessible Ubuntu installer with complete screen reader compatibility - Keyboard-navigable UI with audio cues and meaningful semantic labels - Documentation and developer guidelines for future accessibility improvements - Tested integration with Accessible-Coconut 24.04 This project will enable independent system installation for visually impaired users and contribute long-term value to Flutter-Linux accessibility efforts and the broader open-source community.

This project addresses the critical challenge of GPU resource management in ML/AI research environments where researchers often face delays due to inefficient resource allocation. I'll develop a comprehensive CPU-based control plane that efficiently orchestrates GPU resources through four key components: an advanced job scheduler with priority management and preemption capabilities, a comprehensive observability platform with real-time dashboards, a streamlined model deployment pipeline with CI/CD integration, and robust infrastructure automation. By implementing technologies like Slurm for scheduling, Prometheus/Grafana for monitoring, Terraform/Ansible for infrastructure automation, and integrating ML-specific tools like MLflow and NVIDIA Triton, the system will deliver significant benefits to researchers: reduced wait times for GPU access, transparent visibility into resource availability, priority access for time-sensitive research, and a seamless deployment pipeline from training to serving. Deliverables include a functioning scheduler with priority queue support, a comprehensive monitoring system with custom dashboards, infrastructure-as-code modules, a model deployment pipeline with CI/CD integration, and an intelligent alerting system. The complete solution will serve as a reference implementation for academic GPU cluster management, providing reusable components and best practices for similar infrastructure requirements in the ML research community.

<p>Improve the performance and scalability of TEAMMATES.</p> <ol> <li>Migrate Storage component to Objectify API<ul> <li>Rewrite entire Storage layer to use Objectify instead of JDO</li> <li>Deploy change and divert small amount of live traffic to new version for testing</li> <li>Turn on Objectify global cache (uses memcached); do similar isolated testing</li> <li>Fix issues surfaced during live testing (if any), then fully deploy new version</li> </ul> </li> <li>Write performance profiling tests for Storage and Logic components<ul> <li>All methods in Storage and Logic API to be profiled for cost and performance</li> <li>Use remote API client for client-driven testing</li> <li>Use task queues for app-driven testing</li> <li>Results to be used as a benchmark when making changes to the architecture</li> </ul> </li> <li>Redesign schema<ul> <li>Determine entity groups based on GAE transaction limits and our usage</li> <li>Use conceptual relationships as much as possible while keeping within limits</li> <li>Plan for extensibility: should be able to support new features like LTI compliance without too much effort</li> </ul> </li> </ol>

Bio-Block is an open-source healthcare data marketplace on Ethereum and IPFS that handles the full upload → anonymize → encrypt → sell → download lifecycle. However, the pipeline stops at download — once a buyer purchases and decrypts a dataset, there is no way to analyze it inside Bio-Block. This project adds a data analytics layer by introducing a dedicated FastAPI Analytics API (port 3003), a lightweight AnalyticsRegistry smart contract for on-chain result tracking, and a React dashboard for visualizations. The system supports three levels of analysis: graphical (distribution plots, heatmaps, scatter plots via matplotlib/plotly), descriptive (summary statistics, correlation matrices via pandas), and inferential (t-tests, chi-square, ANOVA via scipy/statsmodels). Results are stored on IPFS and linked to their source datasets on-chain via the AnalyticsRegistry contract, maintaining an unbroken chain of custody from data purchase through analysis. Deliverables include: (1) Analytics API microservice with EIP-712 authentication, (2) AnalyticsRegistry.sol smart contract deployed on Sepolia, (3) IPFS result storage and on-chain attestation pipeline, (4) Interactive React analytics dashboard integrated into the existing frontend, (5) Comprehensive test suite (80%+ coverage) and documentation. An optional differential privacy layer using OpenDP is planned as a stretch goal.

The Internet Yellow Pages is a database containing information about internet resources including domain names, autonomous system numbers (ASNs), and subnets, which it receives from 18 organizations including Cisco, Cloudflare, and Stanford University. The data is stored using Neo4j, a graph database known for its flexibility and scalability. It is important that the Internet Yellow Pages contain accurate data from all these sources and provide users with the data quickly and efficiently. However, IHR currently computes a new database of this form each week, and this deployment is not automated, which increases the time it takes to make the new data publicly available. Thus, the goal of this project is to design and implement an automated pipeline to deploy a new database to a remote server each week and to upload the database dump to a public repository. The solution must be maintainable and rigorously tested, with unit tests for each IYP dataset. This ensures that users receive reliable data with no downtime and that future developers can easily expand upon the pipeline. These goals were accomplished by completing the following four subparts: creating unit tests, creating a pipeline to automatically compute a database dump and push it to IHR’s archive, integrating the tests into this pipeline, and extending the pipeline to also deploy a running instance of the database to a remote server. Caddy is used to hotswap newly computed databases and to provide access to previously generated databases.

This proposal aims to implement HTTP/3 communication for Dubbo Triple in the Go language environment, enhancing the connection management capabilities of the Triple protocol in dubbo-go. The proposal will address the compatibility issues between Triple communication in dubbo-go and dubbo-java by implementing keep-alive functionality at the Triple protocol layer. Additionally, the proposal plans to organize and standardize the error codes of the Triple protocol and output necessary log information. By developing a Triple HTTP/3 server and client, seamless and high-performance communication between Dubbo Java and Dubbo Go over the HTTP/3 protocol will be achieved. We will design a connection pool to effectively manage Triple connections and ensure the validity of connections through a PING-PONG mechanism between the server and client, thus realizing keep-alive functionality. Furthermore, the error codes of the Triple protocol will be standardized according to Dubbo Java's standards to facilitate developers in obtaining detailed log information during the debugging process. The final deliverable of the proposal is to achieve high-performance, barrier-free communication between Dubbo Go and Dubbo Java through the Triple protocol, ensuring perfect compatibility and support for interaction via the HTTP/3 protocol. Users will be able to enjoy flexible keep-alive functionality and improve debugging efficiency through standardized error codes.

Linux Kernel Livepatching is the process of replacing functions in the kernel code affected by CVEs with the patch-applied functions during system runtime. It's basically a method to apply security kernel patches to a running system such as a server without rebooting it. Such a feature is crucial for servers running crucial computational tasks 24/7 which cannot afford a reboot. Livepatch module is already provided by the Linux kernel but it's upto the distributions as to how they will be handled. As of 2026, only a few handful amount of distributions like SUSE, Ubuntu and RedHat offer Linux livepatches, which means no community maintained distribution at the moment offers Linux livepatches. There has been a way to utilise Linux livepatching in Debian in the past using kpatch but after the release of Debian 13 Trixie, the support for the kernel in kpatch has been dropped which halted the progress of supporting livepatching in Debian. klp-build is a promising approach to this problem but it only supports SUSE kernels which are only accessible by internal SUSE employees. Debian also lacks a release plan or mechanism to distribute livepatches for kernels. The goal of this proposal is to introduce Linux livepatching in Debian by studying how livepatches can be integrated into Debian and if existing technologies like clang-extract can be integrated into the workflow, forking klp-build to develop dlp-build which will serve as a tool to create livepatches for Debian kernels, as well as proposing a binary format for livepatches and designing a release cycle for the same.

We would like to develop an LLM-based financial data analytics application using open source LLMs, embedding models, the LlamaEdge application server, vector databases, and data processing tools. It will provide an open source "template" and showcase "best practices" for similar applications in this fast growing application area. Expected Outcome: * Create a data processing pipeline in Python or Rust to automatically * collect public company’s SEC 10-Q quarterly reports and press releases. e.g., [Apple 10-Q](https://www.sec.gov/edgar/browse/?CIK=0000320193) and [Apple press release](https://www.apple.com/newsroom/2024/05/apple-reports-second-quarter-results/) * generate a summary for each SEC 10-Q and press release documents using an LLM service such as [LlamaParse](https://docs.llamaindex.ai/en/stable/llama_cloud/llama_parse/) or [EYELEVEL xRay](https://dashboard.eyelevel.ai/xray/) * create and continuously update a vector database with the summary and original text. The vector is computed from the summary to improve search efficiency. * Create a server-side RAG app that can chat with the vector knowledge base of financial statements. * Evaluate the answer quality * Explore LLM function calling to incorporate real-time information and actions