Link March 2022 Community Update

Sup :sunglasses:

Branding :cool:

After some discussion we started to make the move to rename our CLI facing components from rad- prefixed to lnk- prefixed – the rad binary being named lnk. This decision was made to avoid stepping on the toes of application developers, for example, the alt-client team’s rad binary. Think of it as lnk being rustc and rad being cargo.

Replication Stabilisation :repeat:

The stabilisation of the replication-v3 feature has been making some serious ground in the past month. Some highlights have been:

  • improved verification of the storage layout
  • minimising the number of transfer trips during the exchange
  • pruning of deleted references

The last hurdle is respecting the tracking configuration for limiting what is replicated. The TL;DR is that the semantics of transitively tracked peers was a little bit tricky, but we have come to a decision on what’s best to do here.

Once replication-v3 is stable we will remove the previous version of replication. Any objections should be raised on the mailing list (more on that below).

Git Server :robot:

The pieces of the git-server have been coming together over March. The bare-bones implementation of the server itself has seen a patch series. Groundwork was laid by implementing storage of seeds and the (temporary) request-pull protocol. These will be used in the git-server as part of the git fetch and git push flows. The seeds stored on disk will be the configured seeds in which you git fetch changes from and git push changes to – via request-pull. These don’t require any interaction with the gossip network and instead use point-to-point replication.

Housekeeping :broom:

Some honourable mentions in the housekeeping category are:

  • We updated to rustc-1.59
  • We are now using clap-3 instead of the combination of clap-2 and structopt
  • We (re)moved the daemon crate from radicle-link
  • We improved the organisation of our test code as well as moved to using cargo-nextest, which has been a delight to use – even helping with flakes by retrying :wink:
  • We now build on NixOS on sourcehut! Although it’s not quite a distributable build, but it does tell you what dependencies we require

The Chatz :speaking_head:

We have officially announced a /discuss mailing list ~radicle-link/discuss archives — :partying_face: It will be the home for protocol discussions between the Link Team and anyone who is interested in building on top of radicle-link. It provides more of an open space for discussion that avoids all the noise of patch contributions. It will also be the home for pre-RFC discussions and RFC patches (but please x-post to /dev for these).

And what timing for it to be introduced, since we are discussing how to disseminate “events” to radicle applications on the same host, sans Apache™ Kafka.

Looking forward to hearing more great discussions from all of you!

Forever Linking you to your Monorepos,
The Link Team :chains: :seedling:


@fintohaps would it be reasonable to start researching and discussing the cross-chain implementation of all radicle smart contracts as well as the event listener in the radicle-cloud repo?

I’m not familiar with any of what you mentioned and what that would involve, so I can’t answer yes or no :slight_smile: