web-development | UCSC OSPO

[Final] Building PeerSky’s Extensions System

Tue, 23 Sep 2025 00:00:00 +0000

Hi everyone, I’m Hanzhong Liu. Over the summer I worked on building the peersky://extensions system for PeerSky browser, a decentralized and privacy-first browser built on Electron.

This post is my final GSoC 2025 update — covering how the extensions manager was designed, the security model behind IPC, the UI for managing extensions, and what’s next for PeerSky.

Project Overview

The new extensions system makes PeerSky behave like a modern browser: you can install extensions from the Chrome Web Store or from local files, enable/disable them, update or uninstall, and interact with their toolbar actions through a puzzle-menu UI.

Key Design Goals

Secure preload-based API exposure via contextBridge
Support for preinstalled, Web Store, and local packages
Toolbar integration with pin/unpin support (up to six)
Robust validation: MV3-only, size caps, zip-slip prevention

Highlights

Preinstalled MV3s

PeerSky now ships with three trusted extensions out of the box:

Dark Reader
Linguist (web page translator)
uBlock Origin Lite

They remain installed by default but can be disabled at any time. This ensures users always have a working baseline without needing to browse an extension store.

Electron Integration

Instead of injecting scripts, the system uses preload + IPC. Each operation is routed through validated IPC channels:

listExtensions, installFromWebStore, toggleExtension, etc.
All methods are scoped to peersky://extensions only.
Rate limiting and size caps are enforced per renderer.

This design makes the surface auditable and prevents privilege leaks.

Browser actions appear in a puzzle menu and can be pinned for quick access:

Up to six pins are allowed
Pinned state persists across sessions.
Popups (e.g., for translators or wallets) open in isolated windows, with OAuth flows preserved via popup guards.

Security Highlights

Installs capped at 60 MB, with early rejection on oversized payloads
5 installs/minute per renderer to prevent abuse
ZIP/CRX extraction hardened against path traversal
MV3 required; permissions validated at install with warnings for risky hosts
Web Store installs use Google-signed CRX verification via electron-chrome-web-store

Example: Installing from the Web Store

Adding a new extension is simple:

Paste a Chrome Web Store URL or ID into the install bar.
PeerSky downloads and validates the CRX.
On success, the extension appears in the grid with toggle, update, and remove options.

Reflection

This project was both challenging and rewarding. Designing an extension system meant grappling with security, IPC design, and user experience at the same time. I learned to think carefully about security management, UI/UX positioning, and design APIs that are auditable.

I’m grateful to my mentor Akhilesh Thite and the UC OSPO team for their guidance and feedback. Their support pushed me to make deliberate technical decisions and communicate them clearly.

You can explore the project here: https://github.com/p2plabsxyz/peersky-browser

Final Report: CarbonCast — An end-to-end consumption-based Carbon Intensity Forecasting service

Mon, 15 Sep 2025 00:00:00 +0000

Hi everyone—this is my final report for CarbonCast, mentored by Professor Abel Souza. Back in June, my goal was simple to say and harder to pull off: help people see when the grid is cleaner and make it easy to act on that information. Over the summer I turned CarbonCast from a research prototype into something you can open, click, and rely on: a containerized backend, a clean API, and a fast, friendly map UI.

Background

CarbonCast forecasts the carbon intensity of electricity (gCO₂e/kWh) using grid data and weather. Earlier versions were accurate but difficult to run and even harder to use outside a research context. My OSRE focus was to make CarbonCast usable for real people: provide a standard API, build a web UI that feels responsive, and package everything so it starts quickly and keeps itself healthy.

Goals

I centered the work around four goals. First, I wanted to ship an end-to-end containerized stack—data collection, validation, storage, API, and UI—that someone else could run without digging through my notes. Second, I aimed to expand coverage beyond a handful of regions so the map would be genuinely useful. Third, I needed to make it reliable, with retries, monitoring, and graceful fallbacks so the system could run for weeks without babysitting. Finally, I wanted to lay the groundwork for a consumption-based signal, because imports from neighboring regions also shape a region’s true emissions picture.

What I built

