General Announcements & Updates
New Member
Towards the end of 2025, the protocol team were busy balancing protocol improvements and interviewing candidates to fill out the team.
There were a lot of great candidates that had a lot of interest in Radicle and the ecosystem.
You may have seen them in our Zulip working on their interview tasks, coming up with interesting approaches to various challenges we face when improving Radicle.
With that said, we are so glad to announce our new team member, who goes by ade on Zulip!
ade is a software engineer with 18 years of experience based in the UK. His most recent projects before joining Radicle include a realtime collaborative peer-to-peer software, a versioned graph database, and a hard-realtime musical feedback system. He’s a life long open-source contributor and user as well as trainer on testing, software development and complexity.
Releases
Since January, 2026 there has been a lot of work to keep releases coming; continuously improving the Radicle tools along the way.
Radicle 1.6.0
The first release of the year was Radicle 1.6.0.
It brought with it two amazing improvements to the radicle-node binary, and the rad CLI.
Windows support: with this release, we saw the first glimpse at a world where radicle-node runs, natively, on the Windows OS. It opened the gates for further, incremental improvements for being able to run the whole Radicle tool chain on Windows.
clap: the rad CLI was migrated over to use the clap library. This brings more cohesiveness to the CLI commands, stops us from missing arguments in the help output, and opens the door for further benefits, such as manual page generation.
This migration also saw a lot of help from outside contributors taking on part of the workload and submitting patches. It came a lot quicker thanks to their help!
Radicle 1.7.0
The team, and the community, continued to improve things along the way and Radicle 1.7.0 was released in March.
This release contained a security fix, which we will discuss more in the Radicle 1.8.0 section.
The rest of the changes improve things like semantics of blocking misbehaving nodes, fetching references, and decreased I/O load.
Radicle 1.7.1
Radicle 1.7.1 was released soon after, once the team realised that there were two issues with Radicle 1.7.0.
Radicle 1.8.0
The latest release, Radicle 1.8.0, finalised a lot of the security improvements.
With the release, a full disclosure of the vulnerability was published.
To do a short recap here, the vulnerability was classified as a replay attack.
What this boils down to is that an attacker could replay an old version of your references.
This was possible because signatures were made only the over blob of reference and commit pairs.
To safeguard, one would also want to sign a nonce and/or the previous entry in the chain, i.e. the parent commit, in addition.
While implementing these fixes, we also noticed that we were not as protected as we thought from another class of attacks: a graft attack.
A graft attack would mean that an attacker could “transplant” your signed references in another repository.
A defence for both of these attacks is now implemented in a backward compatible manner – to allow node operators to upgrade.
The upgrade of your signed references happens automatically when starting the radicle-node, if you have update to 1.8.0; so do this as soon as possible, if you have not done so already.
HardenedBSD
Recently, the HardenedBSD project ran into issues with their GitLab server.
One of the maintainers of HardenedBSD has hung around the Radicle Zulip for some time now, and even helped with early stress testing of larger repository fetching.
All of this has lead them to exploring Radicle more seriously as home for the HardenedBSD project.
Overall, the progress seems to be very positive, and the community has come out (once again) to support this effort.
Within 24 hours we had multiple community members step up and set up at least six replicas globally.
You can follow along with the progress in the Zulip topic: #General > HardenedBSD Switching to Radicle.
Quarterly Objectives
1.9.0: releasing Radicle 1.9.0 is one of our more immediate objectives.
We have already merged a lot of nice improvements, with a few more in sight.
Of note is integrating with the I2P network (similar to the Tor integration).
We encourage any I2P users to try this out and report their experience, to see if we can further improve this.
Another improvement that we expect to land in time for the release is the addition of symbolic references to the canonical reference namespace of a repository. This means that delegates will be able to edit the repository identity document, specifying the name and the target of a symbolic reference. The target would usually be a regular reference created by a rule. The prototypical example being HEAD -> refs/heads/main (or whatever the default branch is named).
Simulation testing: something we have found hard to do in the past is simulating a Radicle network topology, and seeing how nodes interact with each other. There has been a massive effort to introduce a solution to this. There will soon be a way to spin up a network of nodes, on different versions of Radicle, and test scenarios. In fact, we have already used a PoC of this to test the fixes for the security vulnerability (discussed in Radicle 1.8.0).
Signed push certificates: the approach of signed references has been one way of approaching crypotgraphically signing and securing the set of references we publish on the Radicle network. However, there already exists a native mechanism for doing something similar, which is push certificates. We plan on migrating towards using these to be more in line with Git itself, as well as potentially opening up the door for non-Radicle users to push to Radicle nodes.
Radicle URI: Richard Levitte, a frequent contributor to Radicle and a member of our Zulip community, has worked hard and patiently to put together a RIP (accompanying Zulip topic) that describes a foundational Radicle URI format. This is almost in an accepted state, at which point we will introduce a library component which defines these in Rust. From there, we hope that the Radicle ecosystem will benefit from sharing and experimenting with these URIs, as well as implementing handlers for the existing clients.
Improved foundations: while dealing with the security vulnerability, but also improving the code base in general, we have noticed that a lot of components – and how they interact – are hard to reason about. We are going to make an effort to improve this situation: drawing context boundaries, creating better and isolated packages, and improving the ability to test smaller components. This will start with the storage layer, and move its way up the stack.
Budget
The following is based on a draft, and requires a cross-check from the accountants.
Period: 1 January 2026 to 31 March 2026
| Account | Actual | Budget | Difference |
|---|---|---|---|
| Contributors | CHF 121’048.63 | CHF 134’624.18 | -CHF 13’575.55 |
| Offsites/Events - External | CHF 1’267.79 | CHF 6’250.00 | -CHF 4’982.21 |
| Online Subscriptions | CHF 483.32 | CHF 750.00 | -CHF 266.68 |
| Total | CHF 122’799.74 | CHF 141’624.18 | -CHF 18’824.44 |
Notes
- Negative differences indicate spend below budget for the period.
- Monthly budget allocation means under-spend does not necessarily reflect savings for the full year.