Explore Projects

The 52°North Weather Routing Tool (WRT) computes fuel-optimal maritime routes but is entirely configuration-file-driven, making it inaccessible to non-developer users. This project delivers a QGIS plugin that solves this problem. A six-page guided wizard covers route setup with map-click waypoint entry, vessel parameters, weather and depth dataset upload with validation, algorithm selection, and constraint configuration - exporting a ready-to-run JSON config. A dockable weather panel renders NetCDF variables as time-animated layers with spatial subset statistics. A route visualization module displays WRT output with per-waypoint fuel consumption popups and distance calculation. An optional component runs the WRT directly from QGIS via an isolated Python venv, streaming live progress to the canvas. Deliverables: installable QGIS plugin, all four components and full documentation.

This project aims to refactor GreedyBear's dashboard into a fully configuration-driven widget system, giving administrators the power to tailor the interface without any code changes. Currently, every widget (type, data source, size, and position) is hardcoded, making customization impossible without touching the source code. The work is organized into three layers: a Widget Registry that maps each widget to its React component, default size, and API endpoints; a Dashboard Configuration stored as a JSON blob in the backend and served via a DRF endpoint; and an Admin UI featuring drag-and-drop reordering and resizing, accessible only to superusers. All eight existing widgets will be refactored into self-contained, registry-conformant components, and a shared useWidgetData hook will eliminate duplicated data-fetching logic across the codebase. A Django DashboardConfig model will persist the global layout, with a graceful fallback to the default configuration when none exists.

<p>Mono is a open source development platform based on the <code>.Net Framework</code> and allows developers to build cross-platform applications. Mono's .NET implementation is based on the ECMA standards for <code>C#</code> and the <code>Common Language Infrastructure</code>. It includes both developer tools and the infrastructure needed to run .NET client and server applications on <code>Linux, Microsoft Windows, Mac OS X, BSD, Sun Solaris, Nintendo Wii, Sony PlayStation 3, Apple iPhone and Android</code>.</p> <p>The implementation of Pipe Streams in <code>Mono</code> doesn't support some functionalities such as parallel builds on msbuild. <code>CoreFX</code> is the foundational libraries for .NET Core. The implementation of Pipe Streams in CoreFx fixes the previous problems. So, the goal of the project was to import <code>System.IO.Pipes.PipeStream</code> from CoreFX to Mono. Doing this, new features are offered by Mono.</p>

My idea for this GSoC period is basically about improving the UI/UX of the admin portal and making it according to the design standards that are defined in talawa docs, also I will make it mobile responsive. Another focus I have this summer is to make all the screens (components) of talawa-admin functional i.e. No more hard-coded values in the admin portal, all the data will be live from talawa-API. I will also implement a way so that users can select or use talawa-admin in their preferred language and I will be implementing a feature for detecting whether a user is spamming a chat or not. Below are the features for talawa-admin that I am going to add this summer that will boost its usability, user experience, and its use cases. Talawa-admin Features: Interactive UI/UX. Multiple screens (Mobile or Tablet) are responsive. Functional screens (components). Implementing the support for different languages. Feature to detect whether the user is spamming the chat or not. Migration from redux-routing to react-routing. *

Apache Fory's compiler can generate type bindings for seven languages, but neither Swift nor Dart have gRPC service generation support. The generate_services() extension point exists in BaseGenerator and is wired into the CLI, but no language implements it yet. This project adds that support for both: Dart will get a new compiler generator (dart.py) covering messages, enums, and unions alongside gRPC stub generation, while Swift will extend the existing SwiftGenerator with generate_services(). Both will emit typed service interfaces and transport bindings using Fory's serialize/deserialize APIs as the codec, covering all four RPC streaming modes with a zero-copy decode path where possible, without introducing any gRPC dependency into the Fory runtimes. Deliverables include the Dart compiler generator, gRPC stubs with golden tests for both languages, runnable server and client examples, cross-language round-trip tests against a Java server, and compiler documentation for the --grpc flag.

<p>I worked on merging the susi_skill_cms, account.susi.ai and chat.susi.ai into one consolidated susi.ai repository and integrating redux, upgrading material-ui and react versions. I implemented a chat bubble at bottom right which allows users to interact with susi.ai and test skills by clicking on their respective speech bubbles. Features implemented by me are:</p> <ul> <li>Skill Creator</li> <li>Dashboard: My Devices</li> <li>Chat Bubble and Speech Bubble for Skill</li> <li>Admin: Bots, Devices and System Skills</li> <li>Admin: CRUD operations on Config Keys in Settings</li> <li>Admin: Edit User Settings </li> <li>Added API endpoints in JAVA: ListDeviceService, ListPrivateSkillService and ListPrivateDraftSkillService</li> </ul> <p>I also enhanced the existing UI, fixed mobile views, integrated styled-components, created shared components, modified various API endpoints in JAVA and fixed various bugs.</p>

