Explore Projects

KubeVirt extends Kubernetes with virtual machine (VM) APIs, virt-api is the component that serves these APIs to the cluster. Historically, the virt-api component has relied on a custom HTTP server implementation to manually handle TLS, authentication (Authn), authorization (Authz), API discovery, and OpenAPI serving. This VEP proposes migrating virt-api to the k8s.io/apiserver library to leverage the standard Kubernetes API server infrastructure. Adopting this upstream standard will significantly reduce maintenance overhead and enable seamless security updates for the system.

I would like to be a part of drupal.org in GSOC. The project Decoupled menus for Drupal. Which is the concept of making Drupal combined with New technology react. The two use cases which were used in the description were much interested. I was learning with the react over the past 10 months. So I would like to solve the problem in a good manner like combining the react with PHP or Python. So, First of all, they asked us to build a menu section that should be globally active around the other pages. This can be done by the react components. Which I had the idea of doing it. In the second use case, they asked to create a menu(s) that changes from page to page like the "Content Moderator Shortcuts" menu to the "moderator" role. Which we can implement with React router dom. But the main task of this objective is to combine the react with drupal. While we know Drupal still serves as a backend repository, front-end frameworks can talk to the database via API calls. By making the Make a stand-alone front-end and using drupal to create APIs which interact with the database. Then consume the API through HTTP AJAX or whatever mechanism React Js contains. Yeah, while coming to symphony it's been a task for me to learn it for using it as a framework. I have already had a little experience with the laravel framework. I am keen interested and fully fledge to be a part of this project.

<p>Since OODT consists of different components like file manager, resource manager and work flow manager, all those components have their own configuration files and locations. This is complex to manage and creates problems when the platform is distributed across servers or geographically. Therefore, the objective of this project is to migrate the OODT configuration to an optional zookeeper module so that the OODT components can register themselves in the zookeeper ensemble accordingly and maintain each component’s state regardless of the scale of the cluster. The proposed zookeeper module will minimize the manual configuration required when configuring OODT components. That is, this module will make use of the inherited configuration at component level. For example consider the file manager. Almost all the configurations of file manager instances are identical. Therefore, new file managers which are coming up later will inherit the configuration of the initial file managers and will almost remove the manual configuration required when adding new nodes to the cluster.</p>

<p>Bassa project is about making installation of Bassa easier for its users and containerizing in a better way to use available resources in efficient way.</p> <p>Bringing Minio into Bassa for proper file storage will be first task, later on currently written Bassa installation scripts will be updated by proper and efficient DockerFile for each Bassa components (minio storage, MySQL DB, (Bassa socket server + aria2c) ) which will be treated as Docker containers and then these Docker containers will run in pods as described briefly in proposal and these pods will be run as clusters in k8s environment</p> <p>Bassa socket server and aria2c together will work as single instance pod and will be auto scaled to attain good uptime and other components Minio and MySQL will be working on different pods, these pods will interact with each other and transfer files to minio buckets created by user.</p>

The objective of this project is to develop IDE plugins that can enhance the developer experience while working with Service Mesh Performance Performance Profiles. The proposed plugins will leverage technologies such as golang and cuelang to provide features such as syntax highlighting, auto-completion, validation, and rendering previews for Service Mesh Performance profile and model definitions. - Expected outcome: - 1. Release VS Code Extension - 2. Syntax Highlighting and Auto-completion: The plugin can fetch SMP Model definitions such as cloud-native components and their relationships. This information can be used to provide syntax highlighting and auto-completion for these definitions in the JSON files, making it easier for developers to write error-free code. - 3. Validation and Reference: For Meshery MeshModel definitions such as cloud-native components and their relationships, the plugin can use the CUE language to provide validation for the CUE input and preview the rendering result. The plugin can also fetch the SMP Model schemas and display them in the IDE for reference.

