Explore Projects

<p>The Project includes :</p> <ul> <li>Designing and Implementing the Admin dashboard.</li> <li>Merging Admin and public templates following the WCAG norms.</li> <li>Adding breadcrumbs to navigate back and forth.</li> <li>Removing “Related Actions” &amp; using Admin dashboard, Header menu for navigation to relevant entities, and bootstrap tags/badge at the bottom where it is necessary. </li> <li>Delete modal with entity’s name and denial for delete right if there are other linked entities. </li> <li>Implementing missing UI for nearly all Edit and Add pages via a proposed common unified design.</li> <li>About page.</li> </ul> <p>These improvements will allow administrators to publish and maintain the CDLI’s entities since options are presented hierarchically with keeping the administrators' workflows in mind. Also, the project aims to solve discrepancy problems by merging the templates and enhancing the UX. I have included some designs in my proposal for implementing the above tasks and will incorporate suggestions in design by its actual users at an early stage of GSoC. Once the Front end is done with the existing sass elements to unify UI with existing pages, then I will be checking for any Violations of WCAG using Axe Devtools and will reiterate the front end.</p>

The goal of this project is to enable support for the High-Level Shading Language (HLSL) in clangd, allowing shader developers to benefit from modern language-server features such as code completion, diagnostics, semantic highlighting, and symbol navigation. Although HLSL is largely based on the C++11 standard and can already be parsed by Clang, clangd’s support remains incomplete due to missing handling of HLSL-specific constructs, semantics, and resource types. Additionally, shader development introduces unique challenges, such as multiple entry points within a single file (e.g., vertex and pixel shaders), which are not fully addressed by clangd’s current architecture. The project will begin with an evaluation of clangd’s behavior on HLSL code to identify gaps, followed by the design of appropriate extensions. An RFC will be proposed to the LLVM community to validate the design and gather feedback. Based on this, the project will implement key improvements to clangd, focusing on built-in function completion, semantic analysis of shader constructs, improved diagnostics, and better handling of shader-specific configurations. The final deliverables include a documented analysis of current limitations, an RFC describing the proposed design, a structured set of implementation issues, and upstreamed improvements to clangd, along with test coverage and documentation.

Detection time and response time are the major critical accepts of all detection and response systems. Considering the vast amount of system logs collectors, network logs collectors and external IOC systems bring vast amounts of data to process within a short amount of time and uncover the anomalies. Although this process should not be flooded with false positive alerts which we identified as alert fatigue. Considering processing vast amounts of boundless stream data and doing a less false positive detection rate is a system engineering challenge that should stand side by side with cybersecurity expert knowledge. Building state of the art systems required several major components divisions. There are Data Sources (IDS, sys logs, net logs, firewall logs, files) , External intelligence (IOC, SIEM), Processing and detection unit(s) (batch or streaming processing, deployed ML/DL models) , Data storages (databases, flat files, object storages) and visualizations (index, dashboards). Recreating each of above divisions are equivalent to reinventing the wheel, therefore openXDR focuses intergaterabiltiy to work with available tools out there which leads users to use existing systems without hassle but with the power of detection and response time of openXDR. In general, it seamlessly integrates with any EDR, NDR, SIEM, or IDS through a modular integrated architecture.

Performance benchmarking distributed systems (such as DLTs) is a challenging task, comprising of multiple aspects, such as scalable workload generation, representative workload definitions, and comprehensive data analysis. Hyperledger Caliper is a general-purpose benchmarking tool with the goal of mitigating the aforementioned aspects of performance benchmarking: 1. It provides a flexible architecture to allow scalable workload generation. 2. It collects and reports results based on detailed client-observable execution traces. 3. It allows the implementation/plug-in of custom workload behaviors to meet the diverse criteria of a wide range of business scenarios. The flexible support of the aforementioned performance benchmarking aspects inherently makes the setup and configuration of a Caliper-based project cumbersome and error-prone: - The user must provide information about the system under test (SUT) in the form of a network configuration file. - The user must also specify the flow of the benchmark run in the form of a benchmark configuration file. - The runtime behavior of Caliper components can be influenced in detail through a configuration file. - As with most programming-related projects, a Caliper-based project should employ best practices to make its structure flexible and maintainable. The goal of the mentorship project is to deliver a Visual Studio Code extension that can help users perform the aforementioned tasks in an assisted and possibly automated manner.