By the end of the program, CarbonCast runs as a containerized backend + API + web app that you can bring up with Docker. The pipelines now reach 85+ regions, and the UI currently exposes 58+ while we finish integrating the rest. The API offers straightforward endpoints for current conditions and multi-day views, plus region metadata so clients can discover what’s available. The UI presents an interactive choropleth map with a side panel for the energy mix and a simple timeline to move between past, now, and the next few days. To keep things feeling snappy, I tuned caching so “now” data updates quickly while historical and forecast views load instantly from cache. I also added a small “mission control” dashboard that shows what updated, what failed, and how the system recovered, which makes maintenance far less mysterious.

How it works

Fresh weather and grid data arrive on a regular schedule. The system checks each file for sanity, stores it, and serves it through a clean API. The React app calls that API and paints the map. Hovering reveals regional details; clicking opens a richer panel with the energy mix and trends; the timeline lets you scrub through hours naturally. In short, the path is fresh data → API → map, and each step is designed to be obvious and quick.

Behind the scenes, I extended the existing Django backend with a SQLite path so the UI works out of the box on a laptop. For production, you can point the same code at Postgres or MySQL without changing the UI. This choice made local testing easy while leaving room for scale later.

Highlights

A few moments stand out. The first time the dashboard flipped from red to green on its own—after the system retried through a wave of timeouts—was a turning point. Clicking across the map and getting instant responses because the right data was cached felt great too. And packaging everything so another person can run it without asking me for help might be the biggest quality-of-life win for future contributors.

Challenges

The first big hurdle was refactoring the old vanilla-JS interface. The original UI worked, but it was dated and hard to extend. I rebuilt it as a modern React + TypeScript app with a cleaner component structure and a fresh look—think glassmorphic panels, readable color scales, and a layout that feels consistent on both laptops and smaller screens. Moving to this design system made the codebase far easier to maintain, theme, and iterate on.

The next challenge was performance under real-time load. With dozens of regions updating, it was easy to hit API limits and make the UI feel jittery. I solved this by adding a smart caching layer with short, volatility-aware timeouts, request de-duplication, and background prefetching. That combination dramatically reduced round-trips, essentially eliminated rate-limit hits, and made the map feel responsive even as you scrub through time. The result is a UI that can handle many simultaneous updates without hiccups.

Finally, there were plenty of stubborn UI bugs. Some regions wouldn’t color even when data was available, certain charts refused to render, and a few elements flickered or never showed up. Most of this came down to learning React state management in a real project: taming race conditions, canceling in-flight requests when users navigate, and making sure state only updates when fresh data actually arrives. Fixing those issues taught me a lot about how maps re-paint, how charts expect their data, and how to keep components simple enough that they behave the way users expect.

What didn’t make the cut (yet)

I designed—but did not finish—per-region plug-in models so each grid can use the approach that fits it best. We decided to ship a stable, deployable service first and reserve that flexibility work for the next phase. The design is written down and ready to build.

Links and resources:

Project page: CarbonCast
Proposal: https://ucsc-ospo.github.io/report/osre25/ucsc/carboncast/20250710-tanushsavadi/
Midterm blog: https://ucsc-ospo.github.io/report/osre25/ucsc/carboncast/20250803-tanushsavadi/
Backend/API (branch): https://github.com/carbonfirst/CarbonCast/tree/django_apis_sqlite
Frontend/UI: https://github.com/carbonfirst/CarbonCastUI/tree/main

What’s next

My next steps are clear. I want to finish the per-region model plug-ins so grids can bring their own best forecasting logic. I also plan to carry the consumption-based signal end-to-end, including imports and interconnects surfaced directly in the UI. Finally, I’ll harden the system for production by enabling auth and throttling and by moving to a production-grade database where appropriate.

Thank you

Huge thanks to Professor Abel Souza for steady mentorship and to the OSRE community for thoughtful feedback. The most rewarding part of this summer was watching a research idea become something people can click on—and use to make cleaner choices.

Midterm Report: Learning and Building ORB

Thu, 07 Aug 2025 00:00:00 +0000

Project Overview

UC ORB is an open-source platform developed to increase visibility and engagement with open source projects across the University of California system.

By providing a structured and searchable repository browser, ORB makes it easier for researchers, students, and collaborators to discover relevant open source initiatives, track their impact, and connect with contributors. It also helps campuses demonstrate the value of their open source output to potential funders and institutional partners.

