Explore Projects

This project implements comprehensive patient-facing digital health capabilities in the CARE platform by integrating Ayushman Bharat Digital Mission (ABDM) Personal Health Record (PHR) flows. While CARE currently supports provider-side health information exchange through the existing ABDM module, it lacks patient-centered features that would allow individuals to access and control their health data. My solution builds a complete set of APIs and interactive user interfaces to bridge this gap by implementing seven key components: ABHA Enrollment - Digital identity creation with multiple verification methods Profile Login - Secure multi-channel authentication and session management User Profile Management - Personal health information control and preferences Discovery and Linking - Finding and connecting fragmented health records Subscriptions & Notifications - Automated health updates and alerts Consent Management - Granular control over data sharing permissions Health Record Display - Unified view of medical history across providers The implementation seamlessly integrates with the existing ABDM module while adding complementary PHR capabilities, enabling CARE to function effectively in dual roles—as both a provider-focused clinical system and a patient-centered health record platform. Deliverables include a fully functional implementation of all ABDM PHR APIs, an intuitive and responsive patient portal interface, comprehensive transaction tracking for compliance, and thorough documentation. All components will adhere to healthcare security and privacy standards while providing a cohesive user experience. The completed project will transform healthcare delivery by eliminating information gaps between providers and empowering patients as active participants in their care journey.

<p>This project aims to improve the functionalities of the Apache OODT OPSUI React.js User Interface and implement a REST API for the resource manager component of Apache OODT. The current OPSUI React.js dashboard which has been developed in the Apache Wicket framework will be replaced with the React.js UI on the completion of this project.</p>

<p>I've been using different technologies over the past few years such as PHP (Laravel), Nodejs, VueJS, React, and React Native. Also, I've been using GraphQL for over a year and I made a couple of full-stack/backend applications such as: -- a basic twitter clone using React Native ( using react-apollo), and nodejs (using Appollo. server).</p> <p>-- I made microservice e-commerce using NestJS alongside GraphQL. <a href="https://github.com/secmohammed/microservices-e-commerce-nest-api" target="_blank">Link</a></p> <p>-- slack clone using React ( with Typescript), and NestJS <a href="https://github.com/secmohammed/slack-clone" target="_blank">Link</a></p> <p>-- meetups clone API using (Golang and gqlgen) <a href="https://github.com/secmohammed/golang-graphql-meetups" target="_blank">Link</a></p> <p>-- ideas API clone using NestJS and GraphQL <a href="https://github.com/secmohammed/ideas-api" target="_blank">Link</a></p> <p>I've been working with GraphiQL to test my endpoint especially when not having the frontend built yet. and I'm keen on participating in this project to help with what I could to improve it.</p>

Currently, MIT App Inventor users lack a straightforward way to incorporate Retrieval Augmented Generation (RAG) for context-specific tasks requiring large or multiple documents. Teachable-LLM addresses this gap by integrating an on-device RAG pipeline, allowing users to build domain-specific chatbots without relying on external cloud services. A dedicated web app will serve as both a data management tool—enabling document import/export to a custom RAG database—and a playground for testing. Meanwhile, the ChatBot component will be extended to support RAG using the imported database. Key deliverables include the updated ChatBot component, a React-based web interface, thorough documentation, and pilot testing. This approach emphasizes accessibility, privacy, and simplicity, bringing advanced language model capabilities into the App Inventor ecosystem.

The existing GPU profiling workflow in OpenVino, through benchmark_app connects kernels to the model layers (primitives) and reports their execution times. However, this level of abstraction is too coarse to identify kernel instruction level insights. Intel GTPin, on the other hand, provides instruction level GPU kernel metrics like clock cycle counts, but is unable to directly map such metrics to specific inference or layers. This project aims to build a GTPin-centered profiling capability within OpenVINO to identify hotspot kernels and analyze their execution characteristics. The approach involves integrating controlled GTPin profiling into the inference flow, developing a custom GTPin tool for collecting kernel-level metrics, and progressively interpreting these metrics using signals from OpenVINO performance counters, and kernel metadata. The expected deliverable is a GTPin-based profiling workflow integrated into OpenVINO, capable of identifying bottleneck kernels, providing insight into their behavior, and offering indicative optimization directions, with validation using tools such as VTune.

