we’re excited to share the monthly update from the Alt.-clients team for August.
As it turned out, our focus was on supporting people to join the protocol as a response to the most recent events and code being again taken down from centralized code hosters. We put a lot of effort into onboarding new users and helping them getting started with the CLI and web inteface as the new entry points to the protocol.
In the following sections we’d like to share some items that we also worked on, as well as an outlook of what we plan to work on next month.
Progress this month
- Built a new website and updated the getting started guide
- Made improvements to the project visualization, loading times and UX in general
- Started preparing for local-first usage
- Moved to project listing on the landing page
- Improved build times by re-organizing
rad binaries into commands
- Added various improvements and bugfixes to
rad track and
- Added Docker support
What are we working on
- Onboarding: review learnings from recent support inquiries and discuss improvements
- Web: packaging such that end users can run the interface without any third parties
- CLI: work on install / distribution, fixes, UX and patches
- Seed: work on new p2p node, better telemetry
- Protocol: design work on identity system, storage etc.
Please feel free to share any feedback with us here!
I wanted to post a longer update as well, on the team changes / merge, so here goes.
The (alt-)clients team maintains the following repos:
radicle-interface: the web app (https://app.radicle.xyz)
radicle-network: the web page (https://radicle.xyz)
radicle-client-services: the “seed node”, ie.
With the dissolution of the
upstream teams, responsibility for the
P2P protocol is also moving to the alt-clients team, and given the size,
complexity and limitations of
radicle-link, we have started on a
new proof-of-concept radicle protocol suite, taking all of our
learnings from the last 3-4 years and designing a solution that fits our
The client implementation for this protocol will live in
radicle-client-services under the name
radicle-node. Implementation has
begun and is making good progress, but there are numerous challenges, namely:
- Implementing a gossip protocol that is efficient enough and resilient to DoS.
- In an untrusted, open network, it’s very easy to produce misleading messages
about where some project may be found. We need to work on mitigating this.
- Expiring routing table entries may be challenging, as well as knowing When
a project may be out of sync.
- Scaling Git as a database.
- Git is basically loose refs (files) plus packed refs (packfiles). On the one
side, keeping around hundreds of thousands or even millions of files is
inefficient and not what file-systems were designed for; and on the other
side, the packed ref format doesn’t allow for efficient eg. O(1) lookups.
Since we’re potentially storing thousands or more repositories in one large
monorepo, these numbers quickly add up. It’s worth exploring whether
the monorepo storage itself is a good idea, or whether storage should
involve multiple repos.
- Implementing Git replication between nodes.
- Doing this efficiently, and including validation of identities is tricky,
since we’re operating on potentially the same refs. Proper locking of refs
needs to be implemented, and staging of updates until refs are validated.
- We need a way of dealing with unintentional forks in commit histories.
- Implementing a simpler and more user-friendly identity system.
- We want first class support for public keys as user identifiers, with
the option to support key-rotation etc.
- We’d like to have familiar workflows when editing project identity documents.
We’ve taken all of the above, and in collaboration with the link team, have
agreed on potential solutions, which we are starting to document.
On the team we have the following people working on the following things:
radicle-interface and a little bit of
radicle-client-services with some
radicle-cli, and helping on the new
radicle-cli and a new TUI
@cloudhead: focus on
radicle-node, CLI and reviewing code
@adaszko: release pipeline, build pipeline, CI and seed node operations
With the link team joining us, we’d additionally have:
One of the first tasks they’ll be working on is putting together a set of crates
for working with Git, under
The above team of 10 people, will from this point on be called the “clients”