Progress So Far

Significant progress has been made in building out core features of the ORB Showcase platform:

Searching and Filtering Options

Users can now search and filter repositories using multiple criteria:

Development Team / UC Campus
Programming Language
License Type
Topic / Domain Area

These filtering tools make it easy to explore the growing set of repositories in a meaningful and personalized way.

Pagination has been added to ensure scalability and smooth performance, even as the number of projects continues to grow.

Repository Details View

Each repository page now displays rich metadata and contextual information, including:

README preview – offering a quick look at the project’s purpose and usage

License – clearly indicating how the project can be used or adapted

Contributors and Funders – acknowledging the people and institutions behind the work

What’s Next

As we prepare UC ORB for public launch, we’re focused on improving the backend workflow and addressing some key challenges:

⚙️ GitHub Workflow Challenges Creating a GitHub-first workflow for adding repositories is powerful, but also tricky:

GitHub Actions cannot be triggered by API calls from a backend directly, which limits automation via server-side tools.

The GitHub bot has permission limitations, especially when it comes to interacting with PRs and validating submissions outside of standard GitHub UI flows.

I’m currently working on designing a more robust and maintainable workflow to handle these edge cases, including:

A standalone script that can add repositories directly to the database, bypassing the need for a pull request and enabling more flexible internal submissions.

Better logging and validation to ensure consistency between the file-based data model and the live PostgreSQL database.

Reflection

This project has been a great learning experience despite challenges with Frontend, Backend, GitHub Actions / Bots and APIs, it’s been exciting to build a platform that highlights open source work across the UC system.

I’m looking forward to what’s coming next as we get closer to launching ORB.

Midterm Report: Learning, Building, and Documenting Brahma

Tue, 05 Aug 2025 00:00:00 +0000

Project Overview

Brahma-XR is an open-source WebXR framework designed for building collaborative virtual environments especially those involving spatial data and scientific visualization.

What makes Brahma powerful is that the same codebase runs seamlessly across both the browser and XR devices like the Apple Vision Pro, Meta Quest 3, and VARJO. This makes it ideal for rapid prototyping and creating cross-platform immersive experiences.

Some of Brahma’s built-in features include:

Grab-and-pull locomotion
Raycasting and interaction
Avatar embodiment
Spatial rendering
Support for geospatial and data-driven visualizations

Brahma is intentionally lightweight, optimized to run even on low-compute devices—making immersive collaboration more accessible to everyone.

What Worked (and What Didn’t)

As Brahma transitioned from a private research repo to a public open-source project, a lot of important foundational work had to be done around documentation, packaging, and example previews.

There are two aspects that make Brahma especially unique:

Bipartite npm package structure – which requires detailed and thoughtful documentation.
Immersive, real-time examples – unlike typical libraries, Brahma’s examples aren’t just static demos. They are live, multi-user XR apps designed to be interacted with.

The first half of the project focused on setting the stage—structuring and preparing the framework for broader use.

🔧 Key Accomplishments

Learning Three.js
I spent time learning the fundamentals of Three.js—how it handles 3D rendering, scene setup, materials, cameras, and animations. I also explored how large-scale Three.js projects are organized, which helped me understand how Brahma’s example apps are built.
Setting up the project structure
I looked at the architecture of various open-source projects and used that knowledge to shape Brahma’s structure. The goal was to align with community best practices while keeping things clean and modular for future contributors.
Understanding npm packaging (especially bipartite)
Since Brahma includes both client- and server-side logic, I spent time understanding how multi-part npm packages are published and maintained. I explored best practices around versioning, distribution, and separating internal vs public modules.
Creating a documentation system
After exploring different approaches (and with my mentor’s help), I set up a static documentation site using JSDoc with the Docdash theme. The current version includes guides, API references, and contribution instructions. This is just the beginning—the docs will evolve as the community grows.

What’s Next

In the second half of the project, I’ll be focusing on:

Building a routing system
For both documentation and example apps, so that users can easily browse through different components and use cases.
Setting up UI and 3D infrastructure
To make it easier for others to start building apps with Brahma by providing clean base layers for interface and spatial development.
Prepping for the first public release
Publishing the Brahma NPM package along with a curated set of featured examples and contributor-friendly documentation—making it easier for developers to get started and contribute.

