Explore Projects

<p>The Wayback Machine Extension is a powerful tool that collects and stores information about the search queries you make and the web pages you view to provide you with information about those pages and to help the Wayback Machine archive the Web. Driven by a powerful idea and an enthusiastic team, this extension has successfully been archiving the internet since 2017. The Wayback Machine Extension plays a significant role in providing people a way to archive and preserve the publicly available web pages and mapping the evolution of the World Wide Web.</p> <h4>This Project focused on Improving the Wayback Machine Extension by:</h4> <ol> <li>Enhancing the existing Search Box feature.</li> <li>Adding 'Fact Check' feature</li> <li>Adding 'Bulk Save' feature</li> <li>Re-defining the display of existing Contexts</li> <li>More enhancements:<ul> <li>Solving the existing issues to ensure full functionality</li> <li>Code optimization and improvement</li> <li>UI improvements</li> <li>Searching, inspecting and fixing bugs</li> <li>Interacting with users about issues and opportunities to make the app better</li> <li>Writing Tests</li> <li>Adding support for Edge</li> <li>Making the Internet a BETTER place to surf.</li> </ul> </li> </ol>

With the help of JavaScript and HTML5/CSS, 1. Maintain musicblocks v3 issues Detailed discussion on all the existing features, issues and other resources of music blocks with the mentors, strategize and prioritize maintenance work accordingly and deliver a reasonably robust version. 2. Resolve issues of browser changes i.e. Planet's cross origin errors By reading the updates on chromium versions (Browser Security) there are a lot of websites facing issues to cop-up. However, it can be easily solved by the help of tutorials , brainstorming and better characterization of code. 3. Better characterize some music utils code to resolve the regression No regressions will be found by the end of the project in any music utils code. Pulling the latest bits of tone.js file in the repository will ensure that the problem is solved. 4. Update the documentation The document too needs updating to the latest versions of code changes , my experience of writing scientific research journals will ensure a finalized documentation by the end of the my term. 5. Add feature enhancement and solve other issues with musicblocks version 3. During the period of gsoc there are many possibilities of new a idea implementation or any unknown error detection during the continuous process of discussion and evaluation with mentor. In such cases , I am ready to work on that as my project size is medium and I am ready to give extra hours to ensure completion of the project while ensuring it's quality.

<p>Kolibri has a Tasks API that runs time consuming tasks asynchronously outside of HTTP request / response cycle hence unblocking the HTTP connection for other requests.</p> <p>The current Tasks API backend has a very poor consumer experience. Adding new tasks require plugin developers to inherit from <code>kolibri.core.tasks.api.BaseTaskAPIViewset</code> class which adds in multiple extra endpoints for handling of this new task.</p> <p>The current architecture makes it a tiring experience for plugin developers to submit and monitor their custom tasks. It also disturbs the core Tasks API code and has heavily polluted <code>kolibri.core.tasks.api</code> module.</p> <p>This project <strong>fully revolutionizes</strong> the Tasks API backend.</p> <p>This project aims to make it super straightforward for plugin developers to submit, monitor and manage custom asynchronous tasks with a simplified backend architecture.</p> <p>The result is:</p> <ul> <li>Plugin developers can submit any custom task by POSTing to just one endpoint. </li> <li>Plugin developers can manage and monitor their tasks via specific and consistent endpoints.</li> </ul> <p>And most importantly, this makes the Tasks API super duper easy to work with.</p>

The Music Blocks v4 project is a complete overhaul of the original Music Blocks project, which was derived from the Turtle Blocks project. The existing implementation, which started in 2015 using native Vanilla JavaScript, lacks modern front-end tooling and ecosystem standards, leading to difficulties in maintenance and subpar performance. The v4 project uses improved application architecture, modern tools (such as Vite, ESLint, Prettier, Docker, Jest, Cypress, etc.), better languages (TypeScript and Sass), and libraries (React for UI rendering). This will significantly enhance the overall developer and user experience, maintainability, and performance. The proposal focuses on implementing one of the main features of Music Blocks, the "Project Builder", which is currently missing in the new version (v4). The Project Builder is a graphical blocks manager module used to create Music Blocks programs, including interactive blocks like Start, Rhythm, Note, Pitch, Instrument, and many more. These blocks can be dragged, dropped, and clicked to perform actions or open context menus. By implementing the Project Builder feature end-to-end, users will be able to create different musical patterns seamlessly. This will bring the v4 project on par with the capabilities of the old version (v1) and provide a more accessible, efficient, and user-friendly application for users to create music through an interactive web application.