GDB-UI currently supports only one user at a time because the backend shares a single global GDB controller across all requests. When two users debug simultaneously, the second session silently destroys the first with no error or warning. This proposal implements a three-phase solution. Phase 1 replaces the global controller with a thread-safe SessionManager that gives each user their own isolated GDB instance via a UUID session_id. A working implementation is already open as PR #131 with 15 passing tests, security fixes, and a live demo page. Phase 2 introduces WebSocket streaming with a per-session reader thread architecture so GDB output reaches the frontend in real time without blocking the server. Phase 3 moves each project into an isolated Docker container using the Docker SDK exec_start socket API for interactive GDB attachment, solving file descriptor exhaustion at the OS level. Deliverables: merged SessionManager with full test coverage, WebSocket streaming with reconnection handling, Docker sandbox with resource limits, security audit, and handover documentation.

Meshery stands as the canonical cloud-native management plane, rigorously managing the lifecycle, performance, and topologies of multicloud infrastructure. Currently, Meshery manages multiple load generators (Nighthawk, Fortio, Wrk2) to execute Service Mesh Performance (SMP) benchmarks. However, the heavyweight C++ Nighthawk binaries are bundled directly inside the meshery/meshery Go backend container. This statically couples the data plane execution to the control plane, bloating the core image size and preventing independent scaling. This project resolves this architectural flaw by cleanly severing Nighthawk from the core server and wrapping it into an autonomous, standalone gRPC adapter (meshery-nighthawk). To achieve this, I will evolve the existing meshkit/meshes/meshops.proto into a generalized adapters.proto capable of routing both traditional service mesh commands and raw load-generation requests. By the end of this project, Meshery Server will dynamically discover and orchestrate Nighthawk as a first-class out-of-tree component, supported by fully overhauled CLI commands (mesheryctl perf), Helm chart deployments, and a dedicated Meshery UI Adapter chip.

This project aims to extract the Salt event processor from Uyuni's Tomcat web server and turn it into a standalone containerized service. Currently, Tomcat handles both web requests and Salt event processing. The problem is that processing Salt events can be resource-intensive, potentially affecting the performance of the web application also running in Tomcat. By decoupling these components, I'll create a containerized service that processes Salt events independently, improving overall system performance and reliability. The implementation will involve extracting the existing Salt event processing logic, packaging it as a standalone service, containerizing it, and extending Uyuni-tools to deploy and manage this new component with scalable considerations. The current event processing logic will be preserved while adding proper scaling, monitoring, and configuration capabilities. Deliverables include a fully functional Salt event processor containerized service, integration with Uyuni-tools for deployment management, documentation, and performance benchmarks showing improvements. This architectural improvement will allow Tomcat to focus solely on serving web requests while the event processor can handle Salt events in a more scalable manner.

The OpenMRS O3 Service Queues app manages outpatient clinic flow but suffers from performance issues due to over-fetching deeply nested objects via custom REST representations, UI components that diverge from O3 design conventions and broken interactions including non-functional buttons and silent failures. This project builds a dedicated REST endpoint in openmrs-module-queue following the emrapi PR #250 pattern, returning only the data the queue table needs with server-side pagination and batch loading. Visit details are lazy-loaded on row expansion. On the frontend, the custom vitals component is replaced with the shared patient-vitals-info extension, encounter parsing is standardized to use configurable concept UUIDs and SWR data-fetching is optimized with activity-aware revalidation. All broken buttons are either fixed or removed. Deliverables include the dedicated backend endpoint with database indexes, frontend migration with lazy-loaded visit details, UI alignment with O3 conventions, fixed interactions with proper error handling, activity-aware SWR optimizations and comprehensive Playwright E2E tests with before/after performance benchmarks.

<p>Web Sites have evolved a lot from static mundane texts to interactive ajax based web sites and today’s Single Page Applications which provides user with a very intuitive experience. React has been one of the front-runner frameworks spearheading this more robust front ends rendering SPA frontend dramatically fast. This has been at the cost of getting down a barrage of javascript in the beginning and rendering it on the fly using the browser’s Javascript and rendering engines. This is counter intuitive to the User Experience goals of a single page application paradigm.</p> <p>A trivial solution that comes into mind is to push this workload to the server to process this Logic in the back end and send it to the server. This raises the concerns of the requirement of an Isomorphic JS backend such as NodeJS. However, with a back end that utilize Java 8 which comes packing with a much more advanced Javascript Engine - Nashorn, possibilities crop up.</p> <p>The main idea of this project wraps around finding an efficient paradigm to develop SPA’s by pre-rendering partially or whole HTML DOMs in the back end and delegating the basic DOM rendering of the static or partially static contents to the browser.</p>

Detection time and response time are the major critical accepts of all detection and response systems. Considering the vast amount of system logs collectors, network logs collectors and external IOC systems bring vast amounts of data to process within a short amount of time and uncover the anomalies. Although this process should not be flooded with false positive alerts which we identified as alert fatigue. Considering processing vast amounts of boundless stream data and doing a less false positive detection rate is a system engineering challenge that should stand side by side with cybersecurity expert knowledge. Building state of the art systems required several major components divisions. There are Data Sources (IDS, sys logs, net logs, firewall logs, files) , External intelligence (IOC, SIEM), Processing and detection unit(s) (batch or streaming processing, deployed ML/DL models) , Data storages (databases, flat files, object storages) and visualizations (index, dashboards). Recreating each of above divisions are equivalent to reinventing the wheel, therefore openXDR focuses intergaterabiltiy to work with available tools out there which leads users to use existing systems without hassle but with the power of detection and response time of openXDR. In general, it seamlessly integrates with any EDR, NDR, SIEM, or IDS through a modular integrated architecture.

Currently, in OpenYurt, the core component YurtHub—which acts as a transparent proxy between edge node system components (e.g., kubelet, CNI, CoreDNS, kube-proxy) and the Kubernetes API server—is deployed as a systemd service on each edge node. The installation is performed exclusively via the community-provided tool YurtAdm during node joining. This approach imposes a significant limitation: users must use YurtAdm to onboard nodes, making it impossible to install YurtHub on existing Kubernetes nodes that were not initially provisioned with YurtAdm. To improve flexibility and user experience, the community aims to support a label-driven, declarative installation mechanism: 1. When a specific label (e.g., openyurt.io/is-edge-worker=true) is added to a node, YurtHub should be automatically installed and started on that node. 2. Conversely, when the label is removed, YurtHub should be gracefully uninstalled and its resources cleaned up. This enhancement will enable seamless integration of OpenYurt into existing Kubernetes clusters without requiring re-onboarding of nodes. Expected Outcome: 1. Design and implement a controller/operator that watches for node labels and triggers YurtHub lifecycle operations. 2. Develop an installation/uninstallation mechanism that: a. Installs YurtHub as a systemd service. b. Ensures idempotency and handles failures gracefully. c. Cleans up all YurtHub-related files, configurations, and services

You will create an AI agent based on open-source Large Language Models (LLMs) running on the CNCF WasmEdge runtime and an MCP server. The application will tie together key components in a modern AI agent stack to create a useful application. The AI agent will ask, answer, and explain practice questions for a specific tech certification program. It enables students to study for the certificate tests more effectively. Expected Outcome: 1. Deliverable 1: create a MCP server with 2 functions a. get_random_question(): The function selects a random question from a list. It returns both the question and the answer. This function is called by the LLM when it detects that the user asked for a new practice question. b. get_question_and_answer(): The function searches an input text from the database for an corresponding question and answer. 2. Deliverable 2: create a practice question / answer database on a subject that you are most familiar with. The MCP functions will 3. Deliverable 3: Create an agent app based on the LlamaEdge framework with a 4. Workflow 1 a. The user asks a question. The LLM calls MCP function get_question_and_answer() b. The agent adds the answer to the context c. The LLM converse with the user with knowledge about the question and its answer 5. Workflow 2 The user asks for a practice question. The LLM calls MCP function get_random_question() to get the question and answer.

etcd is a distributed key-value store that serves as the backbone for Kubernetes and other cloud-native systems, storing critical configuration and state data. However, at scale, multiple applications constantly querying etcd for current state and watching for changes can overload the server and create expensive catch-up scenarios for slow subscribers. This project developed an experimental caching solution that brings Kubernetes' proven watch cache pattern to any infrastructure project without depending on the Kubernetes codebase. Core Components: (1) Watch Demultiplexer: Consolidates multiple client watch subscriptions into a single upstream etcd connection, then broadcasts events to all subscribers, reducing server load; (2) Event History Buffer: Maintains an append-only ring buffer of recent watch events, enabling lagging watchers to catch up from local history rather than reopening expensive upstream watches; (3) B-Tree State Mirror: After an initial snapshot, builds and maintains an in-memory B-Tree of current key/value state, applying watch events incrementally for fast range queries and lookups; (4) Point-in-Time Snapshots: Preserves historical B-Tree snapshots in a ring buffer, allowing exact stale reads at specific revisions without hitting etcd; (5) Resilient Control Loop: Handles initialization, upstream errors, compaction events, and automatic cache rebuilding with proper client notification.

The RISC-V movement has massive potential to unify a fragmented industry behind a single instruction set architecture (ISA). If the participants in the industry can agree to focus their efforts on a single processor architecture, rather than duplicating efforts among incompatible architectures, the entire computing ecosystem benefits. Inefficiency in critical base components of the ecosystem hampers this consolidation. There are separate efforts in documenting the RISC-V ISA, succinctly describing the semantics of the ISA in the RISC-V Sail implementation, and the numerous projects which directly serve as the base components of the software ecosystem, including assemblers, disassemblers, compilers, linkers, loaders, simulators, emulators. In summary, the tasks in this project will include: Improving the RISC-V Sail specification. (Sail language, git/GitHub) Improving the Sail parser’s JSON backend to extract more complete and accurate information. (OCaml, git/GitHub) Improving the RISC-V ISA interactive web site with new functionality and information. (Javascript, React, Carbon, or similar web frameworks, git/GitHub) Survey downstream projects which have dependencies on the RISC-V ISA. (C, C++, RISC-V assembly) Implement transformations of RISC-V ISA representation in JSON into downstream project content. (Python or similar, C, C++, RISC-V assembly) Engage with upstream projects (Sail, RISC-V Sail specification) to submit change proposals and see that they become acceptable.

Utilizing cloud FPGAs prove to be very expensive and minor coding bugs could consume precious compute cycles and incur hefty bills. This proves using FPGAs on AWS F1, virtually ineffective for students, enthusiasts and early researchers. Additionally, 1st CLaaS, already has a streaming interface in place, not all hardware accelerators would require continuous streaming of data. The addition of support for Memory Mapped Interfaces like AXI4, AXI4 Lite, Wishbone and custom interfaces similar to RoCC, Core-V eXtension interface etc., would enable a wider ecosystem of hardware accelerators to support 1st CLaaS integration without any RTL Level modifications. Besides these, supporting 1st CLaaS on Local FPGAs/Remote FPGAs contrary to AWS F1 would prove useful to enthusiasts, researchers, professors and students having FPGA on-premise or remotely accessible. 1st CLaaS for PYNQ leverages the PYNQ (Python Productivity for Zynq) Framework, which consists of a Jupyter Server running in a Linux Operating system on the ARM Processor in the Zynq SoC. Addressing the current limitations of 1st CLaaS, the proposed framework that not only brings 1st CLaaS to PYNQ FPGAs, but also vendor agnostically automates TL-Verilog/Verilog/SystemVerilog based Hardware accelerator design from RTL to bitstream and deployment eliminating the need to interact with a wide range of vendor specific tools. The framework would provide a complete FPGA based hardware design flow within the browser/terminal right from designing in makerchip-app and IP-Block design-Bitstream generation to deployment on FPGA in a single command.

<p>The RISC-V Extensions Landscape is an open-source, interactive web tool that serves as a single searchable reference for the entire RISC-V Instruction Set Architecture ecosystem. It visualizes all ratified, draft, and discontinued extensions, displays per-instruction 32-bit encoding diagrams with match/mask values, and supports filtering by RISC-V profiles (RVA20, RVA22, RVA23, RVB23). The project is live at https://rpsene.github.io/riscv-extensions-landscape/ and built with React, Tailwind CSS, and Webpack.</p><p><br></p><p>The core challenge is that only 83 of 220 cataloged extensions (38%) have their instruction details fully mapped. The remaining 137 extensions exist in the catalog but lack instruction encodings, leaving significant gaps in supervisor-level extensions (trap, interrupt, memory), vector subsets, and vector cryptography bundles. Additionally, 104 extension tags from the upstream riscv-opcodes project remain unlinked due to naming mismatches between the source data and the catalog, preventing automated synchronization.</p><p><br></p><p>The mentee will work on three main tasks: (1) reconcile the 104 mismatched extension tags from riscv-opcodes with the catalog's naming conventions, enabling the sync script to automatically populate instruction data; (2) research and map instructions for the remaining extensions, particularly supervisor-level extensions that define CSR behaviors and vector subset extensions that represent subsets of the V extension; and (3) improve the sync tooling to detect gaps and generate coverage reports automatically. The mentee will gain hands-on experience with the RISC-V ISA, open-source data engineering, and React-based visualization tools.</p><p>&nbsp;</p>

