Explore Projects

The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. This program pairs one mentee with an experienced mentor to deliver a V8 JavaScript engine port for a 32-bit RISC-V core. The V8 JavaScript engine for RISCV64G has been upstreamed to Chromium recently. As a basic component for the Chromium web browser and node.js, it would enlarge RISCV’s application scenario. Although RV32G V8 port would be quite similar to RV64G V8 port , it is still in the TODO list. Porting and enable the RV32G on V8 will bring the embedded RISCV software ecosystem more applications, make RISC-V embed processors more competitive. Deliverables (bullet list of components and the changes expected): - Turbofan backend implementation - Embedded simulator implementation - Corresponding unit tests implementation - Regression tests pass Acceptance criteria (bullet list with measurable results defined): - RV32G cross-compiled and simulator build on both debug and release configuration should be passed - A helloworld demo should run successfully on both the embedded simulator and a real or emulated hardware (i.e. a real board or QEMU emulation). - 97% of the regression test should pass

<h5>End-to-End Testing Support</h5> <p>Oppia Android's current testing corpus includes unit tests using the Robolectric testing framework &amp; integration tests using the Espresso testing framework (to ensure that the app operates as expected in a real Android environment). The current tests have a few limitations: they do not correctly facilitate cross-activity navigation flows which actual users will be triggering, and they do not verify that the app can interact with Oppia's backend correctly.</p> <p>To prepare for the global launch of the app, we need end-to-end tests that:</p> <ul> <li>Verify that the app works as a user would expect by playing through select critical user journeys</li> <li>Verify that the app operates as expected when interacting with a local developer instance of the Oppia backend server</li> </ul> <p>We expect that the tests will be written using UiAutomator &amp; are set up for interacting with a local development server (see <a href="https://developer.android.com/studio/run/emulator-networking.html" target="_blank">relevant documentation</a>).</p> <p>Note that this project requires running Linux with virtualization support (in order to run an Android emulator). You will need to make sure your computer supports <a href="https://help.ubuntu.com/community/KVM/Installation" target="_blank">KVM</a> and is running Linux.</p>

Seeking an escape from daily life chores, many turn to travel as a means of relaxation, renewal, and exploration. However, planning a trip can be overwhelming especially with the abundance of information available online that involves navigating multiple websites, guidebooks and apps to research. Furthermore, discovering the most touristic places in a foreign city or country, along with the best dining spots, shopping locales, and natural vistas, can be a daunting task. The main purpose of this application is to simplify the travel planning experience and inspire users to embark on memorable journeys and discover the most captivating point of interests (POIs) tailored to their preferences. The POIs would be generated by running GEMMA, one of the latest open-source generative text AI models, locally on the AI server in Lleida Lab utilizing Docker technology. Utilizing the liquid galaxy technology, the user would be able to visualize their entire trip on the LG rig with 3 or more screens where the tours along with their info would be sent through KML (keyhole markup language) that will help build beautiful and unique visualizations on the LG rig. In case of unavailability of an LG rig, the user would still have a captivating experience through the app and the integrated google maps. Deliverables - The model trained on the cloud and ready to be inferred in Lleida Lab AI local server. - The new App published on the Play Store under the Liquid Galaxy LAB account. - Full documentation and code on Liquid galaxy lab GitHub.

The Mission Support System (MSS) client currently lacks the ability to save and restore view configurations, requiring users to manually recreate complex window layouts each time they reopen the application. Additionally, collaborative operations do not support sharing view configurations among participants, hindering real-time coordination. To enhance the user experience and collaboration in the Mission Support System (MSS), this project will introduce two major improvements. First, it will implement a local and server-side view restoration system, allowing users to save and reload their window layouts automatically. This will be achieved through JSON-based storage for local configurations and database integration for server-side persistence. Users will have the option to enable or disable view restoration via a new setting, ensuring flexibility. Second, the project will introduce a collaborative view-sharing feature through a dedicated "Manage View" widget. This will enable participants in an operation to share, browse, and load predefined layouts, ensuring consistency during joint missions. The widget will integrate with MSS’s existing operation system, allowing real-time updates via WebSocket notifications. Backend APIs will handle secure storage and retrieval of shared views, while the frontend will provide an intuitive interface for managing layouts. Together, these enhancements will eliminate the need for manual reconfiguration and streamline teamwork in mission planning and analysis.