<h3>Modular YAMPL</h3> <p>The project fundamentally consists in developing a flexible plugin system that allows YAMPL to selectively load essential components at runtime. This makes YAMPL extremely modular and decoupled from the IPC backend modules, making it easy for anyone to add new backends or edit the existing ones without compromising the core YAMPL code.</p> <p>In addition to the plugin system, the project proposes an overhaul and development of a python binding generation procedure which allows for continuous generation of the bindings whenever the core code is modified. The ultimate goal of the project is to make YAMPL more flexible, modular and extensible.</p> <h4>How is Modular YAMPL possible?</h4> <ul> <li>An ABI-agnostic plugin middleware handles the runtime dynamic loading of the plugins, the communication between the YAMPL core code and the plugin as well as the marshalling of data. This system is designed with simplicity in mind and aims to be as <strong>solid</strong> and <strong>reliable</strong> as possible.</li> <li>A specifically designed open-source library (<a href="https://github.com/pybind/pybind11" target="_blank">PyBind11</a>) allows for seamless operability between C++11 and Python. This allows for an easy generation of the python bindings for all the core YAMPL primitives and data structures.</li> </ul>

<p>Our objective is to determine the best architectural and parallelization options for the BLonD future C++ code base. Project includes:</p> <ul> <li>Existing simulations performance profile data and component interaction diagrams.</li> <li>Micro benchmark data selection for regional stress testing that can reveal of currently existing architectural pitfalls.</li> <li>Prototypes for potential architecture evolution that are exclusively designed for BLonD performance optimization covering wide amount of task and data parallelization technics: from local SMID optimizations and coprocessor kernels to cluster technics.</li> </ul> <p>Main project deliverable will be a report covering possible architecture directions rooted in profile data, performance tests and future possibilities. This report will include UML diagrams showing architectural blueprints for concurrency and parallelism directions, structured performance analysis of performed tests and created prototypes, a table comparing selected technologies in terms of:</p> <ul> <li>Top available simulation scale.</li> <li>Integration into current architectural model.</li> <li>Prototype testing results.</li> <li>Profiling tools.</li> <li>Publically available information and documentation.</li> <li>Hardware requirements.</li> </ul>

<p>Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.</p> <p>The tool works as:</p> <ol> <li>TFTP transfer of SPL binary and u-boot.</li> <li>Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode.</li> <li>Flashing the BB hardware with etcher.io like tool. </li> </ol> <p>This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.</p>

My interest in AsyncAPI was sparked by my admiration for the technical ingenuity behind Netflix's ability to provide flawless video streaming services globally. As a Master's student studying Data Science and Computer Science at the University of Pennsylvania, I am eager to explore the intricacies of event-driven architectures further, particularly by deepening my contributions to the AsyncAPI community. My ambition is to transition from a role of simply contributing code to assuming the responsibilities of a project maintainer for the AsyncAPI Generator, a key instrument for facilitating documentation and code generation based on the AsyncAPI specification. This commitment aims to not just contribute technically but also to foster community engagement and ensure the longevity of the project. In this new role as a maintainer, I plan to review and improve documentation, handle incoming requests, engage in community discourse, assist new contributors, and spearhead the implementation of innovative features, complete with testing. Additionally, I will document my path to becoming a maintainer, the challenges faced, and the insights gained, culminating in a roadmap for future maintainers. This endeavor is not only a testament to my commitment to enhancing the AsyncAPI project but also an opportunity to contribute to the sustainability and enrichment of the broader open-source community. Leveraging my technical skills, demonstrated in a recent project that achieved a 20% performance increase using React.js and Redux, and my proactive participation in AsyncAPI discussions and enhancements, I am prepared to undertake this significant shift.