<p>*APPLICATION ONLY OPEN TO STUDENTS IN INDIA*</p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>SONiC is a database-centric NOS: much of the control-plane and operational state is available in Redis, and telemetry can poll/subscribe to DB data. There are a variety of interesting analytics and telemetry data that can be extracted from this DB, many by leveraging Redis capabilities. However, directly adding heavy analytics (e.g., long-running server-side scripts) to the primary Redis risks impacting normal SONiC applications. Redis Lua scripts execute atomically but block the server for the full runtime of the script. This project proposes a low-risk pattern: create a Redis replica (master → replica) that maintains a synchronized copy of selected SONiC databases, and run the analytics plane on the replica.&nbsp;</p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><ul><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Design and prototype a “shadow analytics plane” using Redis replication (master → replica) so normal SONiC apps continue to use the primary Redis instance unchanged. Design and implement cold boot, Warmboot and fast-boot.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Implement use-cases, some examples”</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Incident Forensics (A): Build a flight-recorder capability on the replica that can reconstruct recent sequences of “interesting” changes (timeline) and provide a compact incident summary.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Alert Storm Reduction (B): Build novelty detection and heavy-hitter summarization on the replica to suppress repeated alerts and highlight top recurring signatures.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Provide operational documentation: how to deploy, how to tune retention/limits, and how to validate that primary-path performance is not affected.</span></li></ul><p><br></p><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Strong Linux fundamentals; comfortable working in containerized environments.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Python and/or Go proficiency (for collectors, processors, and CLI tooling).</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Basic understanding of Redis concepts (pub/sub, streams, replication) and willingness to learn SONiC DB schemas.</span></li><li><span style="color: rgb(0, 0, 0); background-color: transparent;">Interest in reliability engineering / observability / operational tooling.</span></li></ul><p><br></p>

<p>OpenWiki has been developing the filter stream framework, to allow for converting from some input streams to any/multiple output target streams. Filter stream framework creates generic interfaces for the input which could be written down to any target output stream without any/much changes to the input streams filter. This allows for easy extension of the converter to target multiple output streams target filter, while maintaining a single input stream filter definition.</p> <p>There are some pre-existing extensions that help convert from dokuwiki to XWiki. Using the a steam framework, we can create input streams from dokuwiki which can now be generic and be output to any other wiki schema including XWiki’s own.</p>

<p>Currently Compliance Tester is a command line tool to check compliance status of an XMPP server. Testing servers for compliance with XMPP extensions is a very cumbersome process in which a server admin or willing user has to download the jar, run it and make a PR to the repo with the results to add it in the overview page. Through this project, I intend to automate this process and turn this project to a web service, which will provide a interface for testing servers, periodically run tests on public servers and visualise current and historic compliance status of servers, implementation of XMPP extensions across servers. Custom badges will be generated for servers from the latest test results. Periodic reports will be generated from the test results and sent to subscribers. Moreover, the collected historical data can also be analysed to recommend appropriate Jabber servers for users.</p>

<p>The primary objective of this project is to develop a GUI dashboard for the Kea DHCP server software to function as a remote monitoring and management console. This frontend web application integrates essential features from the Kea Control Agent (CA) REST API, delivering to users a mechanism for monitoring and configuring the states of remote DHCP servers.</p> <p>Server Monitoring and Management features:</p> <ul> <li>Interface with DHCPv4 and DHCPv6 servers and switch b/w server machines (CA Address)</li> <li>View server status, subnet and shared network layout with real-time utilization stats.</li> <li>Device OUI and lease statistics.</li> <li>Control server operation with local boot ops (start/stop/restart)</li> <li>Utilization threshold alerts and event reports.</li> <li>Examine server logs in real-time (local server).</li> <li>View and modify server config with change testing and updating options.</li> <li>Modify specific server params for network entities (subnet, shared n/w, host res) through editable forms.</li> </ul>

<p>Add stream and mood API to loklak server and build mood heatmap web app on it's top.</p>