<p>Krkn-AI's [discover command](https://krkn-chaos.dev/docs/krkn_ai/discover/) connects to a Kubernetes/OpenShift cluster and generates a static configuration file by enumerating cluster components (namespaces, pods, services, PVCs, nodes). While useful, the generated config still requires significant manual work before it can actually be used. Health check URLs are commented-out placeholders, the fitness function defaults to a single hardcoded PromQL query, and scenario selection is static regardless of what exists in the cluster. This issue proposes enhancing discover to produce a dynamic, cluster-aware configuration that is closer to runnable out-of-the-box. By inspecting routes, ingresses, services, and available Prometheus metrics during discovery, we can auto-populate health check URLs, suggest relevant fitness function queries scoped to discovered namespaces, and intelligently enable only the scenarios that apply to the discovered infrastructure.</p><p><br></p><p>Expected Outcome:&nbsp;</p><p>&nbsp;- Auto-discover OpenShift Routes, Kubernetes Ingresses, and Services to populate health check URLs in the generated configuration.</p><p>&nbsp;- Query Prometheus for available metrics to suggest namespace-scoped fitness function queries instead of hardcoded defaults.</p><p>&nbsp;- Intelligently enable chaos scenarios based on discovered cluster components (e.g., PVC, VMI, network interfaces).</p><p><br></p>

This project aims to introduce a scalable and maintainable internationalization (i18n) system for applications built using MIT App Inventor. Currently, App Inventor does not provide a structured approach for handling multi-language support, making it difficult for developers to create globally accessible apps. The proposed solution introduces a key-based translation system that decouples user-visible text from UI components. The system integrates across multiple layers of App Inventor, including the Designer, Blockly, runtime, and build system, enabling automatic translation handling in generated applications. Key features include: - Automatic detection of user-visible text from component properties and Blockly blocks - A centralized translation editor for managing multi-language content - Context-based key generation to ensure stability and avoid ambiguity - Runtime translation using JSON for flexibility during development (Companion) - Build-time generation of native Android/iOS resources for efficient production builds The system is designed to be fully backward compatible and supports progressive adoption, allowing existing projects to continue working while enabling developers to gradually migrate to the new translation model. Deliverables include: - A working runtime translation system for App Inventor apps - Integration with Blockly for key-based text handling - Designer-level synchronization and key management - Build-time resource generation for native localization - End-to-end tested implementation with documentation

The Programs & Events Dashboard tracks editing activity across thousands of Wikimedia programs, but generating a system-wide picture of that impact remains manual and resource-intensive. WMF staff must stitch together per-campaign exports to answer basic questions like "How many total edits have all programs produced this year?" — there is no single place to see the Dashboard's global impact. This project builds that infrastructure in three layers. First, a SystemStat model and SystemStatUpdateWorker (Sidekiq) that computes and caches daily snapshots of global metrics - total edits, pageviews, articles improved, new and retained editors, and per-wiki breakdowns, so that all aggregations are pre-computed and never run on-demand against the full dataset. Second, an asynchronous system-wide CSV export pipeline that allows admins to request a download of all non-private program data, generated in the background and delivered via notification when ready - handling the full data scale without memory exhaustion. Third, a React-based "System Stats" admin dashboard that visualizes global trends, wiki distributions, and editor retention over time, backed by a JSON API endpoint for direct consumption by the WMF Community Data and Evaluation team. Deliverables: SystemStat model + daily background worker; admin-only async CSV export pipeline; "System Stats" React dashboard with trend charts and retention metrics; public JSON API with date-range filtering; full RSpec/Jest test coverage; and end-user documentation for WMF staff.