The project focuses on upgrading the Eventyay platform components to VueJS 3 within the unified Eventyay codebase. While minor adjustments are required for the ticketing components, the primary focus lies on modernising the talk and video modules, which currently rely heavily on VueJS 2, as well as on updating project-specific plugins. The objective is to replace all existing VueJS 2 code with VueJS 3 across the entire platform while preserving existing functionality and API compatibility. As the Eventyay platform is being consolidated into a single repository, the project also includes implementing additional API features where necessary to support the unified infrastructure. The upgrade improves the maintainability and performance of the platform, aligns it with current best practices, and ensures long-term sustainability of the frontend codebase. Throughout the project, Vue dependencies are upgraded, and components are systematically refactored to address breaking changes introduced in Vue 3. Extensive compatibility testing is carried out to ensure stability across all migrated features. Updated components are made fully functional under Vue 3, with a gradual transition from the Options API to the Composition API where appropriate, leveraging the benefits of improved structure, reusability, and maintainability. In parallel, the continuous integration pipeline is refined to support automated testing and deployment, including the seamless rollout of updated documentation that reflects the evolving architecture and feature set of the unified platform.

Harbor is a widely adopted container registry. As one of the most widely adopted container registries, it is a critical component in modern software supply chains. This project aims to enhance its security capabilities by extending Harbor's Pluggable Scanner specification to support Runtime Behavior Profiles (also known as a Behavior of Bill, or "BoB"). While Software Bill of Materials (SBOMs) describe what an artifact contains, a BoB describes how it behaves at runtime. By integrating kubescape-node-agent as a scanner, Harbor will be able to retrieve, store, and display these runtime profiles for OCI artifacts. This allows software producers to ship secure-by-default configurations and provides consumers with a way to verify runtime behavior, detect anomalies, and report unexpected activity. This feature will create greater trust in artifacts and help users meet emerging compliance requirements, such as the EU's CyberResilience Act, by enabling active breach identification through anomaly detection. Expected Outcome: Propose and document the minimally necessary modifications to the Harbor Pluggable Scanner Spec to support the retrieval of runtime profiles. Implement a scanner adapter that integrates kubescape-node-agent with Harbor. The adapter must be able to retrieve and process SPDX-compliant Runtime Profiles (SBOBs). Extend Harbor's UI to allow users to view runtime profiles and see potential mismatches between expected and observed behavior.

<p>Open Event is an application that allows users to find and book tickets for events. This proposal is about integrating major missing components of Open Event (adding missing API components and payment gateways for events) as well as improving existing components by adding features, polishing the UX/UI and improving the codebase.</p>

<p>So far Thanos has successfully used pieces of old Prometheus UI with some improvements. However, since Prometheus now moved all UI pages to React, it opens new possibilities for Thanos as well. The task is to move all UI to React and enrich them with Thanos features. As mentioned in the proposed idea, I also plan to add UI to every component of Thanos ensuring consistency and improve the experience of using Thanos even more.</p>

The Language Server Protocol (LSP) is a communication protocol between editors and analysis engines. Many major editors support this protocol, making Language Servers—development support tools that communicate with editors via LSP—highly significant in modern development environments. In this proposal, I aim to implement and enhance some new features for a new Language Server called JETLS, which is deeply integrated with the latest Julia compiler infrastructure. I will strive to deliver low-latency, precisely source-mapped feedback to users, enhancing the overall development experience by leveraging JET.jl, Revise.jl, JuliaSyntax.jl, and JuliaLowering.jl. JETLS will provide powerful editor support for programmers working on large-scale Julia codebases, helping them discover potential bugs and write more efficient code.

This project comprises two parts: prototyping a real-time Python pipeline for object detection on point cloud data, and integrating it into LivePose. The goal is to build a functional pipeline that reads streaming point cloud data from various sources (e.g., Orbbec Femto Megas, Intel RealSense, stereo cameras), runs deep learning inference using models like PointNet++, applies filters for smoothing and tracking, and streams the results via OSC. During prototyping, the system will be evaluated across multiple models, input types, and hardware configurations to assess real-time performance and reliability. Once validated, the pipeline will be integrated into LivePose, leveraging its modular infrastructure for input handling, filtering, and output. By the end of the project, LivePose will support end-to-end processing of streaming 3D point cloud data in at least one working configuration, with clear documentation and performance benchmarks to guide future development and extension.

<p>LibreHealth EHR is an open source, clinically focused EHR which was designed for easy use and customizable for variety of settings. LibreHealth is a community that works to develop and implement Health Information Technology application to deliver better health outcomes using these technology platforms one among them being the LibreHealth HER. This is an open source, clinically focused EHR which was designed for easy use and customizable for variety of settings. The back end of this EHR is forked from OpenEMR data model. To move away from OpenEMR data storage, efficient reading and writing clinical data and improving interoperability, we need to move to the standard of FHIR (Fast Healthcare Interoperability Resources) Specification. This project aims to build components for LibreHealth EHR based on FHIR with Polymer components. This will enable the EHR developers to upgrade to a standard data model. The resources from modules in level3 and level4 of FHIR with maturity level above 3 will be developed using Polymer components. These resources were specifically selected as they contribute to the patient centric feature of the EHR.</p>

<p>My proposal is based on getting full support for JavaScript within the RoboComp framework. For this, the current state of generation of written components in the JavaScript language must be improved. Last year during the 2017 GSoC the functionality of the RoboComp component generator was extended to provide component supports based on NodeJS. A first approximation was achieved but still lacks robustness, reliability and should be extended to include more features. In addition, recently Zeroc ICE has added support for JavaScript interfaces, therefore the component generator must be extended to support this feature, both as a server and as a client. The component model of RoboComp must be able to generate components in this language with the same functionality as its counterparts in C ++ and Python, thus achieving complete support for JavaScript within RoboComp.</p>

This project endeavors to revamp the Kubernetes batch execution service to adhere to the Task Execution Service (TES) standards established by the Global Alliance for Genomics and Health (GA4GH). Objectives: Python: Rewrite the existing Java codebase in Python, utilizing the latest version of Python dependencies. Address deprecated code and enhance maintainability, considering the existing task-core is written in Python. Repository Consolidation: Merge all TESK repositories into a unified repository to streamline management and reduce redundancy. Simplify dependency management, ensuring compatibility and synchronized updates across components. Facilitate collaborative development and code sharing among developers. Standardization and Compatibility: Implement TES v1.1.0 To incorporate the latest GA4GH TES features, and comprehensive support for client-side GUI components. Ensure compatibility and interoperability with existing systems. Deliverables: Replacement of Java Springboot API with FOCA-based API implementation. Codebase rewritten in Python with updated dependencies and sanitized code. Unified repository for TESK components for simplified management. Documentation covering the entire system comprehensively. Enhanced collaboration among developers and streamlined build and deployment processes. Milestones: Environment setup and FOCA server, security, and logging configuration. Migration of endpoints as proof of concept (POC). Merge tesk-core into the unified repository. Creation of pydantic data models and data validations. Migration of Kubernetes wrapper. Migration of service and controllers. Upgrade to TES v1.1.0 and update helm charts and docker images. Merge deployment charts and add tests for continuous integration (CI) pipelines.

<p>The emergence of serverless computing moves cloud/edge to the next generation of resource sharing: function as a service. The innovation makes developer released from provisioning, updating, and managing servers under flexible scalability and fault tolerance. Also, the most influential outcome is no computing cost when idle, which is also known as pay as you go model.</p> <p>However, the performance is under critical to be improved, i.e., more servers required in existed serverless platform, high and not predictable round-trip latency, especially under high concurrency and keeping dependable.</p> <p>Here come some places to improvement, including shortened path, performance improvement on invoker, serialization elimination, and scheduling. In the first step, the picked-up topic: <strong><em>work-stealing and priority-based scheduling and direct connection for streaming capabilities</em></strong> will be a great and valuable choice.</p> <p>Goal on this project</p> <ol> <li>Work-stealing scheduling on load balancer.</li> <li>Direct connection for stream support.</li> <li>Priority-based work-stealing scheduling.</li> <li>Comprehensive tests to avoid bugs on concurrency and distributed failure.</li> <li>Performance tests and optimization.</li> </ol>

The primary objective of this project is to enhance the user experience of MIT App Inventor by providing users with information about the availability of components on iOS or Android platforms. To achieve this, proposed changes will be made to the Designer editor code to enable users to determine whether a component is accessible on a particular platform or both. The coverage.json file will be utilized to extract information about the availability of components, which will be represented by iOS or Android icons displayed on the palette items and a text displaying if the component is exclusive to any of the platforms(Android or iOS) on palette Help Popup dialog box. Furthermore, a dialog box will inform users about unsupported components when they connect their devices through the AI companion. The proposed modifications will empower users to make informed decisions when creating their applications, resulting in higher-quality apps that cater to user needs and expectations.

<p>SUSI.AI is a powerful and Open Source Artificial Intelligence based Personal Assistant which retrieves data from various sources and answers queries of the user in the form of text, images, maps, pie charts, etc. My aim for GSOC is to enhance Susi AI server and Susi Android app by implementing new features in them and improving already implemented features.</p> <p>Goals of the project:</p> <ul> <li>Stabilizing Susi android app and making it faster and reliable.</li> <li>Adding more functionalities in the Susi server and then implementing those functionalities in the android app using server API.</li> <li>Improving the Authentication and Authorization system in both server and app.</li> <li>Adding more skills to the Susi, thus improving its AI.</li> <li>Implementing Rating and Feedback mechanism in Server and App.</li> </ul>

Open WebUI is a very popular component that provides a user interface to generative models. It supports use cases related to text generation, RAG, image generation, and many more. It also supports integration with remote execution servings compatible with standard APIs like OpenAI for chat completions and image generation. The goal of this project is to integrate Open WebUI with OpenVINO Model Server. It would include instructions for deploying the serving with a set of models and configuring Open WebUI to delegate generation to the serving endpoints.

<p>Deploying an email service requires patience and technical expertise, as it involves orchestrating a myriad of heterogeneous software components. The benefit of self-hosted email is greater privacy for end-users. In the past, Debian contributors had unsuccessful attempts to compile a unified package that would make such deployments easier. My proposal for GSoC ’21 outlines a 9-week plan for packaging an email server to be run on Debian-powered SBCs. It is divided into 3 release cycles and 2 “extra credit” tasks. If successfully completed, the end product will provide interoperability, spam detection, transport security through encryption and traffic filtering through isolation.</p>

Integration of Talks and Speakers Component with eventyay Video I will create a seamless connection between eventyay-talk and eventyay-video platforms to eliminate the current manual processes that frustrate event organizers. My implementation will: Develop an event-driven system that automatically synchronizes rooms created in eventyay-talk to appear in eventyay-video without manual duplication Build an intuitive MC assignment interface where organizers can easily assign team members to manage different video rooms using a drag-and-drop system Integrate speaker profiles and session information across platforms so attendees see consistent information whether they're in talk sessions or video rooms Create a unified navigation experience with consistent design elements that make the platforms feel like a single, cohesive system I'll approach this with an incremental development strategy, delivering working features every 2-3 weeks rather than a big-bang integration. Having experienced the frustration of disconnected systems while volunteering at tech events, I'm personally motivated to solve this problem for both organizers and attendees.

This proposal aims to create a production-ready, single-command deployment integrating the OpenHands AI coding agent with the OpenVINO Model Server (OVMS) on Intel AIPC hardware. The project resolves three critical friction layers: the API routing mismatch between OVMS (/v3) and OpenHands (/v1), the failure of structured tool-call execution which leads to model hallucinations, and system crashes caused by memory exhaustion from concurrent Docker sandboxes. By implementing a Docker Compose manifest with shared bridge networking and host Docker socket passthrough, the architecture offloads heavy LLM inference to iGPU or NPU targets while keeping orchestration on the CPU. Key technical deliverables include configuring native tool-guided generation for models like Qwen3-Coder-7B, enabling prefix caching to reduce multi-turn latency by over 50%, and enforcing strict container memory limits to ensure stability on 8 GB and 16 GB RAM profiles. The project concludes with a formal usability gap analysis and a finalized deployment setup to provide a seamless, local, and private AI development environment

<p>My most favorite thing about Oppia is its Test-Driven-Environment. All these tests (FE, BE, E2E, Lint) will ensure that no new error or bug will be introduced into the system. Since Oppia is one of the most prominent open-source organizations, it needs rigorous testing and 100% coverage.</p> <p>Oppia’s frontend codebase can be broadly classified into four main categories.</p> <p>1.Components</p> <p>2.DIrectives</p> <p>3.Services</p> <p>4.Others</p> <p>We have a total of 205 components. In which, 163 components have 100% coverage. Partially covered components are 42. And finally, uncovered files are 0.</p> <p>We have a total of 203 directives. In which, 15 directives have 100% coverage. Partially covered directives are 188. And finally, uncovered files are 1.</p> <p>We have a total of 333 services. In which, 262 services have 100% coverage. Partially covered services are 71. And finally, uncovered files are 0.</p> <p>By excluding others category, we should thoroughly test and should achieve 100% coverage in components, directives, and service.</p> <p>My primary focus for this project is only unit testing. Although I'll be doing angular migration as an optional entity.</p>

<p>There are shell scripts for creating X.509 certificates, revoking certificates and signing CRLs and scripts for the creation of Profile certificate files for certain devices such as Linux, Apple OS X, Windows, iOS, etc., these require careful specification of various certificate attributes so that these certificates work on a variety of devices: Android, Windows, iOS/OSX, Linux, etc. The goal of this project is to gather all that knowledge into a simple interface which should support the following:</p> <ul> <li>Generating the proper ipsec.conf configuration based on web admin interface including DNS/split-DNS configurations.</li> <li>Allow Administrator to invite new users using email id.</li> <li>A new user after account validation can download the generated certificate/profile (over TLS) for different platforms.</li> <li>The generated certificates/profiles can only be downloaded once, through the portal.</li> <li>Admin can list, revoke/disable (temporary revocation) user certificates/profiles.</li> <li>Generate PKCS#12 certificates for users.</li> <li>Generate iOS/OSX .mobileconfig profiles for automatic installation on iOS/OSX.</li> <li>Ipsilon user authentication to web application.</li> <li>Configure munin-node to work with libreswan plugin.</li> </ul>