Explore Projects

Rocket.Chat currently uses multiple virtualization patterns across list-heavy UI surfaces, especially in core room and contextual views. This makes scrolling behavior, pagination, testing, and future maintenance less consistent, and increases the effort required to review or extend list implementations. My project will establish a shared virtualization baseline for Rocket.Chat using a reusable wrapper integrated with the existing OverlayScrollbars-based scrollbar system, then apply that baseline to a focused set of core user-facing surfaces such as Threads, Discussions, and Message Search. The implementation will build on existing Rocket.Chat frontend patterns, including TanStack Query-based pagination hooks and shared query/cache infrastructure, so the migration can be incremental rather than disruptive. The main deliverables are: a reviewed shared virtualization abstraction suitable for merge, a reusable migration pattern for flat list surfaces, migrations of selected core components, focused test coverage for the wrapper and migrated screens, and contributor documentation covering wrapper usage, pagination integration, scrollbar wiring, and testing. If time allows, I will also migrate an additional core surface such as Room Files or prepare the path for future grouped-list migrations.

Playground 2.0 is an updated version of the Rocket.chat's Playground, which is an app development platform for creating custom apps and integrations. The new version includes several features to accelerate the development process and make it more visual. The first feature is the addition of an example section, which includes a collection of templates that can be used as a starting point for app development. This will save time and effort for developers who are new to app development and help them get started quickly. The second feature is the implementation of a project concept where multiple screens can be grouped, saved, and revisited at a later time. This will enable developers to work on different parts of the app separately and easily switch between them. The third feature is the use of the flow concept from https://reactflow.dev. This will allow each project to be represented as a flow, with each screen represented by a block. Actions can be connected to other blocks to visualise the app's lifecycle. This will make the development process more visual and easier to understand. The last feature is the ability to "compile the flow" and run it as a demo. This will allow developers to quickly present a mock or app to validate its usefulness. This will save time and effort for developers who want to get feedback on their app quickly. Overall, Playground 2.0 is an app development platform that makes the development process faster, more visual, and easier to understand. It includes several features that will help developers create custom apps and integrations quickly and efficiently.

<p>This proposal is based on a combination of 2 project ideas &amp; 3 tasks.</p> <p>1) ScummVM GUI is currently based on char size strings, so it relies on code pages. There are a <em>lot</em> of character sets and ScummVM supports a wide variety of languages. This means due to the multitude of codepages, we're using:</p> <ul> <li>Unnecessary memory and performance</li> <li>Low compatibility between different languages</li> </ul> <p>The main idea of the of this project is to shift GUI to Common::U32 Strings, which will make our GUI:</p> <ul> <li>Unicode friendly, thus reducing the vast codepages just to one big codepage</li> <li>Better compatible</li> </ul> <p>2) With enhancing our GUI, we're also trying to add support for RTL Languages.</p> <p>3) ScummVM Project has Dynamic Plugins system in place, which allows lower-end platforms to be capable of running ScummVM. However, when we detect games - these plugins are loaded one by one and the relevant detection features are called from the individual engines. Since this is very slow, the main idea of this project is to statically link detection features into the executable so</p> <ul> <li>Games are detected without loading of a plugin</li> <li>Game detection is faster</li> <li>Other parts remain as-is, so our low-end platforms will gain performance boosts</li> </ul>

<p>Servo has support for Web Workers, and the new Fetch Api whose development is in progress is another new standard, that aims to replace XMLHttpRequest (XHR), and provides a cleaner api for anything involving requests and responses.The Fetch api spec also has a subsection which details on handling fetch calls within a service worker context. <a href="https://slightlyoff.github.io/ServiceWorker/spec/service_worker/" target="_blank">Spec</a> Service Workers are the new standard, for modern web apps, which aims to bring native app like experience to browser based apps, by providing a programmable api, for caching certain paths of pages, ,manipulating routing within an application,intercepting network requests according to user logic.</p> <p>Servo has a partial implementation of Fetch api, but the Service Worker api’s are currently missing and if implemented, Servo will be able to intercept network calls made from within the Service Worker’s context, the “handle_fetch” subsection of the Fetch Spec, is to be implemented. <a href="https://fetch.spec.whatwg.org/" target="_blank">Spec</a></p> <p>My project is to have a partial implementation of the new Service Worker Api and its helper interfaces, in Servo. The project is focused on working on parts of the Service Worker Specification which revolves around intercepting network requests.</p>

