Author(s): @lftherios Type: org Created: 2023-11-06 Status:

What We are building: a local first desktop client on top of the Radicle network with the goal to make Radicle simpler and more accessible to a wider audience of developers. blockchain protocols for a) incentivization and coordination of third party nodes that provide hosting & compute on top of the Radicle network as well as b) integrations with naming protocol & infrastructure with the goal to enhance the developer experience while using Radicle. infrastructure for deploying and operating seed nodes either self-hosted or third party hosted. All of our efforts are guided by the principles of open access anywhere in the world for everyone, with contributions being private by default. Strategies

Author: lftherios Type: executable Created: 2024-04-01 Status:

1/13 As it seems that social graphs are in fashion again in Web3, I would like to share a few of the experiments we've done or observed over the years and the learnings that led to cdf.works and drips.network. 2/13 In 2017, we realized there was potential to use blockchain networks to programmatically share on-chain revenue, either block rewards or fees, with a wider set of participants rather than just block producers. We were not the first ones. @Dashpay was already on it, and @zcash was already doing something similar to fund its core team. 3/13 Our passion for FOSS - the original digital public goods - led us to think that FOSS needs a new sustainable funding model inspired by the above. @cloudhead and I saw an opportunity to introduce a different model to reward software dependencies natively on the internet and we naturally gravitated towards social graphs. 4/13 We shared a manifesto [oscoin.io] and eventually published a paper in 2019 (https://twitter.com/monadic_xyz/status/1108717905527623680) that gathered a lot of attention, praise and criticisms within the Web3 and FOSS communities. The core idea back then was to design a new currency where block rewards would be split between block producers and FOSS projects through a pagerank / trustrank system. 5/13 After running numerous simulations [add link], we realized that it's extremely difficult to design a permissionless system at scale unless you degrade significantly the user experience. You either 1. depend on semi-trusted/secure enclave schemes, which I'm not a big fan of, or 2. introduce a trusted set of participants within the network to review projects that are eligible for funding.

Today I’d like to share a new mechanism that has been powering our work with drips.network. 👩‍💻💡👨‍💻 💧 Continuous Dependency Funding (CDF) is the first continuous mechanism for funding public goods, empowering protocols to to continuously allocate a % of their revenue or assets to their critical dependencies. cdf.works Thread ⬇️ Current PGF mechanisms are round-based, come with a lot of overhead (especially for reviewers) and are hard for recipients to plan their future around. Unlike existing mechanisms that rely on periodic assessments or future projections, CDF operates in the present, allowing protocol ecosystems to dynamically adapt and respond to their evolving needs. 🌱

Over the last few years, the Ethereum community has established a cultural norm of funding public goods. Platforms like Gitcoin and Optimism have been at the forefront, introducing groundbreaking funding models such as quadratic funding and RetroPGF, ushering in a new era of support for public goods. Today, we are thrilled to introduce the first continuous mechanism for funding public goods: "Continuous Dependency Funding" (CDF). How It Works Current public goods funding mechanisms are round-based, come with a lot of overhead (especially for reviewers) and are hard for recipients to plan their future around. Continuous Dependency Funding represents a different take on the problem, empowering protocols to continuously allocate a percentage of their revenue or assets to their critical software dependencies. Unlike existing funding mechanism relying on periodic assessments or future projections, CDF operates in the present, allowing protocol ecosystems to dynamically adapt and respond to their evolving needs.

RetroPGF + Drip Lists = fire emoji Intro As supporters of the inspiring work being undertaken by the Optimism Collective through Retroactive Public Goods Funding (RetroPGF), we've been closely following its evolution. RetroPGF's mission to reward positive contributions within the Optimism ecosystem has not only captured our attention but also earned our admiration. In our pursuit of understanding the process and the rounds' progression, it became evident that while RetroPGF was making strides in incentivizing impact, the lists generated in the process were often based on traditional spreadsheets with broken links, lacking the permanence and accessibility they deserved. To bridge this gap, we embarked on a mission to harness the power of Drips, a tool that not only transforms these lists into permanent fundable lists but also ensures their accessibility to anyone interested in the ongoing journey of RetroPGF. All it takes is a list

In the dynamic realm of blockchain and decentralized ecosystems, the Ethereum community has established a cultural norm of funding public goods. Platforms like Gitcoin and Optimism have been at the forefront, introducing groundbreaking funding models such as quadratic funding and retropgf, ushering in a new era of support for public goods. Today, we are thrilled to introduce the first continuous mechanism for funding public goods: "Continuous Dependency Funding" (CDF). Funding Public Goods with Continuous Allocations Continuous Dependency Funding represents a different take on the problem, empowering Decentralized Autonomous Organizations (DAOs) to continuously allocate a percentage of their assets or income to their critical software dependencies. Unlike existing funding models relying on periodic assessments or future projections, CDF operates in the present, allowing DAOs to dynamically adapt and respond to their evolving needs. In this model, funders specify their critical FOSS dependencies. When these dependencies are onboarded to the system, they are also required to list their own dependencies, creating a network or graph of dependencies. Every time capital flows through this dependency graph, it effectively cascades where it matters the most, through a system of redistribution and splitting.