Project Deliverables • Admin Section : Implement an admin dashboard to manage users, projects, and datasets. Add moderation tools for handling flagged content and project approvals. Implement role-based access control (RBAC) for better user management. • Forking Datasets/Projects : Enable users to fork existing projects and datasets, creating editable copies. Implement versioning & attribution tracking for forked projects. Ensure that forked projects maintain links to original versions. Provide users with a UI to track changes between original and forked projects. • Following/Joining Projects : Allow users to follow projects for updates and notifications. Implement a Join Project feature requiring owner approval for collaborations. • Project Dashboard Improvements : Improve UI/UX for easier navigation and better data organization. Add interactive components for better visualization of project statistics. Enable filtering and sorting options for users to manage multiple projects efficiently. • Notebook Management Enhancements : Enhance notebook versioning, metadata, and organization. Improve JupyterLite integration for a smoother editing experience. Implement a notebook history tracker, allowing users to revert to previous versions. • Publication List Enhancements : Improve publication listing, filtering, and categorization. Enable direct linking to project-related publications. • Versioning & Querying Enhancements : Implement dataset version control for reproducibility. Improve querying components to facilitate advanced data filtering. Enable users to compare different versions of datasets using a visual diff tool.

RIPE Atlas publishes traceroute measurement results. A measurement result can have a large volume of data. One example of a large volume measurement is as mentioned below: "Given around 12000 probes worldwide and the system collects traceroute data from these probes every 15 mins. The measurement has been running for 2+ years. The maximum hops a probe made in this measurement was 32." RIPE Atlas provides a REST API to fetch the measurement result. However, the measurement result object can be a large json response. It increases the memory usage on the server while creating a huge response. If the server succeeds in creating a huge response, the client device may not afford to render an SVG graph given the large traceroute data. The main goal for this project is to enable the visualizer to handle traceroute measurement results of any volume. This can mainly be achieved by - Narrowing down the search according to the inputs (probe ids to include, time frame) provided by the user - Paginate the measurement result API call by probe ids, start time and stop time Experiment rendering the network graph using more efficient graph libraries and test. If by testing, the results are improved then replace the current implementation of v-network-graph. Also, there is a scope for UI enhancements. The main thought process behind thinking UI enhancement for this project was this: "The data which we can provide should simply be there on the graph when the user needs it. This UI enhancement can be achieved by adding another “Detailed mode” to the network graph." During the GSoC timeline, I will be executing testing strategies, fixing the underlying issues of the traceroute visualizer and documenting my work.

Libraries worldwide face challenges in adopting digital lending due to restrictive licenses and costly, vendor-locked systems that limit independence. Lenny is an open-source, self-hosted lending system inspired by the Internet Archive and Koha. Its mission is to give libraries ownership of their digital collections while offering a flexible and cost-effective alternative to proprietary platforms. At its core, Lenny based on python features a FastAPI backend that handles borrowing, returning, and waitlists, with support for Readable, Borrowable, and Print-Disabled books. Security and compliance are provided through LCP DRM and Geo-IP restrictions, while PostgreSQL triggers automate loan expirations. An OPDS feed enables integration with Open Library, Thorium, and other reading systems. Deployment is simple with Docker (Alpine + Nginx), and a React dashboard allows librarians to set lending rules like loan durations and waitlists. To improve accessibility, the companion Lenny-app (TurboRepo monorepo) includes: 1. A sandbox demo preloaded with 500+ e-books to showcase the system in action powered by Lenny. 2. A documentation site that supports integration, open-source contributions, and extensions. Built with TypeScript, React, Next.js, Node.js, and Express.js, Lenny-app is production-ready yet flexible for experimentation. Together, Lenny + Lenny-app deliver both the backend infrastructure and the user interface needed to power community-driven digital lending. By combining secure architecture, a ready-to-use demo, and developer-focused documentation, Lenny provides libraries with a scalable and future-proof solution to manage digital lending independently and expand access for their patrons.