<p>Open Robotics creates open-source software and hardware platforms for robotics research and education.</p><p>Create real-time WebSocket node telemetry tools for Gazebo robot simulations in modern web browsers.</p><p><br></p><p><strong>Deliverables:</strong></p><ul><li>WebSocket telemetry bridge in Python/ROS 2.</li><li>TypeScript browser 3D node viewer component.</li></ul>

This project aims to extend the plot module by implementing the missing building blocks needed for end-to-end chart creation. The work will focus on improving how data is mapped to visual representations, adding support for a broader range of visual elements, and enabling better composition of charts. Additionally, the project will introduce features for interactivity, layout management, and common data processing operations, making the API more practical for real-world usage. Each component will be developed with proper testing, documentation, and performance considerations to ensure reliability and consistency with the stdlib ecosystem. By the end of the project, users will be able to programmatically generate complete and reusable visualization specifications using a modular JavaScript API, without relying on manually written JSON.

MUIOGO is an existing Flask and JavaScript application that provides a browser-based interface for running CLEWS energy-environment models. This project extends it in four directions. 1) Cross-platform hardening: fixing path assumptions, making configuration runtime-configurable, and setting up CI on macOS, Ubuntu, and Windows. 2) Building a full OG-Core UI module with parameter input forms, scenario management, run execution, and interactive Plotly results visualization, so that OG-Core has the same level of browser-based support that CLEWS currently has. 3) A coupled mode interface providing a guided workflow where one model's outputs feed into the other, with validation, multi-stage progress tracking, and combined results display. 4) A converging mode interface enabling iterative execution of both models until results stabilize, with live convergence charts, configurable tolerance, and early stopping. The project concludes with PyInstaller packaging for all three platforms, an automated GitHub Actions release pipeline, and user and developer documentation. Deliverables include a CI pipeline on three operating systems, working OG-Core standalone workflows, coupled and converging execution UIs, downloadable platform-specific installers, and complete documentation.

<p>Data Object Service (DOS) is an emerging standard for specifying location of data across different cloud environments. The goal of DOS is to create a generic API on top of existing object storage systems so workflow systems can access data in a single, standard way regardless of where it's stored. This project is an implementation of a DOS server, which is capable of exposing and hosting both public and private data from any cloud environment. In particular, PGP Canada and GCP.</p>

This proposal aims to enhance the infrastructure of PolyPhy by developing new architecture and maintaining existing codebases. The project will involve refactoring the current codebase, creating interfaces for PolyPhy that enable access to its features through Python/Jupyter code and command line, configuring the codebase according to the team's needs, and improving the performance, security, and documentation of PolyPhy. To achieve these goals, I will refactor existing codebase and enhance the PolyPhy package, create a common API to allow multiple and dynamic changes to the pipeline, implement efficient CI/CD workflows for the PolyPhy repository, including unit and integration tests, and create a public pip package release for PolyPhy. Additionally, I will implement a monitoring and logging system to detect and diagnose issues with the software in production, perform profiling and load testing to improve code quality and performance, and establish security best practices such as code reviews, vulnerability scanning, and penetration testing. The expected result of this project is a robust and user-friendly PolyPhy package that can handle different parts of the pipeline, has an efficient CI/CD workflow, and adheres to security best practices. The package should be Dockerized, and the build process should be automated using Docker tools, which will help in maintaining consistency across multiple platforms. Moreover, there should be a Github page workflow for the PolyPhy website deployment, and an issues template should be created to promote people from opening issues on the repos. Finally, the documentation should be improved, and a release management process should be established that includes versioning, release notes, and changelogs.

Implement distributed asynchronous island-model genetic algorithms and GPU-accelerated gradient descent for interplanetary trajectory design.

