Explore Projects

<p>Hyperledger Cello is an enterprise-grade Blockchain-as-a-Service (BaaS) platform that provides a comprehensive REST API for managing the full lifecycle of Hyperledger Fabric networks (Network, Node, Channel, Chaincode). However, all current operations require users to interact manually through the Dashboard, which presents a steep learning curve for newcomers.</p><p><br></p><p>This project aims to implement an AI-powered operation agent with chatbot interface for Hyperledger Cello. It consists of two components:</p><p><br></p><ol><li>AI Agent Backend: A Python service that wraps Cello's existing REST APIs into LLM. It accepts natural language requests, invokes Cello operations, and returns structured responses. It also provides AI-assisted fault log summarization for common Fabric failures.</li><li>Chatbot UI&nbsp;— A chatbot interface integrated into Cello's existing Dashboard (React), allowing users to interact with the AI agent.</li></ol><p><br></p><p>The combined system enables a natural language-driven operational workflow:</p><p><br></p><p>User (chat message) → Chatbot UI → AI Agent → Cello REST API → Fabric Infrastructure</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Open Source Collaboration: Familiarity with Hyperledger Cello workflow, code review standards, and CI pipeline.</li><li>Full-Stack Engineering: Experience building a production-integrated feature spanning a Python backend and a React frontend.</li><li>Applied AI Engineering: Proficiency in LLM Tool Calling integration, streaming response handling, and prompt engineering.</li><li>Blockchain Infrastructure: Hands-on understanding of Hyperledger Fabric network topology, node types, and Chaincode lifecycle.</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>Deliverable: AI Agent Backend</li><li>Acceptance Criteria: Python service exposing a chat API endpoint; supports natural language execution of core Cello operations (list/create networks, manage nodes, query channels and chaincodes)</li></ul><p><br></p><ul><li>Deliverable: Chatbot UI (Dashboard)</li><li>Acceptance Criteria: Chat panel integrated into Cello's existing React Dashboard; supports streaming responses; maintains multi-turn conversation context</li></ul><p><br></p><ul><li>Deliverable: Documentation</li><li>Acceptance Criteria: Setup guide for the AI agent</li></ul>

<p>Meshery is the open source cloud native manager that empowers platform engineers to design and operate infrastructure. As infrastructure complexity grows, the need for intelligent assistance becomes critical. This project focuses on developing and enhancing a dedicated AI Adapter and AI Connections for Meshery. This adapter serves as the bridge between Meshery’s core orchestration engine and various Large Language Models (LLMs). The goal is to enable "Natural Language to Infrastructure" capabilities, allowing users to describe their architectural intent (e.g., "Deploy a highly available Kubernetes cluster on AWS with Prometheus monitoring") and have Meshery auto-generate the visual topology and configuration manifests. The intern will work on decoupling the AI logic from the core platform, allowing users to "Bring Your Own Key" (BYOK)—supporting both cloud-based providers (OpenAI, Anthropic) and local inference runners (Ollama, LocalAI).</p><p><br></p><p>Recommended Skills:</p><p>&nbsp;- Proficiency in Golang (Go) is essential, as Meshery’s backend is written in Go.</p><p>&nbsp;- Familiarity with MCP Servers, REST APIs, LLM APIs (OpenAI, Vertex AI), local inference servers (Ollama).</p><p>&nbsp;- Basic understanding of Kubernetes, Docker, and Infrastructure-as-Code (IaC) concepts.</p><p>&nbsp;- Experience with REST, GraphQL, and gRPC.</p><p>&nbsp;- Nice to have: Experience with React (for frontend integration in Meshery UI).</p><p><br></p><p>Responsibilities:</p><p>&nbsp;- Co-design and implement the interface for the AI Adapter in Go to communicate with the Meshery Server.</p><p>&nbsp;- Implement support for connecting to local LLMs (via Ollama) to ensure data privacy for users who cannot send infrastructure data to the public cloud.</p><p>&nbsp;- Improve the "System Prompt" and context-window management to feed the LLM relevant data regarding Meshery Models (schema definitions) so the AI generates valid infrastructure configurations.</p><p>&nbsp;- Write unit and integration tests to ensure the reliability of the adapter.</p><p>&nbsp;- Create user guides on how to configure the adapter with different AI providers.</p><p>- Expected Outcome:</p><p>&nbsp;- A fully functional AI Adapter (or Connection) integrated into the Meshery ecosystem.</p><p>&nbsp;- Demonstrable capability for users to swap between at least two different LLM providers (e.g., OpenAI vs. a local Llama 3 model).</p><p>&nbsp;- Implementation of a feature where natural language queries result in a rendered design.</p><p>&nbsp;- Merged pull requests (PRs) including code, tests, and documentation.</p><p><br></p>