The torchvision package in the mlverse ecosystem provides essential tools for computer vision workflows in R, including datasets, transformations, and model utilities. While the ecosystem has matured significantly, a key limitation remains in the performance of certain core operations, particularly in detection pipelines. Functions such as Non-Maximum Suppression, bounding box transformations, and proposal filtering are currently implemented at the R level, which introduces inefficiencies when working with larger inputs or real-time use cases. This project aims to address that gap by moving performance-critical components into a native C++ backend using torchvisionlib. The approach will focus on identifying the parts of the pipeline that are actual bottlenecks, implementing them in C++ with careful attention to memory usage and batching, and integrating them back into torchvision without changing the user-facing API. Rather than rewriting everything, the work will prioritise targeted optimisations that have a measurable impact on end-to-end performance. In addition to backend improvements, the project will include the implementation of at least one modern computer vision model family, such as YOLO, using the optimised components. If time permits, support for an additional model (e.g., RT-DETR) will also be explored. These models will be integrated into the existing ecosystem with consistent APIs and working examples. The main deliverables of this project are: a set of optimised C++ implementations for core detection operations, their seamless integration into torchvision, at least one fully functional model pipeline built on top of this backend, and supporting documentation and benchmarks demonstrating performance improvements. The goal is to make torchvision not just feature-complete, but efficient enough for practical, large-scale use.

Dynamic Resource Allocation (DRA) is a new feature introduced in Kubernetes version 1.26 and above, providing an Alpha API that allows users to define Kubernetes objects similar to the Persistent Volumes API for generic resources. With DRA, users can separate the declaration of a resource to be consumed from its actual consumption. This move away from the limited "countable" API provided by device plugins allows for a more flexible control over which resources are consumed and where they are allocated. For handling host devices, KubeVirt relies on the Kubernetes device plugin framework, which is crucial for scheduling, allocating, and attaching desired devices and resources to running pods. One limitation of this framework is the lack of persistence in device allocation when the pod is not running. The proposed solution involves implementing the DRA plugin in KubeVirt for PCI passthrough (with Nvme devices as a Proof of Concept). A DRA driver typically consists of two separate but coordinating components: a centralized controller and a node-local kubelet plugin. The kube-scheduler communicates with the centralized controller, which makes allocation decisions based on the overall cluster state and resource availability. The kubelet-plugins are responsible for discovering and advertising the node's available resources to the kubelet. Additionally, the proposed approach suggests enhancing the VirtualMachineInstance (VMI) resource to include resourceClaims under hostDevices. This way, users can create a VMI resource that references a ResourceClaim (Template) which in turn references a registered ResourceClass. KubeVirt components need to be modified to translate the resource claims in the VMI host devices into the PodSpec of the underlying Pod. Finally, the device driver would be deployed along with virt-handler as part of a DaemonSet. In summary, this approach aims to leverage the DRA capabilities to enhance host devices allocation

Apache Airavata MFT is a distributed high-performance, multi-protocol data transfer engine to orchestrate data movement and operations across most cloud and on-premises storages. Agent is the core of this distributed system which does the heavy lifting of transfer jobs. Right now, agents have to be manually deploy and configure to start the transfer. This is a problem for researchers and people who need to transfer data without having much technical skills or time. Updated Proposal Summary: Updated proposal includes creating a desktop application and cybershuttle server to orchestrate the lifecycle management. This will guide cybershuttle agent and MFT agent from cybershuttle server to perform execution of jobs and data transfer, this would also maintain the lifecycle of cybershuttle agent and mft agents. This would help deploy any software and not limited to MFT agents. The proposed solution is to automate the process of deploying and lifecycle management of the agents when a transfer job is submitted from an edge machine. This will help various researchers and people who needs to transfer data from a source to a destination without having much technical skills or time. The deliverables are a piece of code to deploy the agent on various virtual machines, a piece of code to maintain the agent's lifecycle, an automated process for deployment and management, onboarding users and evaluating edge cases, and automated agent placement. The benefits of the proposed solution are that it will make it easy and on the go solution for people even with less technical ability to use the vast speeds and advantages MFT offers. It will save time and effort for researchers and people who need to transfer data from a source to destination. It will make the MFT more user-friendly and accessible to a wider range of people. It not just stops at MFT, in fact users can deploy any containerizable applications using this solution.