Reflection

This project has truly been the highlight of my summer. Learning about WebXR, Three.js, and open-source workflows has been both exciting and rewarding. Every challenge taught me something new.

I am specially greatfull to my mentor Samir Ghosh for his constant support, patience, and guidance. It’s been a privilege learning from you!

I’m looking forward to what’s coming next as we get closer to the first public release of Brahma!

Midterm blog: CarbonCast Midpoint Update: From Vision to Reality

Sun, 03 Aug 2025 00:00:00 +0000

A few months ago, I shared my vision for making carbon intensity forecasts more accessible through the CarbonCast project. My proposal under the mentorship of Professor Abel Souza aims to build an API that makes carbon intensity forecasts more accessible and actionable. I had two main goals: expand CarbonCast to work with more regional electricity grids, and transform it from a research project into something that could actually run and be interacted with in the real world.

Today, I’m excited to share that we’ve not only hit those goals – we’ve exceeded them in ways I didn’t expect.

What We’ve Built So Far

Remember how I mentioned that CarbonCast needed to support more regional grids? Well, we’ve gone big. The system now covers 85+ regions across two continents. We’re talking about major US grid operators like ERCOT (Texas), CISO (California), PJM (Mid-Atlantic), MISO (Midwest), and NYISO (New York), plus we’ve expanded into European countries like Germany, France, Spain, and the UK.

But here’s the thing – collecting weather data for carbon intensity forecasting isn’t as simple as just downloading a few files. Each region needs four different types of weather data: solar radiation (for solar power predictions), wind patterns (for wind power), temperature and humidity (for energy demand), and precipitation (which affects both supply and demand). That means we’re managing data collection for over 340 different combinations of regions and weather variables.

The Automation Challenge

When I started this project, I quickly realized that manually managing data collection for this many regions would be impossible. We’re talking about thousands of data requests, each taking time to process, with various things that can go wrong along the way.

So we built something I’m really proud of: an intelligent automation system that handles 95% of the work without human intervention. That means 19 out of every 20 data collection tasks happen automatically, even when things go wrong.

The system is smart about it too. It knows when to speed up data collection, when to slow down to avoid overwhelming the servers, and how to recover when errors happen. We’ve achieved 99% data completeness, which means almost every piece of weather data we need actually makes it into our system successfully.

Making It Production-Ready

The biggest challenge was taking CarbonCast from a research project that worked on my laptop to something that could run reliably for weeks without me babysitting it. This meant building in all the boring but crucial stuff that makes software actually work in the real world.

We created a comprehensive error handling system that can automatically recover from 95% of the problems it encounters. Network hiccups, server timeouts, data format changes – the system handles these gracefully and keeps running.

There’s also a real-time monitoring dashboard that shows exactly what’s happening across all regions. I can see which areas are collecting data successfully, which ones might be having issues, and get alerts if anything needs attention. It’s like having a mission control center for carbon data.

The Dashboard: Mission Control for Carbon Data

Let me show you what this monitoring system actually looks like. We built a comprehensive web dashboard that gives us real-time visibility into everything that’s happening:

The main dashboard showing real-time system metrics and status across all regions

The dashboard shows key metrics at a glance – total requests, completion rates, and active regions. But it goes much deeper than that. You can drill down into individual requests to see their complete lifecycle:

Detailed view of individual data requests showing processing timelines and status

Each request card shows everything from the initial request time to when the data becomes available for download. This level of visibility is crucial when you’re managing hundreds of data requests across different regions and weather variables.

The regional analytics view shows how well we’re doing across different grid operators:

Regional breakdown showing completion status across different electricity grid operators

What I’m particularly proud of is the error handling dashboard. When things do go wrong (which they inevitably do with any large-scale data system), we can see exactly what happened and how the system recovered:

Error tracking and resolution system showing 100% success rate in region mapping

The fact that we’re showing “No unknown regions found” means our coordinate-based region detection system is working perfectly – every weather data request gets properly mapped to the right electricity grid.

The Technical Foundation

Under the hood, we’ve built what I’d call enterprise-grade infrastructure. The system can run autonomously for weeks, automatically organizing data by region and weather type, managing storage efficiently, and even optimizing its own performance based on what it learns.