During late-night beam tests, physicists must leave detector halls to find workstations with Qt installed just to check satellite status. This project creates a browser-based interface that lets researchers monitor and control Constellation experiments from any device on the lab network without installing software. The project delivers three components: (1) upstream contributions to Constellation's Python API adding callback mechanisms for satellite state changes and discovery events, plus porting C++ topic management classes to Python; (2) a WebSocket bridge wrapping ScriptableController and MonitoringListener via multiple inheritance to expose satellite control and monitoring to browsers; (3) a SvelteKit frontend implementing the full satellite state machine for real-time control and monitoring. I have verified the multiple inheritance approach through hands-on testing. Discovery, commands, heartbeat state tracking, and CMDP log callbacks all work through a single combined class. I also created a custom satellite and controlled it through the complete FSM cycle. Deliverables include merged upstream MRs for callback APIs and topic management, a working WebSocket bridge with callback-driven state updates, a browser dashboard with state visualization and command controls, a log viewer mirroring Observatory's subscription model, comprehensive documentation, and tests.

The convergence of blockchain and 5G security presents an opportunity to redefine authentication mechanisms within the core network. Traditional OAuth 2.0 authorization mechanisms in 5G rely on centralized components such as the Network Repository Function (NRF) to verify NF identities and issue access tokens. This introduces risks, including single points of failure, insider threats, and identity spoofing. This research explores a decentralized trust model for NF authentication using blockchain-based OAuth 2.0 authorization. The study will analyze the feasibility of leveraging blockchain smart contracts for secure, verifiable access token issuance, ensuring immutable NF identity records and distributed validation. By integrating blockchain with an open-source 5G core, the project aims to enhance security, mitigate attack vectors, and reduce dependency on centralized trust anchors. Expected Outcome and Deliverables - Design and prototype of a blockchain-integrated OAuth 2.0 authorization mechanism for NF authentication. - Implementation and testing of the system using an open-source 5G core solution. - Performance benchmarking against traditional NRF-based authorization models. - Security evaluation covering resilience to identity spoofing, insider attacks, and token misuse. - Documentation and research insights into blockchain-driven 5G security enhancements.

One possible way to use the Kubernetes API to connect to the KubeVela Control Plane in the background and fetch the required information like X-Definitions, ComponentDefinitions, TraitDefinitions, PolicyDefinitions, and WorkflowStepDefinitions. The plugin can then use this information to provide syntax highlighting and autocompletion for these definitions in the YAML files. To preview the rendering result of components and traits, the plugin can use the Kubernetes API to create a dry-run of the KubeVela application on the remote cluster. The output can be displayed in the IDE to give users an idea of how the application will look when it's deployed. To compare the difference between the current application configuration and the corresponding one on the remote cluster, the plugin can use the Kubernetes API to fetch the current configuration and compare it with the local one. The differences can be highlighted in the IDE for easy identification. To preview the selected clusters by the topology policy, the plugin can use the Kubernetes API to fetch the list of clusters and display them in the IDE. The plugin can also use the Kubernetes API to fetch the topology policy and apply it to the list of clusters to display the selected clusters. For ComponentDefinition and TraitDefinition, the plugin can use the CUE language to provide validation for the CUE input and preview the rendering result. The plugin can also use the Kubernetes API to fetch the ComponentDefinition and TraitDefinition and display them in the IDE for reference.

This project enhances the OpenAFS Linux kernel module with multi-page folio support, addressing a key performance limitation in the current implementation. OpenAFS currently interacts with the Linux kernel's memory management system through single-page operations, despite recent kernel versions offering folio APIs capable of managing multiple contiguous pages as a single unit. I will implement comprehensive multi-page folio support in OpenAFS by modifying key components of the cache manager, particularly focusing on the VFS interface layer where the largest performance benefits can be realized. The implementation will optimize read and write paths to efficiently handle larger memory regions while maintaining backward compatibility with older kernel versions through autoconf detection and conditional compilation. By the end of the project, I will deliver: (1) A complete implementation of multi-page folio support that improves performance, especially for sequential read operations common in application deployment; (2) A comprehensive testing framework verifying functionality across multiple kernel versions; (3) Detailed performance benchmarks demonstrating throughput and resource utilization improvements; and (4) Thorough documentation of implementation details to facilitate future maintenance. All code will be submitted as incremental, well-structured patches adhering to OpenAFS coding standards.