<p>Kyverno recently completed two CNCF assessments: a security assessment by the CNCF TAG Security &amp; Compliance group and a General Technical Review by the CNCF TOC Project Reviews subproject. Together they produced a set of findings spanning documentation, threat modeling, network policies, global context cache bounds, API server authentication, SAST tooling, API stability and non-goals, UX/adopter research, webhook cert issuance/rotation guidance, "safe-mode" / temporary disable patterns, SLOs/SLIs and alerting/runbooks, dependency lifecycle and SCA workflows, third-party notices, and the security response process. The findings are tracked in umbrella issues for each assessment. In this mentorship, the mentee will work through the open findings from **both** the TAG Security &amp; Compliance assessment and the General Technical Review, propose and implement fixes across the Kyverno codebase, docs, and Helm charts, and help close out both assessments. Work includes implementing cache bounds for the Global Context, restricting Global Context access in namespaced policies, adding API server request authentication for the admission webhook, generating sample/network-policy templates and a CLI command to produce a Kyverno NetworkPolicy, integrating SAST tooling (e.g. semgrep, Nancy) into CI, updating the threat model and architecture diagrams, documenting core CRDs/API stability, webhook cert rotation, safe-mode/incident playbooks, SLOs/SLIs and reference dashboards, the SCA/dependency lifecycle workflow, and improving the security documentation on kyverno.io.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Resolve the open findings tracked in [kyverno/kyverno#15335](https://github.com/kyverno/kyverno/issues/15335) (TAG Security &amp; Compliance assessment) and [kyverno/kyverno#15473](https://github.com/kyverno/kyverno/issues/15473) (General Technical Review assessment).</p><p>&nbsp;- Implement Global Context cache bounds and access restrictions for namespaced policies (kyverno/kyverno#15359).</p><p>&nbsp;- Add admission webhook authentication of requests from the API server.</p><p>&nbsp;- Refresh the threat model (including CLI and other deployment options) and the architecture diagram to separate logical and physical components.</p><p>&nbsp;- Document core CRDs/APIs and per-API-group stability policy, webhook cert issuance/rotation guidance, recommended "temporary disable" / safe-mode patterns, SLOs/SLIs with reference dashboards/runbooks, and the end-to-end dependency/SCA workflow.</p><p>&nbsp;- Update the Kyverno security documentation: fix the audits page links, document risks of external data lookups, link to published security advisories, and link the current security response process.</p><p>&nbsp;- Add tests covering the new behaviors and document the changes in the Kyverno docs site.</p><p><br></p>

The project aims to create an intuitive tool in React for browsing AiiDA graphs, replacing the outdated AiiDA Provenance Browser in Materials Cloud Explore. This tool will interface with AiiDA via REST API, enabling dynamic graph exploration, clear differentiation of input and output nodes, complete visualization of connecting nodes, and node preview without page redirection. The desired result is an AiiDA node graph viewer developed with React, potentially published as a Component on the npm repository

<p>TrackPal is a public based mobile application that will be implemented using react-native. And the components that are in operation with this application, will be created based on the Go-social components. By using this mobile application, users can share their locations when they are on a bus or train and that shared location will be updated when it moves and other users can see the shared details. This will solve the problem with users have, so that they can find the bus's or train's current location by just tapping on a route or train number on the screen.</p>

The website lacks visual consistency, accessibility features, and a dark mode—critical elements for enhancing the experience of developers and engaging contributing organizations. To address this, I will follow a two-phase approach: first, planning and designing UI components and layouts.; second, implementing these designs using React.js, Next.js, TypeScript, and Tailwind CSS v4.0. Deliverables include a responsive, accessible interface, reusable component system, robust dark mode support, and performance-optimized code.

Ipv6 is the internet's future, and it necessitated a more scalable survey tool to comprehend how routing, DNS function and other traffic. The purpose of this project is to create an IPv6 listener that will passively collect IPv6 traffic data as a passive data collection tool for cyber security research. Survey6 tool has three main components: Probe, C&C Server & Data Aggregator. This year's aim is to design and implement a data aggregate component. It aims to design a big data scale async and robust data uploading pipeline.

<p>The current web application of OWTF has no login/signup implementation. Through this project, I want to work on developing the login and signup components using React with Redux for state management. I will also work on implementing a set of full-fledged robust API endpoints for serving these login/signup-related requests. As part of this project, I will also like to add OAuth authentication using Google, GitHub, and Twitter. Finally, I will write unit/functional tests to guarantee the proper working of each component ensuring the complete module is foolproof.</p>

<p>A common sight on today’s streets is the number of abandoned animals languishing on the streets suffering with injuries and disease and live without a any shelter. The silent suffering of these souls caught the attention of dynamic, animal lover, so Animal Rescue App initiative to develop a mobile app to track animals that are in need of help. Animal Rescue App Connect animal lovers, vets, and other NGOs in real time. They Can Track the Animals That Actually Need the Help. The Mobile Application will Implement From the React native using the Components of the Go social and firebase and the admin Website from the React js and firebase.</p>

In order to improve Thanos usage for users, we would like to define our APIs, both HTTP and gRPC, in protobuf/OpenAPI and expose the automatically generated documentation in the website. We also want to define the configuration of our components in protobuf. This would allow users to use tools for documentation, validation, type checking and even code generation to use our APIs efficiently. During this project we also expect collaboration with the Prometheus project to implement similar improvements on Prometheus' side. https://github.com/cncf/mentoring/blob/master/summerofcode/2021.md#port-the-prometheus-api-to-openapi. Optionally we would like to work on the index page on every Thanos component server that will expose those resources for easier debug.

kruise-game contains two CRDs GameServer and GameServerSet. Game servers can be managed by deploying or changing the corresponding CR. However, in actual production use, a release or operation and maintenance action is often a combination of a series of operations on CR. For example, set the GameServer image tag with ids 1, 7, and 10 to v0.3; adjust the update priority of GameServer with ids 5, 9, and 11 before updating the game server, etc. Therefore, a set of APIs with operation and maintenance semantics is needed, which users can directly use or integrate into their own operation and maintenance platform to facilitate operation and maintenance operations. Expected Outcome: * A service component that includes multiple APIs

<p>This proposal will present the project goal of idea 5, which is to integrate the web-monitoring software into the Wayback Machine and help to further advance it, and how this can be achieved. More specifically, the following solutions are suggested as part of the implementation plan: making the login screen optional, querying the CDX server and not the web-monitoring-db, implementing a mechanism for making changes to the UI easily, improving the code so it is able to handle a lot more data, using The Wayback Machine's calendar to present a webpage capture's dates, and keeping only the required project components. In addition, this proposal contains a link to a server hosting my implementation of some of the proposed solutions. Apart from that, a timeline that presents a rough plan of how the project would be implemented is included. Last but not least, biographical information is provided.</p>

<p>Robots are slowly becoming a part of the internet of things, and easy control and universal access will be a step in future of robotics. MRPT’s Web Framework Library should address this problem.A lightweight publisher/subscriber mechanism needs to be created for MRPT. The C++ server library and the javascript library will then leverage this to create further applications. There will be two libraries, a C++ server library for RPC on the robot. Another will be a javascript library which provides modules for such procedure calls.This task involve serialization of existing mrpt objects for JSON transfer, RPC protocol, websocket setup, 3D rendering of objects in js, reusable js components for sending and receiving data from user created app where the user is largely benefitted from easy to use library methods and objects.</p>

<p>Since the migration to Android Architecture Components has already started, this project aims to integrate Room instead of SQLiteDatabase as a better approach for data persistence. This idea involves the following challenges:</p> <ul> <li>Initially, all the API responses need to be cached in order to reduce the number of connections to the server (especially Featured Projects and the Categories displayed on the main screen)</li> <li>To continue, the structure of the projects (JSON instead of XML) needs to be improved</li> <li>Showing and caching the user projects (local/on-server-stored projects) in the Projects screen will give the user the control to modify/delete his projects from one place</li> <li>Kotlin will be the only used language -- no more Java!</li> <li>MVVM architecture will be used.</li> </ul>

Vitess uses a couple of tools to benchmark its codebase and to make sure that new code doesn’t introduce performance regressions. These tools are: arewefastyet and the VReplication Benchmarking Framework. We currently have an old frontend UI that serves arewefastyet. However, this UI is slow, not optimized and not easily extensible. It uses the built-in Golang template system to serve pages. We would like to create a common frontend UI that will be used by both benchmarking tools and that will replace the current arewefastyet’s UI. The mentee will have the responsibility of creating the UI using (most likely) React/Vite on Vercel. The frontend component will connect to our already-existing backend components: a MySQL database and arewefastyet’s REST API. - Expected Outcome: The expected outcome is to have a working frontend UI that integrates well with our different backends (databases and benchmarking tools’ APIs).

Kubeflow Pipelines (KFP) currently only supports MySQL/MariaDB databases, creating a significant limitation for many organizations that standardize on PostgreSQL. This project aims to implement comprehensive PostgreSQL support across the KFP stack, including the API server, cache server, and ML Metadata components. The solution involves developing database abstraction layers, SQL dialect adapters, and migration tools that enable users to seamlessly deploy KFP with PostgreSQL backends. By providing this integration, the project will greatly expand deployment options for enterprise environments where MySQL is prohibited by policy, benefit organizations leveraging PostgreSQL's superior data warehousing capabilities, and eliminate the need for unsupported workarounds that currently require substantial effort from users. The end result will be a more flexible, enterprise-ready Kubeflow Pipelines platform that meets diverse organizational requirements.

The VelaUX API server follows the Open API schema. It could auto-generate the swagger configs via CLI. When VelaUX frontend or other projects need to call these API, they must write the model code and request the API code. We can provide SDK for them to start faster. [OpenAPI generator](https://openapi-generator.tech/) could help to generate most codes. But there are still some special cases like: - Dynamic component/trait/policy/workflowsteps properties need to be generated according to CUE. - Automatically handles the user authentication process, including automatically refreshing tokens. - The API definition may be incomplete accuracy, we should check it to generate high-quality code. - Expected Outcome: The outcome of this project will be expand two more database driver for KubeVela VelaUX API server: - VelaUX APIServer TypeScript SDK - VelaUX APIServer Java SDK

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.

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

This project aims to transform how analysts interact with threat intelligence data in IntelOwl by introducing a conversational AI interface. Currently, analysts must manually navigate dashboards, query APIs, and correlate results across different jobs and investigations. To solve this, I will integrate a privacy-preserving, self-hosted LLM chatbot using Ollama and a LangChain ReAct agent. The agent will be equipped with custom tools to query IntelOwl's internal REST API using natural language. Key deliverables include: 1) A new Django chatbot app handling WebSocket connections via Django Channels for real-time token streaming. 2) Ollama Docker integration with CPU/GPU auto-detection. 3) A native React chat component embedded in the existing frontend. 4) Custom LLM tools for triggering analyses and searching data models. 5) Comprehensive test coverage and detailed documentation for users and future maintainers.

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

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.