We’ve also created comprehensive testing systems to make sure everything works reliably. When you’re dealing with data that people might use to make real decisions about when to charge their electric vehicles or run their data centers, reliability isn’t optional.

The architecture follows a modular, service-oriented design with clear separation between data collection, processing, monitoring, and user interfaces. This makes it much easier to maintain and extend as we add new features.

Why This Matters

All of this infrastructure work might sound technical, but it’s directly connected to the original vision: making carbon intensity forecasts accessible to everyone.

With this foundation in place, we can now provide reliable, up-to-date weather data for carbon intensity forecasting across major electricity grids in North America and Europe. That means developers building carbon-aware applications, companies trying to reduce their emissions, and individuals wanting to time their energy use for lower environmental impact all have access to the data they need.

What’s Next: Breaking Down CarbonCast

The next phase is where things get really exciting. Now that we have this solid data collection foundation, we’re going to break down CarbonCast itself into modular components. This will make it easier for developers to integrate carbon intensity forecasting into their own applications, whether that’s a smart home system, a cloud computing platform, or a mobile app that helps people make greener energy choices.

Looking Back

When I started this project, I knew we needed better infrastructure for carbon data. What I didn’t expect was how much we’d end up building – or how well it would work. We’ve created something that can reliably collect and organize weather data across two continents, handle errors gracefully, and run without constant supervision.

More importantly, we’ve built the foundation that will make it possible for anyone to access accurate carbon intensity forecasts. Whether you’re a developer building the next generation of carbon-aware applications or someone who just wants to know the best time to do laundry to minimize your environmental impact, the infrastructure is now there to support those decisions.

The vision of making carbon data accessible and actionable is becoming reality, one automated data collection at a time.

Impact Beyond Research

This work builds directly on the foundation of Multi-day Forecasting of Electric Grid Carbon Intensity using Machine Learning, transforming research into practical, real-world infrastructure. We’re not just making carbon intensity forecasts more accurate – we’re making them accessible to everyone who wants to reduce their environmental impact.

The open-source nature of CarbonCast means that anyone can run, contribute to, and benefit from this work. Whether you’re a developer building carbon-aware applications, a policymaker working on grid decarbonization strategies, or a sustainability-conscious individual looking to reduce your carbon footprint, the tools are now there to make informed, impactful choices.

Looking ahead, I’m excited to see how this infrastructure will enable the next generation of carbon-aware computing and smart energy decisions.

[MidTerm] Building PeerSky’s Settings System

Thu, 24 Jul 2025 00:00:00 +0000

Hi everyone, I’m Hanzhong Liu. My project focuses on building a secure and extensible peersky://settings system for the PeerSky browser, a decentralized and privacy-first browser built on Electron.

This post is a midterm check-in covering what’s been implemented so far — from IPC architecture to real-time theme and wallpaper updates — and a preview of what’s coming next.

Project Overview