<p>Pocket Science Lab at FOSSASIA aims to develop open source hardware &amp; software technology to improve science education in the developing world. The main component of PSL is ExpEYES, an open source hardware and software framework for developing science experiments. (<a href="http://expeyes.in" target="_blank">http://expeyes.in</a>)</p> <p>This proposal aims to develop open science experiments for various branches of Physics. It also aims to continue improvements in the work done during my GSoC-2015 project “Sensor Plug-ins, Add-on devices and GUI Improvements for ExpEYES” (<a href="https://goo.gl/2B2CNO" target="_blank">https://goo.gl/2B2CNO</a>). The sensor plug-ins developed during GSoC-2015 project will be used for designing new low-cost experimental set-ups.</p> <p>The new development that will be undertaken is adding wireless node module for accessing sensors with PSL. This will enable PSL to fetch data from various sensors wirelessly and it will be useful in many experiments involving oscillatory and rotatory motions. Development of low cost modules for characterization in Physics research for example - study of sound and light absorption, measurement of thermal conductivity etc, is yet another important feature of this project.</p>

<p>The aim of this project is to enhance some portions of the application that implement the Internet Message Access Protocol (IMAP). Specifically :</p> <h5>CONDSTORE</h5> <p>The Conditional Store extension, defined in <a href="https://tools.ietf.org/html/rfc7162" target="_blank">RFC 7162</a>, adds an additional mod-sequence value to every message. This makes it possible to reference changes made to the mailbox made since a particular point in time, which is extremely useful for mobile clients that are not always connected to the internet. Adding support for the CONDSTORE extension will help to greatly reduce the time and data spent on resynchronization.</p> <h5>Search</h5> <p>K-9 Mail has a basic search feature that searches the local database as well as the remote server for messages. The project aims to add features that make it more modern, such as suggestions, nested search, filters and proper full-text search.</p> <h5>Miscellaneous improvements</h5> <p>Support for some additional IMAP operations will also be added :</p> <ul> <li>Using the UID EXPUNGE command when available so that messages deleted by other clients are not expunged by accident.</li> <li>Switching between and modifying namespaces.</li> <li>Moving messages across different IMAP accounts.</li> </ul>

This project represents the orbit of a satellite orbiting earth on an Arduino-controlled pointer and a Liquid Galaxy rig through a mobile application. The application offers a unique way to visualize satellite orbits using the Liquid Galaxy rig (Google Earth) and a real-world Arduino-controlled pointer. It also provides insights into satellites' movements and access to vital satellite information seamlessly within the app. I plan to develop this by getting all the satellite data from SatNOGS database through API calls. Then, we use SGP-4 model to convert TLE of a satellite to get the state (position and velocity). Then we convert the satellite state to KML format. We segregate the KML data into the various tracks to get a neater visualization of the satellite's orbit data. Then, we write the code to send KML data from our Flutter app to the Liquid Galaxy to visualize this data on the Liquid Galaxy rig. Next, we make Arduino controlled pointer which emits green laser in the direction of satellite, which is controlled by the app. First, we 3D print the STL files of the 3D projector. Then, we assemble all the components of the Arduino-controlled pointer. Then, for the application, we use flutter_bluetooth_serial package to connect and send data to HC-05 module. Then, we use SGP-4 model to get the servo motor angles for the Arduino pointer. Then, we upload code to Arduino to receive data.

<p>The idea is to</p> <ul> <li>Add a new Database honeypot module - as for now there are modules like ssh,ftp,https and ICS but no module for catching database events.</li> <li>Add telenetsrv honeypot module to the system - as for now there are modules like ssh,ftp ,https and ICS.</li> <li>Add IMAP honeypot Module to the system - as for now there are modules like ssh,ftp ,https and ICS.</li> <li>Add SMTP Honeypot Module to the system - as for now there are modules like ssh,ftp ,https and ICS.</li> <li>Enhance the Web UI - Search functionality in the UI and also make the visualizations more better and presentable.</li> <li>Make small changes like export the data via UI and after the termination of the honeypot server in a nicely formatted JSON and CSV - currently only stored in the database.</li> <li>Add tests for all the functions inside the modules - as we have newly created the Test environment, I would like to add tests in the system.</li> <li>Docker Image - The idea is to create a docker image of the Honeypot process as currently one has to run it via script. To automate this process I would like to make a Docker Image and put it on Docker Hub to make it easier for some other company/user to use the Honeypot system.</li> </ul>

<p>Fineract version 1.0 was based on the client server architecture. Now Mifos is moving one step forward and is going to releasing Gen 3/Fineract Version 2.0 which is based upon the cloud-native architecture for digital financial services.</p> <p>Fineract 2.0 evolved from the Fineract 1.0. Now Fineract 2.0 backend API structure is totally changed with great enhancement and is massively scalable and easily adaptable.</p> <p>I will design an android application on top of fineract 2.0 that will add many exciting features. MVP architecture with Dagger 2, Rxjava, Retrofit 2 etc. Code Quality plugins Findbugs, PMD, CheckStyle. User Login with Multiple account (Using Basic Auth and OAuth2). User Profile with Edit option. Client List. New client onboarding (including additional user-defined data). Viewing of client details. Loan and savings origination - opening, approving, and disbursing applications Dashboard screen with advance search. Synchronizing client data so field officers can collect repayments, view data, and onboard new clients while offline and synchronize when the return with a connection. Unit testing and Instrumentation Testing. Documentation etc.</p>

Background: Current flows from RISC-V Sail specification to downstream implementations have manual steps which are time-consuming and can introduce errors.A lack of familiarity with Sail and OCaml presents a barrier to adoption of Sail as the basis for automated downstream implementations: emulators, simulators, compilers, assemblers, disassemblers, instruction stream tools, documentation, etc. Proposal: - Create an accessible Sail backend. - Extract salient information. - Transform it into an accessible database (JSON). - Survey projects dependent on RISC-V ISA for how that dependency is realized. - Utilize JSON to directly and automatically generate downstream source that is currently generated by hand. - Create a React-based interactive RISC-V ISA reference by directly importing the JSON database. Benefits: The backend can serve as a model for creation of additional Sail backends. The JSON database itself may be sufficient for many downstream uses. Creating downstream source shows feasibility, and a process for a fully-automated downstream flow. Additional collaboration with the effort to transform Sail into documentation is warranted. Much of the effort to transform Sail into JSON is complete, but there is still significant effort ahead: - enhanced parsing - enhancing the RISC-V Sail specification itself with more required content Much of the effort in creating an interactive web site is complete, but there is work to support the incorporation, display, and filtering.

This project focuses on creating clear, approachable, and practical documentation that shows how to integrate kgateway’s AI Gateway (agentgateway) with popular AI tools, developer UIs, and other CNCF ecosystem projects. Its aim is to make kgateway’s documentation more practical, discoverable, and reflective of real ecosystem usage, so users can better understand what’s possible and how kgateway fits into the broader AI and cloud-native landscape. Examples of integrations and tutorials include: 1. Open WebUI / OpenAI Codex / Claude Code: Step-by-step guides showing how to connect agentgateway to interactive UIs for testing, demos, and common integration patterns 2. Demonstrate how agentgateway fits into the CNCF ecosystem by integrating with tools such as: a. Argo Rollouts: Update the Argo Rollout Gateway API guides with the latest agentgateway example config. Create docs using Argo Rollouts with AgentgatewayBackends for LLM providers and MCP servers. b. KServe: Using agentgateway as an ingress for model serving, enabling rate limiting, authentication, and observability c. Knative: Add a guide for setting up kgateway with agentgateway as a custom ingress gateway Expected Outcome: 1. A series of integration guides and tutorials demonstrating how to use kgateway with AI developer tools and CNCF ecosystem projects 2. New examples, improvements, and documentation pages....

<p>This mobile app will be used to tell user about CO2 emission during user’s activity . This app will find the type of activity and distance travelled . Based on activity type and distance travelled by user , CO2 emission will be measured by using same formula used in existing browser extensions . This measurement will be real time , i.e. , user will be notified about CO2 emission at same time while he/she is travelling . This app will also contain Google Map to show user about his/her source and destination which will help user in navigating the path ( Having less CO2 emission) along with current information about CO2 emission .</p> <p>Platform Used - This mobile app will be developed as a Hybrid app . For Hybrid app development , React Native framework will be used along with Scala.js to make it cross-platform and easy to develop and maintain .</p> <p>Functionalities provided by Mobile app -</p> <ol> <li>Google account authentication </li> <li>Google Map showing path (having less CO2 emission) between source and destination</li> <li>Details about CO2 emission and its calculation</li> <li>Other features like 'learn more about Carbon Footprint' , 'set CO2 emission rate of user’s vehicle' , 'logout' etc.</li> </ol>

Help us fight climate change through nature-based solutions! The Full Lands INtegration Tool (FLINT) is a platform for estimating greenhouse gas emissions at local, national and global scales. This project aims to build a cloud deployment framework for rapid deployment of FLINT implementations. This framework will be used in a continuous deployment pipeline (CD) for integration testing and the delivery of FLINT as a service (FLINTcloud) for demonstration purposes. We hope to offer an easy entry point for new users to evaluate the FLINT platform and provide a blueprint for new users to roll their own FLINTcloud deployments. This is critical to help drive the adoption of FLINT and help scale up the monitoring, reporting and validation of carbon emissions and sequestration from land use and land use change around the world. This will involve: 1. Publishing a design for the complete FLINTcloud solution, detailing the required components, technologies and endpoints to be exposed. 2. Exposing the core FLINT routines by wrapping the existing command line interface in a REST API. 3. Creating a simple script to install the prerequisite libraries, FLINT and its modules as a standalone microservice. 4. Creating the deployment framework and setting up a CD pipeline on commodity cloud hardware, favouring automation wherever possible (e.g. infrastructure-as-code). 5. Providing new documentation for the cloud deployment procedure.

I work on Gitcord, a tool that connects a GitHub organization with a Discord server to help track and manage open-source contributions. The system will collect GitHub events such as issues, pull requests, reviews, and merges, store them locally, and calculate contributor scores based on configurable rules. The automation will follow a simple pipeline (Read → Plan → Report → Apply) so that every action can be reviewed before it is applied. To keep the system safe, it will run in dry-run mode by default and generate audit reports for maintainers. The project will also include a Discord bot that allows contributors to interact with the system directly from Discord. Contributors will link their GitHub and Discord accounts using a verification step instead of OAuth. Through bot commands, users will be able to check contribution summaries, view pull request information, request issues, and receive notifications about reviews, assignments, and merged pull requests. Gitcord will follow a local-first approach, storing data in a SQLite database rather than relying on external services. It will maintain records such as contribution history, identity mappings, audit logs, and notification history. The project will also include documentation, YAML-based configuration, Docker support, and automated tests so that organizations can deploy and maintain the system more easily.

<p>Open Event Organizer is an Android Application for Event Organizers and Entry Managers. It is a client side application for another project under FOSSASIA named Open Event Organizer Server.</p> <p>The core features implemented in the app are:</p> <ul> <li>Scan a QR code to validate an attendee's check-in</li> <li>Overview of Sales</li> <li>Ticket Management</li> <li>Edit Basic Event Details</li> <li>Offline Support to the above-mentioned features</li> </ul> <p>The app is designed on the Model View Presenter Architecture which enables robust unit testing. Each feature implemented in the app has a complete coverage of unit tests. The app uses most of the modern open source technologies like ReactiveX API for multithreading, Dagger for dependency injection, OkHttp+Retrofit for handling network requests, Evernote's android-job for handling jobs in the background, JSON API-converter to handle JSON API schema responses, Google Vision API for scanning QR code, Glide for image loading/caching, Jackson to parse JSON data, Leakcanary to detect memory leaks, Lombok for logs, Mockito Framework for unit tests, DbFlow ORM database library, Data Binding etc. Material Design Guideline is followed for the UI in the app.</p>