Music Blocks students have no ownership of the projects they create. When a project is saved it lands in a MySQL database they can never see, with no version history and no guarantee it will exist next year. This project completes the migration from that aging PHP and MySQL stack to a modern system backed by GitHub and SQLite, making the transition completely invisible to students while giving every project a permanent, version-controlled home. The work happens in four phases. First, setting up the migration environment with a read-only database connection, GitHub App credentials, and a SQLite database that will power the new backend. Second, running a streaming migration pipeline that processes all 10,000+ existing Planet projects one at a time, pushing each one to GitHub as a repository with full metadata and thumbnail, while skipping duplicates using SHA-256 content hashing. Third, building the seven API endpoints the Planet frontend needs to browse, search, like, and load projects, all backed by SQLite for sub-millisecond response times. Fourth, connecting the frontend to the new backend through a single drop-in adapter file, overhauling the UI with proper modals, a clean commit history timeline, and an interactive Git onboarding walkthrough that teaches students how to save versions, go back in time, and fork projects using Music Blocks language with no Git jargon.

The Music Blocks v4 project is a complete overhaul of the original Music Blocks project, which was derived from the Turtle Blocks project. The existing implementation, which started in 2015 using native Vanilla JavaScript, lacks modern front-end tooling and ecosystem standards, leading to difficulties in maintenance and subpar performance. The v4 project uses improved application architecture, modern tools (such as Vite, ESLint, Prettier, Docker, Jest, Cypress, etc.), better languages (TypeScript and Sass), and libraries (React for UI rendering). This will significantly enhance the overall developer and user experience, maintainability, and performance. The proposal focuses on implementing one of the main features of Music Blocks, the "Masonry Framework" (previously code-builder/project-builder), which is currently missing in the new version (v4). The is a graphical blocks manager module used to create Music Blocks programs, including interactive blocks like Start, Rhythm, Note, Pitch, Instrument, and many more. These blocks can be dragged, dropped, and clicked to perform actions or open context menus. By implementing the Masonry feature end-to-end, users will be able to create different musical patterns seamlessly. This will bring the v4 project on par with the capabilities of the old version (v3) and provide a more accessible, efficient, and user-friendly application for users to create music through an interactive web application.

<p>This project focuses on "Building a Chrome extension for the Way Back Machine, Adding new feature for the way back machine's chrome extension."</p> <p>The original chrome extension was released during January 2017 where the unofficial and pre-release version was developed and released as an open source contribution at mid-2016. This is an extended update for the January 2017 chrome extension of the way back machine. This project has already several repositories in GitHub, where previous selected projects for building a chrome extension for the way back machine alongside with integrations, are available at the link below:</p> <p><a href="http://www.github.com/rakesh-chinta/WayBackMachineChromeExt/" target="_blank">http://www.github.com/rakesh-chinta/WayBackMachineChromeExt/</a></p> <p>The project's Goals and criteria for success:</p> <ul> <li>Integration with the Wayback Machine’s Site Search</li> <li>Support for social sharing, including Twitter and Facebook</li> <li>Display Tweets about a URL for a given date range</li> <li>Provide user with visual feedback based on if we have archived a URL or not</li> <li>Provide user with a one-click Summary view of a given site (Alexa Rank Whois, etc.)</li> <li>Automatically archive URLs that are not in the Wayback Machine</li> <li>Quick access to an overview of all the Archives for a specific URL</li> </ul>

This project aims to develop a versatile mobile application tailored for efficient data management on Firebase databases. Given Firebase's popularity among small to medium-scale projects for its schemaless nature, there is a growing need for a generic mobile editor that enables seamless CRUD operations, independent of the database structure. Our project addresses this need by building a user-friendly and feature-rich mobile application that effectively empowers users to manage Firebase databases. Key Deliverables: CRUD Operations Editor: Functionality for seamless Create, Read, Update, and Delete operations on Firebase databases. Real-time Notifications: Notification system for alerting users to new or edited records, facilitating timely review and modification. User Authentication and Authorization: Secure authentication and authorization mechanisms to control access to the application. Search and Filter Functionality: Advanced search and filter options to locate records based on specific criteria easily. Export and Import Data: Ability to export data in JSON, enhancing data portability. Data Visualization: Data visualization tools to provide visual insights into data transactions and analytics. Firebase Data Audit Logging System: User activity tracking features to monitor and audit interactions with Firebase data. Batch Operations Editor: Support for batch operations to perform CRUD operations on multiple records simultaneously. In Conclusion, our project aims to empower developers with robust tools for managing Firebase databases effectively.

