Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
One of the key use cases of blockchain integration is asset bridging: in essence, "locking" an asset (typically, a native coin or token) in a smart contract on its authoritative ledger and making available corresponding, newly minted (wrapped/shadow/...) assets on another. By now, bridging is supported by quite mature solutions in the cryptoworld; however, the same is not true for "consortial" distributed ledger technologies. At the same time, such functionality can be expected to become an important requirement in the not too distant future - Analysing the implementation approaches of standard "token models" (ERC20, ERC-721, ... - as far as this has been already done) in native Fabric chaincode and creating conceptual mappings between standard Ethereum token types and Fabric-native assets (including, but not limited to, the different authentication and authorization approaches). - Creating a brief review of the bridging approaches and mature technologies widely used in the cryptoworld. - Performing a requirement analysis for bridging assets from Fabric to Ethereum-based networks (and back), taking into account that the parties performing the bridging have to be explicitly given permission to do so by an authority and may be subject to regulatory requirements. - Based on the available open-source components, designing and prototyping a Fabric-Ethereum bridge fulfilling the requirements As the proposed project bridges multiple fields, creating a centralized solution.
A DID registry is a type of verifiable data registry that can be simply referred to as a role, a system performs to mediate the functionalities like create, verify, update, and deactivate the decentralized identifiers. The mentee will have an opportunity to learn -- The application and automation of the Decentralized Identity Hyperledger Aries and Ursa code base -- Public key cryptography -- Application of Hyperledger Ursa in enabling Zero-Knowledge proof -- Git, Shell Scripting, RUST -- Open source contribution, documentation, and sense of ownership Expected Outcome -- Command-Line utility to automate the process of creating a DID Registry for the members of organizations utilizing Github/Gitlab as Verifiable Credential Registry, On-boarding organizations, and features for easy management -- Proper test cases and documentations -- Codebase maintained with proper read me document
Cryptographic mentorship - Spring/Summer '25 Mission: OpenBao exists to maintain and improve a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. The OpenBao community will provide this software under an OSI-approved open-source license, led by a community run under open governance principles. This mentorship focuses on adding post-quantum cryptography support to OpenBao: https://github.com/openbao/openbao/issues/496
The Karmada Certificate Lifecycle Management project addresses user challenges in certificate management, focusing on mitigating service disruptions and security risks due to expirations. Key goals include implementing a feature for real-time monitoring of certificates with advance notification for upcoming expirations; creating a comprehensive manual for manual replacement with best practices and visuals; allowing configurable certificate validity during deployment via CLI, Helm charts, and Operator; and designing an automated certificate rotation system to streamline certificate maintenance and ensure continuous security across Karmada environments. Expected Outcome: Certificate Visibility Tool/Feature, Manual Certificate Replacement Guide, Updated Installation Tools with Customizable Certificate Validity, and Automated Certificate Rotation Solution Design or Integration Recommended Skills: Golang, Kubernetes Admin, certificate management, Helm. Upstream Issue: karmada-io/community#69
DNS-over-QUIC (DoQ) and DNS-over-HTTP/3 (DoH3) are relatively new protocols for transmitting DNS queries with security and privacy. Additionally, DoQ and DoH3 also offers other benefits such as improved latency and better error detection. The goal of this proposal is to add DoQ and/or DoH3 support to CoreDNS. Expected Outcome: An implementation of DoQ or DoH3 for CoreDNS. A stretch goal of adding both DoQ and DoH3 is also within scope. - Recommended Skills: Golang, DNS. - Mentor(s): Yong Tang @yongtang (yong.tang.github@outlook.com); Chris O'Haver @chrisohaver (cohaver@infoblox.com) - Upstream Issue (URL): https://github.com/coredns/coredns/issues/5583, https://github.com/coredns/coredns/issues/5539
The build infrastructure for istio.io currently carries a complete archived copy of the site for each release of Istio. These archived versions should be separated to their own branch, with only the supported versions published. We should also separate out content which is not version-specific (e.g. the home page, news and blogs) so that only the latest version of this content is visible online. Expected Outcome: Updated publishing infrastructure for istio.io which separates evergreen content (home page, blogs) with versioned content (documentation). Drop-downs per docs page allow switching between the supported versions.
Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.
Hyperledger Umbra is a Hyperledger Lab designed to run unmodified versions of our DLT platforms (e.g. Hyperledger Fabric, Hyperledger Iroha) under a simulated environment with software defined networking for the purposes of running experiments (e.g. scaling experiments, consensus algorithm development, etc) and security audits. Currently Hyperledger Umbra can run unmodified Hyperledger Fabric Docker images and execute a full Fabric network under simulation. Umbra is written in Python and has code for doing virtual network switches and connections. This project is to extend that code to allow for network fuzzing capabilities. The goal is to be able to introduce packet drops, packet delay, packet reordering, as well as unsolicited packets with random/known-bad data. The purpose it be able to test Hyperledger Fabric's resilience to general network "weather" and intentional attacks coming from the network.
For the past two years, the Hyperledger Umbra lab has been worked on by mentees to develop the capability of running the unmodified Hyperledger Fabric docker images under a simulated network environment for the purposes of doing experiments on running Fabric networks in a controlled way. At the end of last summer, Hyperledger Umbra achieved the initial goal of running Fabric networks under simulation. Hyperledger Umbra is useful for doing network-level security fuzzing as well as network scaling experiments and this mentorship is focused on designing and executing scaling experiments. Hyperledger Fabric networks are designed to scale up fairly easily, however nobody has actually tried scaling Hyperledger Fabric to many hundreds and thousands of nodes and done analysis on how it affects the characteristics of the distributed system such as time to reach consensus, time to run an election for block creation, etc. The mentee chosen for this project will work with their mentor to design a plan for setting up, executing, gathering and analyzing data, and reporting the results of scaling experiments run at different scales.
The Hash Time Locked Contract (HTLC) is a well-known pattern for dis-intermediated asset swaps, i.e., as a mechanism to exchange assets between two parties in two different blockchain networks in an atomic manner without a trusted mediator (or trusted third party). HTLC support has been implemented in the Hyperledger Weaver Labs project, with mechanisms to lock, claim, and unlock assets supported in both the contract and higher application layers. At present, the protocol requires several manual steps by the application users carrying out the exchange or agents acting on their behalf. We would like to automate this process as much as possible by augmenting the relay module in Weaver to communicate events and trigger transactions in foreign networks; this requires both research and software development. Further, HTLC is known to have flaws that could violate system integrity properties, because it relies on parties to execute certain actions by a certain timeout or forever lose the opportunity to carry out those actions; this makes the basic protocol intolerant to system crashes. Research is needed to (provably) determine the best way to make the HTLC protocol fault tolerant, using the features of the blockchain networks maintaining the assets and the Weaver relays mediating the exchange. Augmenting the existing HTLC mechanism within Weaver will provide practical validation of this research.
Recently, we have updated the directory and structure of the community's official website documentation. We have listed some documentation improvement tasks. In this project, we would like you to have a thorough understanding of KubeEdge and complete these documentation optimization tasks to help users or developers gain a better understanding of and utilize KubeEdge effectively. Expected Outcome: Document optimization of setup, usage guide, and developer guide, adding more FAQs, etc.
Cross-chain bridges are a vital part of the blockchain landscape as they enable data and value to move seamlessly across different blockchains. Security is of utmost importance in this area, as these bridges can be vulnerable to malicious attacks and manipulation. In addition to securing bridges, measuring their performance and scalability is key to understanding if one is meeting the highest standards and is capable of encountering users' needs. This is mandatory to achieve mass adoption of the technology by single users and businesses. There have been some efforts to design and implement interoperability solutions across different blockchains, some of which are within the Hyperledger ecosystem (see links in the next section). Furthermore, preliminary research has been conducted to benchmark interoperability solutions, however, we feel there is currently a lack of studies that thoroughly compare bridges – used both within and between Hyperledger and public blockchains used in the industry. We aim to address this gap and conduct such evaluation studies, mainly through benchmarking. The goal of this project is to benchmark cross-chain solutions, an essential step for measuring the performance of any solution. As the adoption of cross-chain bridges grows it is increasingly important to have benchmarks to measure cross-chain solutions' performance and security.
CoreDNS (https://github.com/coredns/coredns) is a cloud-native DNS server with a focus on service discovery. While best known as the default DNS server for Kubernetes, CoreDNS is capable of handle many other scenarios within or outside of Kubernetes clusters to make easy infrastructure management. One such case is certificate management. This project is to provide ACME protocol support so that it is possible to have automatic certificate management through CoreDNS. More details and discussions are available in https://github.com/coredns/coredns/issues/3460.
his project aims to develop AI/ML models for NFV-usecases. Any two of the following three problems can be considered. VNF/CNF resource/performance/failure prediction NFV log analysis with NLP Synthetic monitoring and logging data generation using GANs Learning Objectives ML Techniques: Deep_learning. ML model development AI/ML for Telco Usecases. Interested Interns: DO NOT apply through this platform. Due to a bug, please go to https://wiki.lfnetworking.org/x/EasZB. Read the complete description. When you a ready to apply send your application documents to your Mentor(s) and mentorship@lfnetworking.org
Prometheus recently [announced the second version of it's remote-write protocol](https://prometheus.io/docs/specs/remote_write_spec_2_0/), with support for new features on top of performance and cost savings. The work to be done is contribute support for this new protocol in the OpenTelemtry-Collector-Contrib repository, more specifically to the `prometheusremotewriteexporter` component. Expected Outcome: `prometheusremotewriteexporter` component with support for PRW v2.
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.
The Zowe Virtual Desktop needs to provide a way to easily transfer files and datasets from the mainframe to a user desktop and vice versa, while dealing with encoding and security.
The objective of this project is to improve the interoperability of different blockchain networks by developing smart contract gateways that can interact with multiple networks. These gateways will automate, trace, and secure the process of submitting transactions to other blockchain networks. To achieve this goal, the project will involve creating smart contract gateways for various blockchain networks, including those using the same platform, as well as gateways to submit transactions to heterogeneous networks. The initial focus will be on developing gateway smart contracts for connecting multiple separate Hyperledger Fabric networks, and the next step will be to create gateways to connect Hyperledger Fabric to other heterogeneous networks, such as Hyperledger Indy and Besu. The project's primary objective is to evaluate system-level and large-scale integrations, which will be accomplished by setting up an extensive network of blockchains using Hyperledger Fabric as the source blockchain and other networks as destination networks. Overall, the project aims to enhance the efficiency, security, and traceability of cross-blockchain transaction submissions, thereby improving the overall functionality of blockchain technology.
OPNFV VSPERF already includes comprehensive Monitoring solution. However, it lacks the Log-Analysis and Alert-Management solution. This project aims to include log and alert management solutions based on opensources - ELK Stack. This will enhance the ability of VSPERF to: 1. Perform post-test correlation/causation analysis. 2. Adapt the Test-Traffic patterns based on the Alerts. The first aim is to create custom kibana dashboard analyzing and synthesizing VSPERF logs/events. For every test-run, VSPERF generates following logs: 1. vsperf-overall 2. vswitchd 3. trafficgen 4. host-cmds 5. guest-cmds These logs have useful information that can help user to understand the test behavior, and analyze the performance results. VSPERF will have Alerting from the Monitoring component, and lacks alerting from the logs. As the next step, this project aims to use the same information - The logs - and create alerts than will be notified to VSPERF.
The task will be to implement a visual blueprint frontend similar to Blockly, Scratch, or Unreal Engine Blueprints for the Iroha Special Instructions smart contract language. Iroha Special Instructions (or ISI) are a composable smart contract language for Iroha v2 providing an opportunity to execute logic on-chain. In their raw form they represent a syntactical tree, which is not very convenient to write. We think that the structure of the ISI will perfectly match a visual blueprint language and therefore make developing Iroha v2 smart contracts more comfortable for everyone. The app to be developed should allow the user to compose ISI, potentially validating the correspondent types of outputs of each of the blocks. After the program of blueprints is composed, the app should provide a way to transpile the blocks into the file of raw ISI in their byte format. Potentially the app can also act like a client and submit the ISI directly to a Hyperledger Iroha network to be executed right away.
All In is a community dedicated to advancing diversity, equity, and inclusion within open source. All In for Students is a paid, 12-month program for select college students from underrepresented backgrounds. During the program, students will receive professional development training, open source education, a structured 12-week open source project, and ultimately have the opportunity to join one of our corporate partners for a summer internship experience.
Envoy is an open source edge and service proxy, designed for cloud-native applications.
FINOS (FinTech Open Source Foundation - part of the Linux Foundation) is looking for a summer marketing intern to assist with: - Marketing research (members, projects, BD) - Social media (research, operations) - Content for website (research, operations) - Podcast production (research, operations)
The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. Convolution is the core operation of deep learning models and computer vision applications. MLIR supports various convolution operations. Our project is to vectorize them for the RISC-V backend. There are several methods to implement convolution vectorization, such as optimizing nested loops, implementing vectorization algorithm, converting to GEMM, etc. This project needs to choose a vectorization method and implement a conversion pass for the convolution operations. As for the vector semantic support, MLIR has the “Vector” dialect for the general vector abstraction, and it also allows the backend-specific vector dialect, such as the “x86vector” dialect, “arm_neon” dialect, and “arm_neon” dialect. Like these dialects, the project also needs to propose an “RVV” dialect and work with existing dialects and tools. Deliverables: - An MLIR “RVV” Dialect. (Operations in the dialect can support the convolution vectorization) - A conversion pass to vectorize convolution operations in “Linalg” dialect with “RVV” dialect enabled. - A conversion pass to lower the operations in “RVV” dialect to “LLVM IR” dialect. - Unit tests for “RVV” dialect and conversion passes.