High-fidelity detector simulations are critical for accurate analysis in particle physics, but traditional Monte Carlo-based methods are computationally expensive. DeepFalcon introduced a promising approach using Graph Variational Autoencoders (GVAE) that treat particle hits as graph nodes, enabling faster inference while maintaining high accuracy. This implementation used CMS Open Data of boosted top quark jets and considered only the ECAL layer of the detector, achieving a 400× speedup in reconstructing jets compared to traditional simulations. The model architecture employed GraphSAGE layers and mincut pooling, while training used Adam optimizer with a hybrid loss function combining MSE and KL divergence. However, the current approach is limited to single-layer detector responses and doesn't fully capture the correlations between multiple detector components. This project aims to extend DeepFalcon’s GVAE architecture to support multi-layer detector systems, specifically incorporating Tracker, ECAL, and HCAL layers simultaneously. The proposal is structured into two phases: Phase I will focus on enhancing the graph data representation by including all three detector layers and designing optimized connectivity patterns that capture spatial and inter-layer dependencies. Phase II will explore advanced pooling techniques and alternative message-passing strategies to improve latent representation quality and model generalization, while maintaining fast inference speeds. All components will be implemented using Python and relevant machine learning libraries such as PyTorch Geometric. Expected deliverables include a multi-layer GVAE model, benchmark comparisons against existing results, and detailed analysis of the architectural choices. This project contributes toward advancing fast simulation techniques in high-energy physics by enabling more comprehensive and scalable detector modeling.

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

PostgreSQL introduced Server API and ABI Stability Guidance to help extension authors understand compatibility expectations. The policy ensures ABI stability between minor releases (e.g., 17.0 to 17.1) but allows changes in major versions. Currently, committers rely on manual reviews to enforce this, which occasionally leads to unintended ABI changes. A recent example occurred in PostgreSQL 17.1, where an ABI-breaking change was shipped and later reversed in 17.2. This incident highlights the need for an automated process to catch such issues before release. To enforce ABI stability, this project will monitor PostgreSQL’s repository across STABLE branches, detecting any ABI breakage early. Since ABI changes depend on system architecture, OS, and compiler, the tool will be developed as an extension to PostgreSQL Build Farm, leveraging its infrastructure to handle diverse configurations. Git receive hooks are unsuitable as PostgreSQL does not allow them due to repository performance concerns. As the frequency of commits on the PostgreSQL stable branches is very low, build farm’s cron based clients (animals) can simply compare the latest commit build(which it already does) with the latest release tag or the most recent minor release to get the ABI breakage, if any. The Libabigail suite (abidw, abidiff) will be used for ABI compliance checks, currently supporting GCC and Clang, with future expansion planned for other compilers. The system will generate ABI compliance reports on every run and will send to the build farm server and notify the community about breaking changes. This project will include the development of a Build Farm Client Perl Module that generates ABI compliance reports and report any ABI Breaks to the community. This project will strengthen PostgreSQL’s ABI stability process, preventing unintended breakages and ensuring smoother minor releases.