The Problem When developers write custom webpack plugins, they need reliable API documentation. Currently, the generated docs drop critical function signatures, returning unhelpful {object} types instead of actual parameters. The new documentation infrastructure is also missing webpack's visual identity, essential navigation pages, and a safe review process for automated updates. The Solution I will complete the TypeDoc to doc-kit pipeline to finalize webpack's API documentation redesign. First, I will fix the AST renderers to properly map TypeScript function overloads so no signature data is lost. Then, I will configure the doc-kit UI with webpack brand tokens and build custom React components to cleanly display complex hooks. Finally, I will secure the CI/CD workflow and port the core website pages. Deliverables: Accurate API Output: A fixed TypeDoc theme that correctly renders function parameters and TypeScript overloads. Visual Identity: A custom doc-kit configuration with webpack branding and new React components (HookSignature, PluginInterface, DeprecationBanner). Automated CI/CD: A GitHub Actions workflow that safely opens pull requests for new docs instead of pushing directly. Core Navigation: Fully ported Home, Download, Guides, and About pages.

<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>

<p>Clinical Data Management is a child project under Modernizing Administrative functions for OpenMRS. The project focuses on porting administrative functions for managing clinical data within OpenMRS to OpenMRS 3.0: A Frontend Framework.</p> <p>As frontend technologies have evolved quickly over the past 5 years, many sites have started making their own front ends for the platform, Thereby, OpenMRS is moving from legacy server-rendered pages to React using Carbon Design within a micro frontend framework.</p> <p>I have proposed how I will be working and what design principles and carbon design components I will be using during my summer and what contributions I have made in the past. Alongside, I have attached a draft timeline for the summer contribution and how I will execute my project and all the necessary coordination required during my work.</p>

This project makes the ENTS (DirtViz) dashboard easier to grow with real field use. A lot of the UI is still wired together by hand in React, which gets painful when new sensors show up or when people want different views of the same data. The plan is to expose what can actually be plotted using live database information, mainly from the sensor table, so the app lists available sensor names, measurements, and units per cell instead of maintaining long static lists in the frontend. Power and TEROS data may still live on older storage paths for a while, so the catalog will need a clear, documented way to bridge those sources until everything lines up on one model. The headline user feature is a drag and drop dashboard: reorder panels, add or remove them, and keep layout in the URL so someone can share a view with a link. Saving layouts on the server can come later, once the client side layout behavior is solid and easy to reason about. For people comparing multiple cells, the work should also make loads feel snappier by avoiding strictly one after another requests where batching or parallel loads make sense, and by ignoring out of date responses when the selection or date range changes mid flight. After that foundation, there is room for equations for derived metrics with tight server side validation, plus CSV export of what is already on screen. Fancy per panel styling is a lower priority and might stay minimal. Overall this is steady refactoring of the existing Flask and React stack, not a from scratch rewrite, so current APIs stay stable unless an extension is clearly worth it.

Meshery UI lacks a permissions framework. The existing internal implementation is simple, fragile and must be completely rewritten. The approach to implemention a permmissions framework includes using React.js and CASL.js. Meshery UI's approach needs to be extensible given that this framework will be an extension point for Remote Providers to supply their own permissions. - Expected outcome: Definition of permissions and their enforcement in Meshery with an aim for deep granularity and extensibility with each user interface input component carrying a unique permission key id. Each key is then put into a group of keys in a keychain, keychains assigned to user roles, in turn, roles assigned to users. With users having the ability to create own custom roles, the framework will be dynamic based on the associated server-side permissions for the currently auth’ed user. - Upstream Issue (URL): https://github.com/meshery/meshery/issues/7436, https://github.com/meshery/meshery/issues/7382

This project implements a browser-native genomic feature search system for efficiently querying large GFF3 annotation datasets without requiring backend infrastructure. Traditional approaches either rely on slow client-side parsing or require server-side APIs, both of which introduce scalability and maintenance challenges. The proposed solution converts GFF3 files into an indexed SQLite database offline and performs full-text search queries directly in the browser using SQLite WASM within a Web Worker. The system integrates with JBrowse to enable seamless navigation from search results to genomic locations, providing a responsive and interactive user experience. To support large metagenomic datasets, the system will incorporate range-based loading and progressive data access strategies. The final outcome will include a production-ready indexing pipeline, a browser-based query engine, performance benchmarks, and a reusable React component that can be integrated across multiple EMBL-EBI web applications without requiring backend services.

