Link Road Plan 22

📜 Archive 🌱 Development
,
1

Cross-post of Road Plan 22 — sourcehut lists

The radicle-link core team has made it into 2022.

== Looking back

2021 has been a little rough. Despite hypertrichotic ruminants, colour-stained
functions, mutants, deorgs, departures, quarantines and overly long lines, the
project came out in a fairly good shape:

  • We have a specification and baseline implementation of
    “collaborative objects”, a way of defining customisable collaboration
    primitives (such as “issues”, “tasks”, “patches”) within a radicle-link
    project.

  • We have fairly usable support for git protocol-v2 within our network
    stack, paving the way for more efficient and reliable replication.

  • We have specified how radicle-link applications should be built and
    interact. Some of the components are already in place (including a
    renaissance of our cli), while others are expected to land soon.

  • We have transitioned away from Github, and built routine in a workflow as
    distributed and decentralised as is possible with existing technology.

=== Highlights, Lowlights

The single biggest cost factor was to work around the flaws and pitfalls of
“async” Rust, and to make that paradigm work with git’s network protocol –
which is in fact fundamentally at odds with this model. We understand that
designing a scalable IO subsystem has its challenges, and that the situation may
improve over time. Yet it does not reflect too well on the community that
the paradigm has become virtually inescapable despite its fairly narrow
applicability. As language users, we want to focus on solving the problem at
hand, using abstractions which do indeed allow us to not worry about their inner
workings. Or be able opt-in to features when and if there is a clear benefit for
our domain.

On the positive side, we learned that the olden ways of patch-based distributed
git are actually quite pleasant. Surely, some things appear quite manual, but
that seems to contribute to the overall quality of the conversation. Being able
to automate and streamline one’s workflow, and not being bogged down by a >500ms
RTT for every single interaction is liberating. As-a-services become just that:
serving a particular purpose.

The experiment was also worthwhile in that it made it a habit to think of
collaboration as happening asynchronous and non-linearly. The premise of
radicle-link is that decentralisation implies distributed-ness, and that this
is not a property which can or should be hidden. “Forkability” is more than
just the right to modify code, and what keeps us going is to push this one step
further by adding commutativity.

== Looking ahead

We think that we are quite close to being able to self-host radicle-link,
which will be our main (and sole) objective for 2022.

For us, self-hosting entails to be able to exchange patches and, most
importantly, discuss them. It also means a way to record and organise what is
being worked on, especially when that doesn’t immediately manifest as code (we
call this “task tracking”, but we don’t mean your grandparent’s task tracking:
think of it more as a tree-shaped way of recording the design process of an
interconnected system).

To get there, we will need to wrap up a few things from last year. Namely:

  • Implement the set of (lightweight) tooling outlined in the AppArch RFC to
    the extent that the system is usable on a day-to-day basis, and package
    releases can be cut
  • Make replication more predictable via interleaving the “push” and “pull”
    modes of git (also referred to as “grafting”), and stabilise the v3 feature

This will give us the baseline to start experimenting with the “patches” and
“tasks” collaborative objects within our own workflow.

Further out, we have compiled a grab bag of improvements to tackle:

  • Simplifying identity handling
  • Gossip fanout reduction and proximity routing
  • UDP hole punching
  • Various git performance measures

On the more experimental side, we are also looking into two projects which could
yield a fair amount of fun:

  1. An editor plugin for collaborative objects.

    We don’t know much about editor plugins, but the new world of Lua-based
    extensions of neovim seems quite exciting.

  2. Automation of mechanical maintainer duties.

    With the help of CRDTs, we believe that it is quite possible to make a
    bors-style merge bot deterministic, allowing it to be executed in a
    distributed, leaderless setting. This would enable shared maintainer
    responsibilities without requiring shared infrastructure, which is
    essential for scaling free and open source projects.

== Feedback

A “living” documentation of our road plan can be found in the TODO.md file at
the root of the radicle-link repository. We’ll adapt this as we go, and make
sure to report significant milestones alongside our weekly releases.

If you have any feedback or questions, feel free to send an email to
~radicle-link/dev@lists.sr.ht (you do not need to be subscribed to post).

In case you are considering to contribute, don’t hesitate to reach out to us. We
are especially interested in people with interest and expertise in git
internals, Windows, or networking (or all of those :)).

5 Likes