Problem: VLC’s macOS interface has fallen behind modern design standards, creating a disjointed experience compared to its intuitive iOS/tvOS counterparts. The current AppKit-based UI lacks macOS Sequoia's visual polish, struggles with libvlc’s newer playback features (e.g., frame-accurate seeking), and suffers from inefficient media library management. This outdated design hinders usability and fails to make use of macOS’s native capabilities. Solution: Redesign VLC’s macOS interface using AppKit to implement a pre-approved, user-tested design that integrates into macOS visual aesthetics and libvlc’s advanced APIs. The overhaul will: 1. Replace legacy Carbon-era UI components with modern NSCollectionView and NSSplitViewController layouts. 2. Integrate libvlc’s latest playback controls (frame stepping, HDR metadata) into native transport UIs. 3. Rebuild the media library using Core Data for performance and NSDiffableDataSource for real-time updates. 4. Prioritize system consistency with SF Symbols, vibrant materials, and macOS accessibility standards. Deliverables: 1. Modern UI Components: - Unified toolbar with adaptive controls (NSToolbarItemGroup) - Redesigned media library with thumbnail grid (NSCollectionView) and smart filters (NSPredicateEditor) 2. Enhanced Playback: - Frame-accurate seekbar with NSSlider tick marks synced to libvlc’s next_frame() API - HDR tone mapping toggle using CAMetalLayer integration 3. Optimized Media Management: - Rules-based playlists backed by Core Data - Spotlight-like search using NSFetchRequest 4. Developer Documentation: - Migration guide for plugin developers - NSAccessibility implementation notes By collaborating closely with VLC’s core team and iterating on the existing codebase, this project will deliver a performant, native macOS experience that bridges the gap between VLC’s powerful engine and modern user expectations.

<p>OpenEverest is an open-source cloud-native database platform that helps developers deploy and manage PostgreSQL, MySQL, MongoDB, and other databases on Kubernetes. In V2 it uses a plugin architecture where database providers define their UI through declarative YAML schemas (UISchema in Provider CRD). Currently, plugin developers have no integrated tool for developing and testing these schemas — the only way to see the rendered result is to deploy a full Provider CRD into a running Kubernetes cluster, making the development cycle slow and error-prone. This project aims to build a Plugin Developer Playground — a page inside OpenEverest where plugin developers can write UISchema YAML, see the rendered form in real time, validate the schema structure, inspect the post-processed API payload, and save/share schemas, all without deploying to a cluster. The mentee must solve the CSP compatibility problem by either choosing a CSP-compliant code editor or proposing an isolation architecture (e.g., sandboxed iframe) that keeps the main application's strict security posture intact.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Split-pane YAML editor with syntax highlighting and live form preview using the existing `UIGenerator` component</li><li>Real-time schema validation: YAML parsing errors and structural validation against the `TopologyUISchemas` type, with inline error markers in the editor</li><li>Live form rendering with stepper navigation through schema sections and topology switching</li><li>Dynamic field support: existing API provider fields load real data from the running OpenEverest instance; new/unknown provider types can be mocked</li><li>Output panel displaying the JSON payload after form data post-processing</li><li>CSP-compliant solution</li><li>Unit tests for core logic (schema validation, persistence, mock data injection) and component tests for key panels</li><li>Plugin developer guide for using the playground and the UISchema format</li></ul>