As a final-year Software Engineering student at Kyiv Polytechnic Institute, I propose transforming Rucio WebUI into a more powerful, intuitive, and sustainable platform. Drawing from my previous contributions and technical expertise, I've developed a comprehensive strategy that addresses current limitations while setting the foundation for future growth. My plan focuses on migrating to modern technologies (Next.js 15, React 19, TailwindCSS 4.x), implementing server-side rendering for improved performance, enhancing the authentication system with NextAuth.js and RBAC, and fixing critical bugs like DID slash-handling issues and non-functional replicas loading. I'll also optimize performance through advanced streaming mechanisms for large data volumes, improve architecture with a transition to NX monorepo, enhance entity management functionalities, and implement comprehensive UI/UX refinements. With substantial experience in the Rucio WebUI codebase from my previous internship and 30+ contributions to the project, I've demonstrated my commitment and technical ability to execute this comprehensive modernization plan. My current work with Next.js and NX at a startup provides me with cutting-edge expertise that I can directly apply to enhance the project's development and implementation.

<p>Hyperledger Identus provides mature backend services (Cloud Agent, Mediator) and Edge Agent SDKs (TypeScript, Kotlin Multiplatform, Swift) for building Self-Sovereign Identity (SSI) solutions.</p><p><br></p><p>This mentorship project will deliver a&nbsp;lightweight, unified agent interface&nbsp;— primarily a web-based reference dashboard — that supports:</p><ul><li>Offline-first / non-custodial mode&nbsp;— powered entirely by the TypeScript Edge Agent SDK running in the browser, with CIP-30 Cardano wallet integration (via MeshSDK) for PRISM DID operations.</li><li>Connected / custodial mode&nbsp;— optional connection to an existing Cloud Agent instance via a configurable API endpoint.</li></ul><p>Core architectural principles</p><ul><li>Offline-first by default&nbsp;— If no&nbsp;<code style="background-color: rgba(129, 139, 152, 0.12);">CLOUD_AGENT_API_ENDPOINT</code>&nbsp;is provided, the application runs fully in the browser with no backend dependencies.</li><li>Maximal reusability&nbsp;— Core SSI logic is built as pure TypeScript modules / utilities that can be reused in other projects (web, React Native,, custom dApps, etc.).</li><li>Minimal vendor lock-in&nbsp;— No UI component kits (e.g., no shadcn/ui); use plain Tailwind CSS + simple, custom, portable components.</li><li>Stable &amp; compatible stack&nbsp;— Target React 18 (latest stable non-experimental version) to maximize future compatibility with projects.</li><li>Modular structure&nbsp;— Separate concerns: pure SSI logic → service adapters (Edge vs Cloud) → presentation layer.</li></ul><h3>Learning Objectives</h3><ul><li>Deep understanding of SSI concepts: Decentralized Identifiers (DIDs – especially PRISM method), Verifiable Credentials (JWT, SD-JWT, AnonCreds), schemas, revocation, DIDComm messaging, trust frameworks, issuer/holder/verifier roles</li><li>Hands-on experience with the Hyperledger Identus ecosystem: Cloud Agent REST APIs, TypeScript Edge Agent SDK, Mediator coordination, PRISM DID resolution &amp; publishing to Cardano, Verifiable Data Registry</li><li>Building reusable, framework-agnostic TypeScript code for SSI workflows</li><li>Implementing a unified UI system for both the Cloud Agent and the Edge Agent (offline first)</li><li>Practice open-source development workflows, including code review, documentation, community engagement, and incremental delivery</li></ul><p><br></p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/77" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/77</a></p>

Overcome current architectural issues of: 1) No Caching - In Meshery UI, List of adapters is a state that is being used in multiple components i.e Settings , Dashboard , Connection Wizard and Performance. Refetching the data on every mount of each of these components degrades the user experience. The same goes for all the other data that are being used across multiple components. 2) Multiple Sources of Truth - There is no single source of truth in Meshery UI as all react components manage their own state. Since Meshery UI has to deal with data that frequently changes, like Control Plane Data, Meshsync data etc. it will become hard to keep them in sync if they all manage their own copy of them in their local state.

