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
Web
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
CLI
Improved build times by re-organizing rad binaries into commands
Added various improvements and bugfixes to rad track and rad checkout
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!
radicle-client-services: the “seed node”, ie. radicle-http-api and radicle-git-server
With the dissolution of the link and 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
needs better.
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.
Team
On the team we have the following people working on the following things:
@sebastinez: mainly radicle-interface and a little bit of radicle-http-api