<p>Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers. It currently handles authentication and coarse-grained authorization via AuthPolicy/Authorino, but has no built-in mechanism for tool-level authorization, e.g., allowing agent A to call `add` and `subtract` on a math server while agent B can only call `subtract`. The kube-agentic-networking SIG is defining a standard AccessPolicy CRD for exactly this. MCP Gateway is well-positioned to implement it because its ext_proc already parses MCP request bodies and exposes tool metadata via headers (`x-mcp-method`, `x-mcp-toolname`, `x-mcp-servername`). This project will design how AccessPolicy maps to Kuadrant's AuthPolicy/Authorino, then build an experimental implementation covering CRD definition, a controller that translates tool-level authorization rules into Authorino configuration, identity model integration (starting with OIDC), `tools/list` response filtering so callers only see tools they're authorized to use, and CEL-based authorization expressions. The mentee will work closely with mentors on the design doc, pair on implementation decisions, and engage with both the Kuadrant and kube-agentic-networking communities.</p><p>- Expected Outcome:</p><p>&nbsp;- Design document covering AccessPolicy-to-AuthPolicy/Authorino mapping, body parsing strategy (ext_proc vs Envoy MCP filter), identity model choices, `tools/list` filtering, and CEL-based authorization</p><p>&nbsp;- AccessPolicy CRD with status conditions and CEL validation rules</p><p>&nbsp;- Controller that watches AccessPolicy resources and generates/updates AuthPolicy resources with authorization rules based on `x-mcp-toolname` headers</p><p>&nbsp;- OIDC identity source support, with consideration for ServiceAccount and SPIFFE identity types</p><p>&nbsp;- `tools/list` response filtering so callers only see tools they are authorized to invoke</p><p>&nbsp;- CEL-based authorization rule support (e.g., `request.mcp.tool_name.startsWith("read_")`)</p><p>&nbsp;- E2E tests covering allow/deny scenarios for tool-level access control</p><p>&nbsp;- Documentation guide in `docs/guides/`</p><p><br></p>

<p>Kuadrant's MCP Gateway uses an Envoy external processor (ext_proc) to parse MCP JSON-RPC requests, extract metadata, rewrite request bodies, and route tool calls to backend MCP servers. This works but adds latency via a gRPC hop per request and requires maintaining custom MCP protocol parsing logic. Envoy has been rapidly adding native MCP support, as of v1.38, the Envoy MCP filter can parse MCP messages, populate dynamic metadata for downstream RBAC/ext_authz filters, handle session management, support SSE and Streamable HTTP transport, and aggregate multiple backend MCP servers. A previous investigation rejected the Envoy MCP filter due to missing body modification support, limited method coverage, and no aggregation, but the filter has since evolved considerably. This project will perform a fresh evaluation, produce a design document mapping each ext_proc responsibility to native Envoy capabilities, identify gaps (particularly around request body rewriting for tool prefix stripping and dynamic metadata consumption by Authorino), build a proof-of-concept demonstrating the native filter approach, and propose an incremental migration path. The mentee will work closely with mentors on the design, validate assumptions through prototyping with standalone Envoy, and engage with both the Kuadrant and Envoy communities.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Design document covering capability mapping of each ext_proc responsibility to Envoy MCP filter features, body modification strategy, dynamic metadata vs header trade-offs for Authorino integration, federation/aggregation comparison, session management analysis, and Istio version dependency chain</p><p>&nbsp;- Proof-of-concept demonstrating Envoy MCP filter parsing requests and populating metadata, downstream authorization consuming that metadata, and tool routing to multiple backends</p><p>&nbsp;- Clear identification of what still requires custom code after migration</p><p>&nbsp;- Proposed target architecture and incremental migration plan</p><p>&nbsp;- E2E tests validating the prototype against existing test scenarios</p><p>&nbsp;- Documentation of Istio version requirements and feature gates needed</p><p><br></p>

