Explore Projects

Description: Thanos is a distributed system that has a user interface written in React. Let's create a community instance with continuous integration for easy testing of how Thanos works. Also, it could serve as a testing ground for new React components. A server is provided by CNCF (https://github.com/cncf/cluster/issues/190).

<p>Meshery Models are declarative representations of infrastructure, applications, and their relationships - the canonical artifacts through which Meshery understands and manages cloud native systems. Today, Meshery lacks a standardized, portable distribution mechanism for these models. OCI registries (Docker Hub, AWS ECR, GitHub GHCR, and others) have emerged as the universal artifact store for the cloud native ecosystem, and [ORAS](https://oras.land) (OCI Registry As Storage) provides the Go-native tooling to push and pull arbitrary artifacts to any OCI-compliant registry. This internship implements end-to-end OCI registry support for Meshery Models - from new Connection and Credential types for major registries, to ORAS-powered push/pull logic in the Meshery server, to a redesigned Registry page in the Meshery UI that gives users full visibility and control over their model artifacts across registries.</p><p><br></p><p>Recommended Skills: Golang, REST API development, React. Familiarity with OCI image specifications, container registries, or ORAS is a plus. Experience with Meshery or other CNCF projects is welcomed but not required.</p><p><br></p><p>Responsibilities:</p><p>&nbsp;- Design and implement Connection and Credential types for Docker Hub, AWS ECR, GitHub GHCR, and additional OCI-compliant registries within Meshery's existing connection framework.</p><p>&nbsp;- Implement Golang server-side logic using the ORAS SDK to push and pull Meshery Models (and their component schemas, relationships, and policies) to and from any OCI-compliant registry.</p><p>&nbsp;- Define the OCI artifact media types, manifest structure, and layer conventions used to package Meshery Models for registry storage.</p><p>&nbsp;- Enhance or rewrite the Registry page in Meshery UI to surface connected registries, browsable model artifacts, push/pull controls, and credential management.</p><p>&nbsp;- Write integration tests covering push, pull, and round-trip fidelity of Meshery Models across at least two registry backends.</p><p>&nbsp;- Document the new registry integration, artifact format, and UI workflows in Meshery's official documentation.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Meshery users can connect to Docker Hub, AWS ECR, GHCR, and other OCI registries using managed credentials and push or pull Meshery Models directly from the Meshery UI and `mesheryctl`.</p><p>&nbsp;- A well-defined OCI artifact convention for Meshery Models, documented and suitable for adoption by the broader Meshery ecosystem.</p><p>&nbsp;- A redesigned Registry UI page providing a unified, registry-agnostic interface for model artifact management.</p><p><br></p>

<p>The Open Event project has SIX components:</p> <ul> <li>The Open Event Format Definition</li> <li>The Open Event Server</li> <li>The Open Event Generic Android App and It's Generator</li> <li>The Open Event Web App Generator</li> <li>The Open Event Organiser App</li> <li>The Open Event Frontend</li> </ul> <p>All the components support organizers in all stages from event planning to publishing, marketing and ticket sales for all kinds of events including concerts, conferences, summits and regular meetups.. Automated web and mobile apps help organizers in creating event web pages and apps without any investment or knowledge of development. This also helps attendees to get information easily.</p> <p>This proposal focuses on the <strong>Open Event Server, the Organizer App, and the Frontend</strong> for the summer.</p> <p>For the Open Event Server, remaining important features will be added in order to make it feature complete. These features would then be implemented in the Frontend and the Organizer App.</p> <p>The Organizer App's architecture will be revamped from MVP to MVVM. And new features from the server will be implemented while using reactive programming, dependency injection, and other modern standard libraries.</p>

This project addresses the issue of fragmented tools within the Kubeflow ecosystem, specifically Elyra, Kale, and Jupyter Scheduler, which complicates workflows for data scientists. The proposal aims to solve this by developing a unified JupyterLab plugin for Kubeflow. This plugin will consolidate and modernize the functionalities of the existing tools, providing a cohesive environment for developing, testing, and deploying machine learning workflows directly from JupyterLab. The plugin will achieve this by implementing seamless integration with Kubeflow Pipelines. Users will be able to convert notebook cells to pipeline steps, define and visualize pipeline workflows, submit pipeline runs, and monitor their execution status, all within JupyterLab. The plugin will be built with a modular architecture, including Python backend components for interacting with Kubeflow Pipelines and parsing notebooks, and TypeScript/React frontend components for the user interface. The key deliverables of this project are: • A unified JupyterLab plugin architecture consolidating Elyra, Kale, and Jupyter Scheduler functionalities. • Seamless integration with Kubeflow Pipelines, enabling notebook-to-pipeline conversion, workflow definition and visualization, pipeline submission, and monitoring within JupyterLab. • A user-friendly UI for pipeline development and management using modern React components. • Initial integration with Kubeflow Notebooks for easier notebook provisioning. • Comprehensive documentation and usage examples. • A robust testing framework to ensure plugin reliability, including unit tests, integration tests, user acceptance testing, continuous integration, and compatibility testing. This unified plugin is expected to significantly improve workflow efficiency for data scientists and ML engineers by bridging the gap between interactive development and production-grade ML infrastructure.

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>

InZpect is next generation dump viewer and inspector that is something of a successor to IPCS. There is a lot of work to do in UI and testing. Plus almost any work on the internals requires lots of knowledge of the operating system. SVCDumps are not highly structured, so the relationships of data and state of the computation must be synthesized from the memory blocks in the dump, primarily. The server is written in java, with some back-end code coming from extensions/usage of the ZSS in Zowe. The client code is in Javascript using React. The tooling is very minimal currently, as is the number of third-party libraries.

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

<p>Volcano's scheduler has no presence in the dashboard today. Three critical operator workflows are missing:&nbsp;</p><p><br></p><p>(1) Configuration — the entire scheduling policy (6 actions, 22 plugins, per-plugin toggles and arguments) lives in a raw Kubernetes ConfigMap edited only via `kubectl`, with no validation or UI;&nbsp;</p><p>(2) Observability — Volcano exposes rich Prometheus metrics (scheduling latency, preemption counts, unschedulable job/task counts) that the dashboard never queries, leaving operators dependent on a separate Grafana stack;&nbsp;</p><p>(3) Logs — debugging scheduling issues requires `kubectl logs` against pods in `volcano-system`; the dashboard has no log viewing capability at all. This project adds a `/scheduler` section with three tabs: a Config tab that reads and writes the `volcano-scheduler-configmap` as a structured form, a Metrics tab that proxies and visualizes the scheduler's Prometheus `/metrics` endpoint, and a Logs tab that streams live logs from any Volcano system component (`volcano-scheduler`, `volcano-controller-manager`, `volcano-webhook-manager`, `volcano-agent`) — all backed by new tRPC procedures using the existing `CoreV1Api` client in `packages/trpc/server/utils/k8s.ts`.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Config tab: draggable action pipeline editor, plugin tier editor with per-plugin `enabled` toggles and typed argument fields, live YAML diff preview, and a Save button that patches the ConfigMap via `CoreV1Api.patchNamespacedConfigMap`.</li><li>Metrics tab: stat cards for unschedulable jobs/tasks and total preemptions; line chart for e2e and per-plugin scheduling latency; bar chart for per-action latency — all from a new `getMetrics` tRPC procedure querying the scheduler's `/metrics` endpoint.</li><li>Logs tab: component selector dropdown (`scheduler`, `controller-manager`, `webhook-manager`, `agent`), `tailLines` control, keyword filter/highlight, and real-time log streaming via `CoreV1Api.readNamespacedPodLog` with a Server-Sent Events or polling transport.</li><li>Updated RBAC in `deployment/volcano-dashboard.yaml` for ConfigMap `get`/`update` and Pod logs in `volcano-system`.</li><li>Tests and user-facing documentation.</li></ul>

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

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.

The emergence of blockchain interoperability in the last few years has been playing a pivotal role in the development of blockchain technology. Hyperledger has been supporting multiple projects in this domain, leading to semantic and technical interoperability advancements. For example, Hyperledger has been investing resources in the adoption of different interoperability standards, such as the Secure Asset Transfer Protocol (SATP), being standardized at the Internet Engineering Task Force (IETF) However, security, privacy, and organizational interoperability are still the most prominent challenges in the space. This internship attempts to partially address these issues. This internship connects these three dots by offering the ability to Hyperledger Cacti to create robust consortia that adhere to privacy and security needs, required by organizations leveraging our open-source project. The present internship compresses the development and studying of the API Server, a core component of the Cacti Node. The mentee will develop API Server support for gRPC and the Connect protocols. Furthermore, an integration with SATP to create consortia will be performed. This can be achieved with some scripts for the end user to generate API Servers and SATP consortia configurations, served by a simple UI. This could become the new de-facto Cacti UI.

Institutional departments, such as the Biomedical Informatics (BMI) Department of Emory University School of Medicine, manage vast amounts of data, often reaching petabyte scales across multiple Linux-based storage servers. Researchers storing data in these systems need a streamlined way to modify ACLs to grant or revoke access for collaborators. Currently, the IT team at BMI is responsible for manually handling these ACL modifications, which is time-consuming, error-prone, and inefficient, especially as data volume and user demands grow. To address this challenge at BMI and similar institutions worldwide, a Web Management Interface is needed to allow users to modify ACLs securely. This solution would eliminate the burden on IT teams by enabling on-demand permission management while ensuring security and reliability. The proposed system will feature a robust and highly configurable backend, high-speed databases, orchestration daemons for file storage servers, and an intuitive frontend. The proposal includes an in-depth analysis of required components, high-level and low-level design considerations, technology selection, and the demonstration of a functional prototype as proof of concept. The goal is to deliver a production-ready, secure, scalable, and reliable system for managing ACLs across multiple servers hosting filesystems such as NFS, BeeGFS, and others. This solution will streamline access control management and prepare it for deployment at BMI and other institutions worldwide, significantly reducing the manual workload for IT teams.