Introduction Funding Free and Open Source Software (FOSS) has always been a crucial concern for the sustainability and growth of the FOSS ecosystem. While the capital problem is widely recognized and various approaches have been explored, the lesser-known information problem presents its own set of challenges. In this discussion, we will delve into the two facets of funding FOSS, examining how they intersect and influence each other. We will also explore different solutions within the crypto space and discuss our work with Drips that aims to effectively address both the capital and information problems. The Capital Problem The capital problem in FOSS is well-understood. FOSS projects require funding for various purposes, such as development, maintenance, security audits, and infrastructure. Without adequate funding, FOSS projects may stagnate, become unmaintained, or even cease to exist. Traditional methods of funding, like corporate sponsorship, individual donations, and grant programs, have been employed to bridge the capital gap. While these methods have been successful to some extent, they often suffer from issues such as donor fatigue, short-term funding, and lack of transparency in fund allocation. FOSS projects may struggle to secure consistent and sustainable funding, leading to instability and uncertainty. The Information Problem The information problem in FOSS is less explored but equally critical. It revolves around the challenge of determining which FOSS projects deserve funding. With thousands of FOSS projects available, donors often lack the necessary information to make informed decisions. This can result in capital being allocated to projects that may not have the greatest impact, while more deserving projects are overlooked. Looking at Crypto Solutions through the Information Problem

I've done more thinking over the last few days and this is where I stand. I would like to propose that we create a new org within Radworks that will focus on Gateway / Seed Node Infrastructure. Purpose The purpose of this org is to provide gateway infrastructure that makes hosting and fetching content from Radicle simple, performant and accessible for any developer. What For 2024, my proposal is that this org should focus on two services:

Hello everyone, I appreciate the feedback received since my last post. During the Christmas break, I've had the opportunity to reflect further on the above discussion. In my initial post, I focused on retrieval markets for Radicle through incentivized seed nodes. I anticipated that after the release of Radicle 1.0, a global network of seeders would emerge to host and serve relevant content. However, I thought that there may be a distinct market gap for Radicle users seeking a combination of the following attributes: high performance (minimal retrieval latency), availability, and censorship resistance. Through one-on-one conversations with community members, it became clear that:

Problem statement Relying on a single Radicle Seed Node is neither sovereign nor user-friendly or performant. There is currently no market for Seed Node operators. Assuming that a market of Radicle Seed Node operators has emerged that offers hosting and content delivery, switching between them based on $ rates or reputation comes with switching costs and UX complexity. If you rephrase the above in terms of user needs then: As an end-user: I want to have guarantees with regards to availability and performance of Radicle

Author(s): @lftherios Type: Org Created: 2023-11-06 Discussion:

Author: lftherios Type: Treasury Distribution Created: 2023-07-14 Status:

Our strategy for 2023 is solely focused on bringing large, well established funders to the Drips ecosystem, in order to create legitimacy for our tools and mechanism (Dependency funding) and further attract FOSS projects and developers. Our value add to them is the simplicity and streamlined workflow for funding your dependencies with Drips. In short we prioritize the user needs on the funder side and NOT the user needs on the recipient yet. The latter will come in 2024, if and only if we are successful in attracting capital from funders in 2023. Project Objectives Convince the radworks community to fund its dependencies with Drips Learn from the radworks case. Improve the product where needed and build a package of material we can reuse. By the end of 2023 convince 3 well established web3 orgs to fund their dependencies with Drips.

Monday = Map Day 1st session Discussion: Why are we doing this project? Objective: Define a goal for this sprint and put it on the board 2nd session Discussion:

Lost There are a few things that have been bothering me the last few months about how we do things here. This post is not meant to be a criticism of anyone in particular but a wake-up call for all of us. In fact I take my fair share of responsibility for how things work around here. Many of the problems I will outline below are the product of decisions that I led or supported. So instead, I want to start the conversation about how to help this community get back to its mission. Engineering Culture? I will start here: Radicle is an engineering project. Its audience is builders, its contributors are builders. Unfortunately, we haven't succeeded in developing our engineering culture. Some examples of that: Our community calls are 75% non-product & eng topics Our Discord is two channels with technical development and 30 with other topics

User time is precious time. For that reason it's important to have in mind exactly what we are trying to accomplish, before we engage with actual users. To my mind there are three classes of engagements that should be approached differently. 1. Opportunity exploration type of interviews. The objective here is to discover new pain-points, needs and desires users have. 2. Solution validation type of interviews. The objective here is to assess how well a solution we developed satisfies the users' pain-points, needs and desires.

Hiring Priorities - Nov 2022 Alexis: 3️⃣ > 6️⃣ > 1️⃣ > 7️⃣ > 2️⃣ > 4️⃣ > 5️⃣ Ele: 1️⃣ > 3️⃣ > 4️⃣ > 5️⃣ > 2️⃣ > 6️⃣ Abbey: 4️⃣ > 3️⃣ > 6️⃣ > 1️⃣ > 7️⃣ > 5️⃣ AGGREGATED: 3, 1/4, 6 Roles to Open

Hello Radicle Funding There have always been two sides to the Radicle vision: developing sovereign code infrastructure creating new value flows for developers to sustain their FOSS work Today I am announcing the creation of a new core team called Radicle Funding that will focus on the latter. This core team will be responsible for the protocols and user experiences that will enable a more sustainable future for FOSS developers using Radicle.** This change affects the Drips & Workstreams core teams with regards to the way they organize, their strategy and objectives moving forward. In short the Drips & Workstreams core teams are now one team. Hello Radicle Funding team.