FinBot CTF is OWASP's premier learning environment for agentic AI security, yet it currently operates solely as an offensive arena. Practitioners can exploit vulnerabilities but lack the capability to implement, test, and score defenses against the OWASP Agentic Top 10. This project closes the blue-team loop by introducing a production-inspired, hook-based security framework. The solution is a four-part architecture: (A) a pluggable Guardrail & Detection Framework with pre-tool, post-output, and pre-action hooks that emit a standardized security event model; (B) a Defense-Enabled Challenge Pack converting 3-5 existing offensive challenges (A2: Excessive Agency, A3: Memory Poisoning, A8: System Prompt Leakage) into paired red/blue tracks with integrated defensive scoring; (C) an MCP-Style Scenario Module featuring benign and malicious JSON-RPC tool servers, with detectors for output poisoning, prompt injection via payload, and unauthorized endpoint redirects; and (D) comprehensive Documentation & CI including Docker Compose, contributor guides, and a GitHub Actions test suite. This work transforms FinBot into a complete AI security training platform. Leveraging my prior contributions to the codebase, I will deliver a low-risk, high-impact implementation that equips defenders to build, test, and validate guardrails against real-world agentic threats, solidifying FinBot's role as the practical counterpart to the OWASP Agentic Top 10.

Ultimate Alarm Clock III (UAC) aims to evolve into a production-ready, cross-platform mobile application that delivers intelligent, condition-based alarm functionality. The core problem addressed is the limitation of traditional alarms, which lack contextual awareness and flexibility in triggering based on real-world conditions such as location, calendar events, or user activity. To solve this, the project will enhance UAC with advanced conditional logic and deep integrations, including Google Calendar synchronization, Google Assistant voice controls, and customizable task lists linked to alarms. Additionally, the system will improve reliability through enhanced alarm history logging and debugging tools, while enabling seamless synchronization with a companion app. Infrastructure improvements such as CI/CD pipelines, automated testing, and Play Store deployment workflows will ensure scalability and maintainability. A stretch goal includes developing an iOS version with native background execution capabilities to ensure consistent alarm behavior across platforms. The key deliverables include: Implementation of core features such as calendar-based alarms, voice interaction, shared alarms, and task lists Advanced developer diagnostics via alarm history and logging systems Companion app synchronization with real-time data consistency A robust CI/CD pipeline for automated testing and deployment (Stretch) iOS support with native integrations for reliable background execution Together, these deliverables will transform UAC into a scalable, production-grade application with intelligent, context-aware alarm capabilities and a strong foundation for future development.

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.