Peersky’s new settings system is designed to unify browser preferences (themes, search engine, appearance, extensions, etc.) into a single modular interface. It’s accessible via a protocol route (peersky://settings) and built using web-standard HTML/CSS, scoped APIs, and Electron’s context isolation model.

Key Design Goals:

Secure preload-based API exposure via contextBridge
Fast access to user preferences with zero-flicker wallpaper updates
Extensibility for bookmarks, future plugins, and privacy tools

Midterm Progress Highlights

Electron Integration

Rather than using webFrame.executeJavaScript(), I implemented preload-scoped APIs using contextBridge and ipcRenderer to prevent injection vulnerabilities and ensure synchronous availability during early page load. Each internal protocol (settings, home, bookmarks) is granted its own API access level.

Code: src/pages/unified-preload.js

Modular Settings Page

The UI lives in a single HTML file with sidebar-based navigation (Appearance, Search, Bookmarks, Extensions). Each section updates independently using event-driven IPC and live sync.

Wallpaper & Theme Switching

Supports both built-in wallpapers and custom uploads
Background applies instantly using sendSync() during preload
Themes (light, dark, system) are controlled using root-level CSS variables and real-time IPC events

Cache & Search Engine

Added IPC handler to clear both Electron session and P2P cache directories (ipfs/, hyper/)
Settings API allows switching between DuckDuckGo, Ecosia, and Startpage via dropdown

Example: Adding a New Setting (`autoSave`)

I also documented how developers can add new settings like autoSave using:

settings-manager.js for default values and validation
Preload event listeners (onAutoSaveChanged)
UI toggles and save logic in settings.js

Documentation link: Settings Guide

Reflection

I’m really thankful for the mentorship I’ve received from Akhilesh Thite. His guidance has been the perfect balance of autonomy and support. He challenged me to reason clearly about technical choices, especially when I thought some of them are minor and not worthing paying attention to. His feedback helped me write cleaner, better-scoped code. This project has helped me grow as a software engineer in ways I didn’t fully anticipate, but I’ve enjoyed it so so much.

You can explore the project here:
https://github.com/p2plabsxyz/peersky-browser

CarbonCast

Thu, 10 Jul 2025 00:00:00 +0000

As part of the CarbonCast project, my proposal under the mentorship of Professor Abel Souza aims to build an API that makes carbon intensity forecasts more accessible and actionable.

Under the mentorship of Professor Abel Souza, my proposal is centered around building upon CarbonCast to create an API to enable user access and utilization of energy data in optimizing their electricity consumption. Before diving into the details of the project, I’d like to share a bit about my background.

About Me

Hi, I’m Tanush—a rising senior at the University of Massachusetts Amherst, majoring in Computer Science and Mathematics and graduating in Spring 2026. Currently, I’m an AI Intern for the Commonwealth of Massachusetts Department of Unemployment Assistance, where I’m developing an end-to-end retrieval-augmented generation (RAG) chatbot on AWS.

In the past, I’ve contributed to CarbonCast in a different capacity, designing a user interface to help visualize carbon intensity forecasts. I also worked at MathWorks as a Machine Learning Intern, where I collaborated in an AGILE environment to design and deploy predictive models that improved precision torque control and dynamic responsiveness in motor-driven robotic and industrial systems.

I’m excited to bring these experiences to this year’s GSoC project, where I’ll be building tools to make carbon data more accessible and actionable for everyone.

What is CarbonCast?

CarbonCast is a Python-based machine-learning library designed to forecast the carbon intensity of electrical grids. Carbon intensity refers to the amount of carbon emitted per kilowatt-hour (kWh) of electricity consumed. Developed in Python, the current version of CarbonCast delivers accurate forecasts in numerous regions by using historical energy production data of a particular geographical region, time of day/year, and weather forecasts as features.

However, there is no easy way to access, visualize, and utilize the data through a standard interface. In addition, much important information is left out and is not available to users. For instance, electricity grids often import electricity from neighboring regions, and so electricity consumption depends on both electricity generation and imports. Moreover, it is imperative for each energy source to utilize a tailored predictive mechanism. Consequently, any carbon optimization solution trying to reduce carbon emissions due to its electricity consumption will benefit more from following a consumption-based carbon intensity signal.

Unlike other third-party carbon services, CarbonCast’s model is open-sourced, allowing users to study, understand, and improve its behavior. This transparency invites public collaboration and innovation. It also contrasts sharply with proprietary services that often withhold both the logic behind their models and the data they are trained on.

Why This Matters

Electricity usage is one of the largest contributors to carbon emissions globally. Carbon intensity—the amount of carbon emitted per kilowatt-hour of electricity consumed—varies based on how electricity is generated and demanded (for example, coal versus solar). With better visibility into when the grid is cleaner, individuals and organizations can shift their energy consumption to lower-carbon periods and lower prices. This enables everyday energy optimizations without compromising comfort or productivity.

By improving CarbonCast’s accessibility and functionality, we are helping people and institutions answer questions like:

When is the best time to charge my EV to reduce environmental impact?
Can I run my energy-hungry server jobs when the electricity is cheaper?
How do I actually reduce my emissions without guessing?

By providing clear, accurate forecasts of carbon intensity, CarbonCast can help users make informed decisions to optimize their energy footprint and reduce emissions without sacrificing convenience or productivity.

What I’m Building

The plan for this summer is to develop the backend API services for CarbonCast. This summer, I’m focused on two major goals:

Geographical Expansion

I am extending CarbonCast’s compatibility to support more regional electricity grids. Each model will be customized for local grid behavior and renewable energy characteristics. This involves tuning the model pipeline to adapt to each region’s energy mix, weather patterns, and reporting granularity.

System Refactoring and Modularity

The original CarbonCast system was built as a research artifact. To refine it into production-grade infrastructure, I am refactoring the codebase to improve modularity. This makes it easier to plug in new regions, update forecasting algorithms, and integrate new data sources.

Impact Beyond Research

The paper that inspired this project, Multi-day Forecasting of Electric Grid Carbon Intensity using Machine Learning, pioneered the idea of forecasting carbon intensity over multiple days using a hierarchical machine learning model. This goes beyond the typical 24-hour day-ahead models that are common in the industry and allows for better planning and longer-term decision-making.

CarbonCast builds directly on that foundation by transforming research into practical, real-world infrastructure. It is an open-source library that anyone can run, contribute to, and benefit from. Whether you’re a developer building carbon-aware applications, a policymaker working on grid decarbonization strategies, or a sustainability-conscious individual looking to reduce your carbon footprint, CarbonCast provides the tools to make informed, impactful choices.

Looking Ahead

I am excited to contribute to a project that blends machine learning, systems engineering, sustainability, and public impact. My goal is to help make it easier for everyone to see, understand, and act on their carbon footprint while also providing the “visibility” people need to take meaningful, informed actions.

Implement Web Extensions & System Settings Integration

Sun, 15 Jun 2025 00:00:00 +0000

Hi! I’m Hanzhong Liu, a Computer Science student at Fordham University with a minor in Business Administration. My interests lie in distributed systems, backend engineering, and decentralized tools—especially systems that prioritize user autonomy and privacy.

This summer, I’m contributing to the Peersky project as part of OSRE 2025 through Google Summer of Code. My project, “Implement Web Extensions & System Settings Integration,” will add full support for local browser extensions in Peersky, allowing users to customize their experience without relying on centralized extension stores.

Deliverables include an extension loader, drag-and-drop installation for .zip and Git-based extensions, manifest validation, sandboxing, and a unified peersky://settings page for managing everything from themes to privacy tools. Pre-installed extensions like uBlock Origin and DScan will be bundled by default.

You can read my full proposal here. My mentor for this project is Akhilesh Thite.

I’m excited to help build tools that empower users to take control of their browsing experience—and to contribute to the vision of a more decentralized web. Looking forward to the summer ahead!

Into the VR-Verse: My GSoC Adventure Begins!

Sun, 15 Jun 2025 00:00:00 +0000

Hello! I’m Kajal Jotwani, an undergraduate Computer Science student from India who is passionate about building creative, interactive technologies and contributing to open source. This summer, as part of Google Summer of Code 2025, I will be working on the Brahma / Allocentric WebXR Interfaces project under the mentorship of Samir Ghosh. You can read my complete proposal here.

This project focuses on creating a formalized framework for building collaborative and cross-platform WebXR-based experiences. As part of its first public release of Brahma- a lightweight open-source toolkit, our goal is to formalize the framework, create documentation, and implement example applications like multi-user games and scientific visualizations. This will help make Brahma extensible and accessible for a wider developer community.

I’m excited to be working on this project and will be documenting my journey, learnings, and progress here throughout the summer.

Open Source Repository Browser

Sun, 15 Jun 2025 00:00:00 +0000

Hi! I’m Param Arora, a Computer Science student at Manipal Institute of Technology. My interests lie in backend engineering and AI.

This summer, I’m contributing to the ORB project as part of OSRE 2025 through Google Summer of Code.

My project, “UC Open Source Repository Browser [UC ORB]”, is a discovery platform that maps and categorizes open source projects across the UC system. It offers a comprehensive web interface with intuitive search, advanced filtering capabilities, responsive design, and integrated visualizations of project metrics.

You can read my full proposal here. My amazing mentor for this project is Juanita Gomez.

Looking forward to the summer ahead!

Causeway: A New Approach to Web Development Teaching

Thu, 20 Jun 2024 00:00:00 +0000

As part of the Causeway team, my proposal under the mentorship of Professor David Lee aims to enhance web development education through situated learning.

Causeway addresses shortcomings in current online coding tutorials by offering a comprehensive approach to web development using an Angular, RxJS, NgRx, and Firebase stack. By breaking down the complex task of creating a website down into discrete chunks (micro-roles) and tracking individual progress, students can be assured they are acheiving their desired learning goals. With this project, our team hopes to demonstrate the potential of sitatuted learning – tacit knowledge picked up within a real-world context – instead of content-based learning approaches used in sites like Khan Academy and Coursera.

Over the course of this summer, we plan on reinvigorating the pre-existing v1 platform through the addition of new features such as dashboards, quizzes, and in-depth walkthroughs of new potential projects for users to implement. The platform will also leverage the Stackblitz WebContainer API and Firebase Cloud Functions to run full applications in the browser for interactive and secured learning.

Causeway: Learning Web Development Through Micro-Roles

Mon, 03 Jun 2024 00:00:00 +0000

Hello! My name is Rishi and I will be contributing to Causeway, a platform for learning to develop web applications using an Angular, RxJS, NgRx, and Firebase stack , during Google Summer of Code 2024. My project is Causeway : Improving the Core Infrastructure and Experience ! , mentored by David Lee. This project aims to modernize the platform by adding various login options (Google, GitHub, email/password, passwordless) using Firebase Authentication, enhancing the landing page with an about section and improved UI, and introducing section quizzes via Firebase Firestore and Cloud Functions. It also involves developing user and learning dashboards with Angular Material UI and Firebase Cloud Functions, improving the overall UI design with application walkthroughs, providing an introductory demo for new users, incorporating generative AI features, automating deployment and monitoring with Vercel Bot, and adding contact and feedback options. These enhancements will boost user engagement, usability, and the overall learning experience. My proposal can be viewed here!

Causeway is a platform for learning to develop web applications using an Angular, RxJS, NgRx, and Firebase stack. It aims to bridge the gap in online coding tutorials by providing a holistic approach to web application development, breaking down the process into a hierarchy of micro-roles. This structure offers learners a clear pathway for learning and translates into a clear process for developing an application. In the longer future, this approach will enable learners to contribute to projects by taking on micro-roles for yet-to-be-developed projects. The platform leverages the Stackblitz WebContainer API to run full applications in the browser for interactive learning.

web-development | UCSC OSPO

[Final] Building PeerSky’s Extensions System

Project Overview

Key Design Goals

Highlights

Preinstalled MV3s

Electron Integration

Toolbar & Puzzle Menu

Security Highlights

Example: Installing from the Web Store

Reflection

Final Report: CarbonCast — An end-to-end consumption-based Carbon Intensity Forecasting service

Background

Goals

What I built

How it works

Highlights

Challenges

What didn’t make the cut (yet)

Links and resources:

What’s next

Thank you

Midterm Report: Learning and Building ORB

Project Overview

Progress So Far

Searching and Filtering Options

Repository Details View

What’s Next

Reflection

Midterm Report: Learning, Building, and Documenting Brahma

Project Overview

What Worked (and What Didn’t)

🔧 Key Accomplishments

What’s Next

Reflection

Midterm blog: CarbonCast Midpoint Update: From Vision to Reality

What We’ve Built So Far

The Automation Challenge

Making It Production-Ready

The Dashboard: Mission Control for Carbon Data

The Technical Foundation

Why This Matters

What’s Next: Breaking Down CarbonCast

Looking Back

Impact Beyond Research

[MidTerm] Building PeerSky’s Settings System

Project Overview

Key Design Goals:

Midterm Progress Highlights

Electron Integration

Modular Settings Page

Wallpaper & Theme Switching

Cache & Search Engine

Example: Adding a New Setting (autoSave)

Reflection

CarbonCast

About Me

What is CarbonCast?

Why This Matters

What I’m Building

Geographical Expansion

System Refactoring and Modularity

Impact Beyond Research

Looking Ahead

Implement Web Extensions & System Settings Integration

Into the VR-Verse: My GSoC Adventure Begins!

Open Source Repository Browser

Causeway: A New Approach to Web Development Teaching

Causeway: Learning Web Development Through Micro-Roles

Example: Adding a New Setting (`autoSave`)