SLIPS is a Machine Learning based intrusion detection system, which scans network traffic and processes the data using a variety of techniques, both machine learning based as well as heuristic based. Despite having many different features and techniques to detect malicious behaviors on a target network, there will always be a problem of processing so much network traffic data quickly and efficiently, both in regards to the CPU and memory usage. However, there is currently no way to gather data about CPU and memory usage during execution time, which makes it difficult to make further performance improvements to the project. Therefore, this project seeks to remedy this by creating a set of tools to gather performance data about the IDS execution behavior. To improve performance data gathering capabilities, the following features will be added to the project: - CPU profiling module - Memory profiling module - Both modules will allow for: Export of profile data, output as both absolute and difference from input profile baseline (if provided), output as data stream - CPU/Memory data visualization/analysis module which can: Show process resource usage over time, can restrict to top however many if desired, histogram of resource consumption and time spent at consumption level for a single module, and recommendation lists for modules needing optimization, scoring criteria based on highest memory/CPU usage, longest blocking time, and weighted aggregate score.

<p><strong>Security event auditing</strong> permits the selective and fine-grained configurable logging of security-relevant system events for the purpose of post-mortem analysis, intrusion detection, and run-time monitoring and is intended to meet the requirements of the <strong>Common Criteria(CC)/Common Access protection profile(CAPP) evaluation</strong>. The audit subsystem in FreeBSD, <em>audit(4)</em>, can record a variety of system events like user-logins, file system activities, network activities, process creations, etc.</p> <p>The <em>auditd(8)</em> on the server doesn’t generate any record trails for the NFS activities as the audit works mostly on the syscall level and the NFS server is implemented within the kernel.</p> <p>To audit NFS activities within the network, it will require to run the <em>auditd(8)</em> on each NFS client. This arrangement works perfectly fine in case of secure networks. But In the case of an insecure network, running <em>auditd(8)</em> on each client is not an option. The <em>audit(4)</em> support to the NFS server is a missing feature for such networks. Thus, the aim of this project is to <strong>audit each NFS RPC</strong>. This would allow audit of all NFS activities within the network by just running <em>auditd(8)</em> on the server.</p>

<p>I intend to work on the scrapy benchmarking suite project. I would like to create benchmarks that reflect real-life cases as well as component-specific micro benchmarks.<code>--profile</code> uses cProfile for profiling and the feature is currently undocumented. I intend to investigate other profilers to be used with scrapy and try to improve the performance of the spiders based on the results.</p>

<p><strong>*APPLICATIONS ONLY OPEN TO STUDENTS LOCATED IN CHINA*</strong></p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>SONiC supports serial console management using console switch functions, enabling it to act as a terminal server and control devices through the serial console. Diagnosing issues with the serial console can be challenging because the connection is exclusive, so only the user on that line knows what’s happening. For Ethernet, SONiC users can leverage the Everflow feature to mirror data plane traffic or use tcpdump to monitor control plane traffic. In the context of serial consoles, however, a new feature is needed to mirror serial console traffic, which would greatly assist with diagnosing console problems.</p><p><br></p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><p>The goal of this project is to create and implement a new SONiC feature that lets users start or stop recording for a specific console line whenever needed.</p><p>Key features include:</p><ul><li>Designing a file format to store the serial console data stream, with configurable time resolution.</li><li>Mirroring incoming (RX) data streams to a local file.</li><li>Mirroring outgoing (TX) data streams to a local file.</li><li>Adding CLI support to start or stop recording for any serial console line.</li><li>Additional desired features are:</li><li>Mirroring the CTS flow control signal to a local file.</li><li>Mirroring the RTS flow control signal to a local file.</li><li>Providing encryption for recordings.</li><li>Implementing gNOI APIs to enable start/stop recording for specific serial console lines.</li><li>The feature will be implemented in Python based on existing serial console infrastructure which allows developer to manipulate serial console data stream.</li></ul><p><br></p><p><strong>Expected Outcomes and Deliverables</strong></p><p><br></p><ul><li>HLD document for console mirroring feature</li><li>Implementation details of console mirroring</li><li>Test plan for console mirroring</li><li>Test cases for console mirroring</li></ul><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li>Familiarity with a common programming language (Python, Java, C, C++, Rust, etc.)</li><li>Basic Linux knowledge</li><li>Basic SONiC knowledge (preferred)</li><li>AI or vibe coding experience (preferred)</li></ul>