The goal of this project is to explore implementing a list-like datatype with enhanced performance. Immutable linked lists are a core datatype in functional programming languages, proving particularly useful in concurrent programs due to the immutability. The most common operations programmers use on an immutable list include random access, sequential accesses, appending, and copy/writes. Unfortunately, sequential access requires a pointer dereference for each node meaning O(n) time which can significantly impact performance. Iteration is necessary for the most popular functions including fold and map and because the datatype is immutable, many changes one may want to make to a list, excluding operations like prepending or removing an element from the head, require allocating a new list which takes O(n) time. This project will design and implement a new immutable linked list datatype with improved performance for the most common operations by leveraging memory/cache locality and mechanical sympathy to improve performance in concurrent programs within the Typelevel ecosystem. The new datatype implements a generalization of the traditional linked list, one where each node contains a constant number of elements rather than one. These nodes, which we call blocks, each contain an array and a pointer to the next block. Deliverables: -Outline direction and priorities for the new datatype based on existing alternatives and how to best integrate in to the greater Typelevel ecosystem (improve performance in concurrent programs by integrating it in to other datatypes ex. Typelevel fs2's Channel) -Research and design the new datatype -Implement the interface for the new datatype -Benchmark and compare theoretical asymptotic bounds against existing immutable linked list-like data structures -Proper documentation and tests

EAT (Eap Additional Testsuite) is a testsuite to develop tests against infinite number of JBoss servers. It’s an innovative tool because it’s creating the test once and testing with any version of the tested software. EAT is available for a number of server configurations and a CI pipeline can be built using the maven tool. The goal of the present project is to extend EAT with new features and tools. The implementation of the project is estimated to last from June to November (Large Size Project) and the timeline is envisaged as follows: During the 1st Phase (June 2022 - July 2022) a snapshot will be added for testing the latest version of JBoss Community Server. The newly added snapshot will be made available for use with the CI builds. Moreover, the extension of EAT with additional multiversion android projects (described at the second phase) will begin. Continuing to the 2nd Phase (July 2022 - September 2022), new multiversion Android projects will be added to EAT. In EAT there is already a basic android multiversion example. This will be extended with other open source android projects demonstrating how EAT can be used to support multiversion real life android projects. Finally, during the 3rd Phase ( September 2022 – November 2022) a multi-version Android application will be developed and added to EAT. This app will enable users to upload and view descriptions and ways of usage for various programs or functions. The users will be able to upload the descriptions of projects related to EAT, how they can be used and other project related information. The documents will be proposed for acceptance and when accepted they will be stored in e.g. google drive, from where they will be accessible for anyone interested.

Video frame interpolation (VFI) refers to the process of increasing the framerate or frames-per-second (FPS) of digital media beyond the initial framerate that is explicitly available (e.g., interpolating 24fps video to 60fps video), and is desirable to be done in real-time using GPU-accelerated algorithms to allow for use in media players such as VLC Media Player. This technique is not available to a broad audience through open source software, with implementations either being proprietary, unsuitable for real-time use, or unsuitable for use in a media player setting. We will solve this problem in libplacebo, VideoLAN's GPU-accelerated video processing library, by implementing a motion compensation-based VFI algorithm, a class of VFI algorithms well suited for real-time performance. This algorithm will require two stages: motion estimation (predicting the motion of pixels from one frame to the next), and motion interpolation (using motion estimates to estimate an intermediate frame between the two). This algorithm will be robust to common VFI challenges, using an image pyramid for large motion handling, and bidirectional motion estimation for occlusion handling. We will clearly document VFI in libplacebo to enable easy integration into software projects, such as media players. We will document the performance, the speed and accuracy of our VFI implementation, using common benchmarks from literature such as Adobe240FPS, or the Xiph dataset, using metrics such as SSIM as well as visually identifying artifacts, to better understand the computational efficiency of our algorithm (performance on 1080p vs 4k resolution, performance when interpolating multiple frames 24->120fps) and accuracy under varying input (large motion caused by high resolution).

<p>The objective of this project is to keep Sugarizer growing by enhancing two core concepts for our deployments: <strong>Security and Availability.</strong></p> <h4>📝 Deliverables</h4> <ul> <li>Fix current issues/features request on <a href="https://github.com/NikhilM98/sugarizer-school-portal-server/issues" target="_blank">Sugarizer-School-Portal</a></li> <li>Update package/chart versions for Sugarizer School Portal.</li> <li>Migrate from deprecated <a href="https://github.com/helm/charts/tree/master/stable/mongodb-replicaset" target="_blank">helm/mongodb-replicaset</a> chart to <a href="https://github.com/bitnami/charts/tree/master/bitnami/mongodb" target="_blank">bitnami/mongodb</a> chart.<ul> <li>While maintaining support on different Kubernetes providers.</li> </ul> </li> <li>Add Two Factor Authentication feature for Sugarizer School Portal to enhance user's security.<ul> <li>TOTP Enable and Disable feature</li> <li>TOTP Verification upon logging in after Two Factor Authentication has been enabled.</li> </ul> </li> <li>Add Two Factor Authentication feature for <a href="https://github.com/llaske/sugarizer-server" target="_blank">Sugarizer -Server</a> Dashboard to enhance user's security.</li> <li>Update the prevailing tests and write tests for new features added.</li> <li>Update Setup Scripts and documentation for <a href="https://github.com/NikhilM98/sugarizer-school-portal-server" target="_blank">Sugarizer School Portal</a></li> </ul> <h4>🎉All of the aforementioned deliverables were attained during GSoC coding period.</h4>

The recent efforts of the `scala-wasm` project have made it possible for Scala to use the WebAssembly Component Model binary format as a compilation target. Although, the implementation has not yet been finished, it is already possible for developers to run Scala code on Wasm runtimes. In order for the Scala language to succeed in the Wasm ecosystem, core libraries which rely on platform APIs must be ported to the Wasm/WASI platform. The goal of this project is to prototype porting the core parts of the Cats Effect and FS2 libraries to the Wasm/WASI platform. The CE runtime prototype will be single-threaded and based around `wasi:io/poll`. The end result is expected to be similar to the (now-replaced) single-threaded LLVM runtime which used a `libuv`-style event-loop. The FS2 porting effort is going to focus on `fs2-core` and the `network` and `file` APIs from `fs2-io`. As a part of this project, a standalone reimplementation of java.nio.file API will be developed as a separate library. Planned Deliverables: 1. A working prototype of Cats Effect's single-threaded runtime compiling and running on Wasm/WASI free of glue JavaScript code. This prototype will serve as a basis for an upstream implementation. 2. Prototype port of the core FS2 module and the fs2.io.file and io.network APIs. 3. A standalone library reimplementation of JDK file APIs for WASI. Initial scope of the implementation will be adjusted to the needs of the fs2.io.file port. 4 An extensive documentation of the project. 5. A report regarding implementation details and findings discovered over the course of the project which will help with further porting efforts of Scala compilers and other platform-dependent libraries. 6. Wasm test environment and CI created for this project can upstreamed to sbt-typelevel so that it can be used in other projects.

<p>Packit (<a href="https://packit.dev/" target="_blank">https://packit.dev/</a>) project has native support exclusively for GitHub now. There were numerous requests from the community to add support for GitLab as well. So here we are - are you up for the challenge to implement support for GitLab in packit-service (<a href="https://github.com/packit-service/packit-service" target="_blank">https://github.com/packit-service/packit-service</a>) so that it can process events from GitLab API and return feedback of successful builds or failed tests back into the merge request? Please bear in mind that GitLab and GitHub use slightly different workflows (pipelines vs. external CI systems) so design work needs to be done before writing code.</p>

<p><a href="https://wiki.debian.org/FreedomBox/Plinth" target="_blank">Plinth</a> is a web interface to administer the functions of the FreedomBox which is a Debian based project, and the main goal of this idea is to make it available for Fedora.</p> <p>To solve this issue, I made up a scenario in this proposal, it can be divided roughly into two parts. The first one is modifying the source code module by module to convert it to RPM-based, including replacing the apt command code with the dnf command code or fit both of them, changing the Deb-based packages into RPM-based packages which play the same roles and testing after each module finished. The second part is a little scattered, including making a RPM package for Plinth and setting up a repo for it in <a href="https://copr.fedorainfracloud.org/" target="_blank">Copr</a>, testing inside a Virtual Machine, and modifying some configuration files and the documents for users to fit the changes of Plinth during this project, at the same time, a new wiki page for Plinth in Fedora is needed.</p>

<h3>Goal</h3> <p>This project aims at fully implementing end-to-end encryption in matrix-python-sdk, following the official implementation guide and making use of the Python bindings already present in libolm.</p> <h4>Rationale</h4> <p>Currently, even though end-to-end encryption has landed in Matrix for over a year, only the three SDK upon which is built Riot on different platforms (JS, Android and iOS) ship with encryption. On desktop, this situation prevents writing clients, bots and bridges that can interact with encrypted rooms in any other language than javascript. Tackling this issue would benefit the matrix ecosystem by seeing more featureful projects emerge in a variety of languages (Python in this case). It also supports the Matrix long-term goal of having E2E encryption turned on by default in private rooms.</p>

<p>Happiness Packets encourages and makes it easier for people to send positive feedback to their peers (anonymously if they like). This project extends Happiness Packets by giving a Fedora Badge to anyone who sends a Happiness Packet to another contributor. To do this we need to add support for Fedora’s authentication system and a fedmsg hook.</p> <p><a href="https://goo.gl/62GwE1" target="_blank">Proposal</a></p>

<p>Most containers currently have a hard-coded default seccomp profile, that is pretty loose and meant to support a wide range of use-cases. The idea of this project is to build a tool that would watch all of the syscalls made within a container, and generate a seccomp profile for this specific container to further harden security. We would want to add a command to the Pod Manager (Podman) tool to basically launch the container and then collect a set of syscalls either through strace, or auditing, or similar tracing technologies.</p>

<p>Linux System Roles is a project related to Ansible, a tool for automating configuration management, application deployment and software provisioning. The goal of linux system roles is to provide a consistent user interface, abstracting from any particular implementation of the linux subsystems, but trying to get the most out of the particular libraries on each one of them.</p> <p>The Network Linux System Role, the one that aims to be improved in this proposal, currently provides a unique configuration interface for network-scripts and NetworkManager. This tool requires many improvements in several areas as it is a relatively new tool.</p> <p>In the proposal, all the issues are addressed, ordered from the tasks that the candidate considered to be better for the start in the project, to the ones that seems more challenging. The main goal of the summer will be to add Pytest support to the integration testing of the project.</p>

<p>Developing software is a creative activity, and being carried out by humans is subject to defects. There are types of defects that can occur in a software’s project, but the ones that interest us most, are those related with the product of the project, that is, the source code. Source code defects can be named as weaknesses, which depending on their characteristics, can lead to security vulnerabilities. In medium and large projects, find such weaknesses by manually inspecting all the modules of the project, it is infeasible, in addition to the fact that active projects launch with some frequency new versions of your product, versions that may come with new weaknesses. During Google Summer of code period, i’m intend to build a system, that permits to run several static analysis tools in source code packages. I’m working in the past few months in Debile, a tool created by the Debian community to make static analysis on Debian packages. Make this tool more generic will permit to analyses others fonts of source code, and this is the main object that i want to reach.</p>