<p>Hyperledger Fabric-X introduces a new architecture for Fabric, with decomposed services for ordering, endorsement, validation, and committing, but its current developer workflow is still centered around dedicated deployment scripts and Ansible-based setup.</p><p>Fablo, on the other hand, is widely used to start Hyperledger Fabric networks quickly from a single configuration file for local development, CI, and experimentation.</p><p>This project will explore and implement the best path to support a simple local Fabric-X network through the Fablo experience. We will evaluate architectural options such as a new engine, a separate repo, or an extension/wrapper approach, then build a minimal but practical MVP that can generate configuration, bootstrap the required components, and start/stop a working local Fabric-X network. The goal is to reduce setup friction for contributors and users, and provide a repeatable developer workflow, examples, and documentation that make Fabric-X easier to try, demo, and extend.</p><h3>Learning Objectives</h3><ul><li>Understand the architecture and deployment model of Hyperledger Fabric-X, including how it differs from classic Hyperledger Fabric.</li><li>Learn how to design contributor-facing tooling for distributed systems with evolving architecture.</li><li>Gain experience in open source development across CLI/tooling, configuration generation, testing, and documentation.</li><li>Develop practical skills in Docker-based environments, and debugging multi-component systems.</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>A design proposal describing the recommended integration path between Fablo and Fabric-X (for example: separate repo, pluggable engine, or wrapper-based approach).</li><li>An MVP implementation that can bootstrap a simple local Fabric-X network and manage its lifecycle.</li><li>Example configuration(s) and sample workflow for running Fabric-X through the proposed Fablo-based experience.</li><li>Automated tests and/or validation scripts covering the supported MVP scenario.</li><li>Contributor and user documentation explaining setup, architecture decisions, and next steps.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/83" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/83</a></p>

<p>Jaeger is the industry-standard platform for distributed tracing. As microservice architectures grow complex, finding root causes in massive trace data becomes increasingly difficult. While Phase 1 of this initiative established a baseline AI assistant for natural language search, the system currently relies on hard-coded capabilities. This project (Phase 2\) aims to transform the Jaeger AI agent from a static chatbot into an extensible, user-programmable platform. The primary objective is to implement a "Self-Service Skills" framework, architecturally similar to "Claude Code Skills." This will allow end-users to teach the Jaeger AI new debugging workflows (e.g., "Analyze Critical Path" or "Detect N+1 Queries") by simply adding configuration files containing system prompts and logic rules, without needing to recompile the Jaeger binary. The applicant will build this extension within the Jaeger v2 (OpenTelemetry-based) architecture, utilizing **LangChainGo** to orchestrate interactions with Language Models (SLMs/LLMs). This project bridges the gap between generic AI reasoning and domain-specific observability expertise.</p><p><br></p><p>**Expected Outcome:**</p><p>&nbsp;- **Skills Engine Implementation:** An approach compatible with our [BYOA (bring your own agent)](https://docs.google.com/document/d/1qD0OpyRfq-JbO6MCB5gmVxsdPcpPhxz1R_pPnKDdYOg/edit?tab=t.0#heading=h.qgr5ifum0a9m) direction that dynamically discovers, validates, and loads user-defined "Skills" (prompts and tool definitions) from configuration.</p><p>&nbsp;- **Smart Analysis Features:** A polished implementation of Natural Language Search and Contextual Trace Explanation that intelligently leverages these loaded skills.</p><p>&nbsp;- **Local-First Support:** Verified compatibility with local model runners (e.g., Ollama, Llama.cpp) to ensure deterministic performance without sending data to public clouds.</p><p>&nbsp;- **UI Integration:** Enhancements to the Jaeger React UI to expose these AI capabilities and visualize the "reasoning steps" taken by the agent.</p><p>&nbsp;- **Documentation:** A complete guide for users on "How to Author Custom AI Skills for Jaeger."</p><p>- **Learning Opportunities:**</p><p>&nbsp;- **Agentic AI Architecture:** Learn to design stateful AI agents in Go that utilize "Tool Calling" and "Reasoning Loops" rather than simple text generation.</p><p>&nbsp;- **OpenTelemetry Internals:** Gain deep familiarity with the OpenTelemetry Collector architecture, as Jaeger v2 is built directly on top of it.</p><p>&nbsp;- **Cloud-Native Engineering:** Experience contributing to a graduated CNCF project, including navigating code reviews, writing design docs (RFDs), and adhering to open-source best practices.</p><p>&nbsp;- **Full-Stack Development:** Practical experience bridging a complex Go backend with a modern React frontend.</p><p><br></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>