Alt.-clients Community Update August 2022

Hey everyone,

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!

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-cli: the rad CLI
  • 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
  • @rudolfs: mainly radicle-interface
  • @dave: mainly radicle-client-services with some radicle-cli
  • @slackcoder: mainly radicle-cli, and helping on the new radicle-node
  • @erikli: mainly 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 radicle-git.

The above team of 10 people, will from this point on be called the “clients”
team.

2 Likes