This project aims to integrate bytetrack algorithm into a Mediapipe graph using OpenVINO inference calculators. The bytetrack graph will be deployed on OpenVINO model server to perform efficient object tracking on a video input. The deliverables of this project include a bytetrack graph in OpenVINO mediapipe fork with custom calculators, YOLOv10 model and bytetrack graph packaged in OpenVINO model server, and a Python client for the bytetrack graph to perform bytetrack algorithm on video stream. The final phase of this project includes evaluation of bytetrack on metrics MOTA, IDF1, and HOTA. The goal of this project is to bring the bytetrack algorithm to OpenVINO model server to leverage its efficiency, scalability, and robustness for production-grade inference.

This project focuses on modernizing the Jaeger-UI by upgrading its foundational routing and state management libraries. The primary goals are to migrate from legacy react-router patterns to React Router v7 and replace the deprecated history package and older Redux integration patterns with modern standards like redux-first-history. This refactoring will improve long-term maintainability, enhance performance, and simplify the code for one of the industry's most critical observability tools. Expected Outcome: A fully migrated Jaeger-UI running on React Router v7, removal of deprecated history v4/v5 dependencies, refactored functional components using modern hooks (useNavigate, useParams), and a robust test suite ensuring no regressions in trace visualization or search functionality.

Mailu is a simple yet full-featured mail server as a set of Docker images. It is free software (both as in free beer and as in free speech), open to suggestions and external contributions. The project aims at providing people with an easily setup, easily maintained and full-featured mail server while not shipping proprietary software nor unrelated features often found in popular groupware. Main features include: - Standard email server, IMAP and IMAP+, SMTP and Submission - Advanced email features, aliases, domain aliases, custom routing - Web access, multiple Webmails and administration interface - User features, aliases, auto-reply, auto-forward, fetched accounts - Admin features, global admins, announcements, per-domain delegation, quotas - Security, enforced TLS, Letsencrypt!, outgoing DKIM, anti-virus scanner - Antispam, auto-learn, greylisting, DMARC and SPF - Freedom, all FOSS components, no tracker included

ChromeStatus.com is a website that allows web developers to track all the features in the Chrome browser, including the deprecated, current, and upcoming features. It also provides editing pages and guidelines for feature developers to enter and view the process of their features. The app currently has a traditional multi-page application design in which each URL corresponds to a HTML file, and almost every click in the site triggers a loading of the new page. The goal of this project is to upgrade the website into a single-page application for better user experience. This requires the use of web components for client-side rendering and state management. All the current HTML templates would be converted into the Lit components and managed by a new top-level component, which would also have a router to manage the routing of the whole app. In addition, parts of the server code that return HTML elements upon API requests would have to be redesigned. This project will make the codebase of the app much more maintainable and scalable, and allow for a more fluent user experience on ChromeStatus.com.

Submitty's frontend relies on server-rendered Twig templates and jQuery for interactivity, leading to fragmented, hard-to-maintain interfaces. This project migrates Submitty's most critical pages - the TA grading interface, discussion forum, office hours queue, and rainbow grades customization to modular, reusable Vue.js components backed by clean PHP JSON APIs and centralized Pinia state management. The migration follows a progressive enhancement strategy using the Mount Container Pattern, allowing Vue components to coexist with legacy code at every stage, ensuring zero disruption to active users mid-semester. Deliverables include a reusable Vue component library, full reactive migration of the discussion forum and TA grading interface, a Pinia and Axios powered state and API layer, comprehensive unit and E2E tests, and a developer migration guide for future contributors. A proof of concept PR migrating the TA grading score box to Vue.js has already been submitted, validating the end-to-end approach before the program begins.