<p>An asymptotic expression typically contains exact terms and O-terms, for example n3 + 2n2 + O(n). The basic framework for this asymptotic ring is already implemented. The main aim of this summer of code project is to extend its functionality up to the point where asymptotic expressions with explicit constants are fully supported. In his book, “Asymptotic Methods in Analysis” on page 5, deBruijn calls it an “L-term”, but we will call it “B-term”. B_{20}(3z) is a B-term, which stands for an expression which is bounded in absolute value by 3|z| for |z| ≥ 20. Sometimes, in research, it is important to know from which values of the variable on the asymptotic expression has enough precision to decide wether it is larger than a given bound. This cannot be achieved by O-terms (because the unknown implicit constant might be very large). For example, the average number of comparisons of classical quicksort is 2n log n + O(n). When comparing with recent variants, such as dual pivot quicksort with average number of comparisons 1.8n log n + O(n), it is interesting to know how large the O-terms are in order to know when dual-pivot quicksort will be more efficient than classical quicksort.</p>

Apply unsupervised machine learning models to detect power degradation and temperature anomalies across orbiting open satellites.

Enhance high-dimensional vector search indexing throughput for retrieval-augmented generation (RAG) applications.

Develop distributed edge caching strategies using Web Standard Cache API for sub-50ms storefront responses.

DigiKam’s Advanced Search is powerful, but translating a natural-language request into the right combination of structured filters can be difficult for many users. This project will add a natural-language input to digiKam’s Advanced Search so users can describe queries such as “landscape photos with red labels taken in Paris last summer,” which will then be converted into editable search criteria such as tags, labels, dates, and locations. The implementation will use a lightweight local language model, structured intent parsing, capability-based resolution into supported digiKam search fields, ambiguity handling for unclear terms, and caching for repeated queries, while reusing digiKam’s existing model-management infrastructure. The deliverables include the Advanced Search UI integration, the local inference and parsing pipeline, criteria resolution and validation, safe clarification behavior, and end-to-end integration with digiKam’s existing Advanced Search workflow.

Optimize Phoenix channel broadcast fanout for millions of concurrent websocket connections across global edge nodes.

Embed Wasm runtime filters into Vector data routing topologies for custom metric transformations at line rate.

This project accelerates the convolution core of the Active Segmentation Plugin (ASP) in ImageJ by offloading its most compute-intensive pixel operations to parallel hardware using TornadoVM. The goal is to achieve significant speedups without altering existing functionality or behavior. The approach focuses on identifying CPU bottlenecks, converting them into accelerator-friendly kernels, and executing them through a reusable TornadoVM pipeline. A strict correctness-first methodology ensures all accelerated outputs match the CPU reference in terms of boundary handling and numerical accuracy before any performance gains are considered. By integrating a robust, reusable parallel execution layer with safe CPU fallback, this work transforms ASP’s performance while preserving its reliability—laying the foundation for scalable acceleration across multiple filters and larger image-processing workflows.

Build local hardhat and foundry simulation plugins to calculate dynamic token bridge and gas cost bounds.

<p>Cubesat are now widespread as affordable tools for teaching and researching for Universities and Research Centers. Although they are simple platforms, their complexity can be increased in a budget. One of the elements that increase the capabilities of cubesats is the incorporation of an attitude (and orbit) control system (AOCS). Simulation of the capability of these subsystems is the first step to assess the convenience to include such subsystems in a platform.</p>

<p>The project aims to analyze a satellite set of telemetry to understand links and dependencies among different subsystems. The project should be able to demonstrate an understanding of the links between the different behaviour changes of each telemetry within a satellite or within a set of external sources of information (mission plan, solar aspect angles, ephemerides, etc.) in order to rapidly characterize future debris events to support risk analysis, close approach analysis, collision avoidance maneuvering, forensic analysis and other decision making. Machine learning can be used to learn the different link models and storage of acquired knowledge should be stored in a graph (Bayesian network). The intermediate and final output should be represented as data interpretable by a visualization interfaces, preferably in JSON.</p>

Train convolutional neural networks to detect solar flare magnetic field twist precursors on real-time SDO / PROBA-2 satellite coronagraph feeds.

<h3>Development of vuln, exploit, auth and malware scripts</h3> <p>I will seek to research on the newest vulnerabilities that have been made public and either a) translate the existing PoC into a NSE Lua script or b) implement the thing myself on Lua, if no existing PoCs exist yet and the vulnerability is widespread enough.</p> <p>The metric which I will benchmark myself against is 1 high-impact/high-difficulty script per week, as if time allows I will implement other scripts as well.</p>