Hindsight is 20-20 and we realised that we had not implemented a mechanism for migrating from the old tracking configuration to the latest and greatest. With a couple of bumps along the way, we added a migration path that is transparent to the consumers of
We also spotted a nice, algebraic solution to simplifying tracking operations when performing them in batches. For those interested, you can find the details in the RFC .
The use of the tracking configuration in replication was integrated, but not without spurring on a conversation. The TL;DR is that we became stumped as to what to do about configuration filtering for transitively tracked peers. We ended up only considering the
data portion of the configuration and plan to use the
cobs portion in a different way – possibly even moving it out of the tracking configuration.
While exploring the integration of
replication-v3 into #radicle-upstream, we came across an issue with a
We are currently aware of a problem when enabling the
flag. This flag pulls in
get-tempfilev1.0.6 which unfortunately
installs some signal handlers. This means that applications which enable
replication-v3may find their own signal handlers are affected. We are
working on a solution to this but in the meantime the workaround is to
git-tempfile:1.0.6and disable it’s signal handlers with the
The recent issues with
gitoxide have prompted us to limit our usage of the set of libraries and attempt to only rely on the git protocol-v2 feature it provides, for now.
We now have an MVPeer that is a standalone, socket activated daemon. The node accepts RPC methods for interacting with the
radicle-link protocol. For now, the only method is to announce new changes, but this paves the way for implementing more of the application architecture.
RFC 701 was proposed and accepted. The TL;DR is that there will be a protocol mechanism for a peer to synchronise with the peer it is serving data to.
There were several QOL improvements to the CI builds. There’s even a GitLab CI manifest if you’re into that sort of thing.
Thanks to @Jayman for contributing to the code base by fixing documentation and licensing. Their initial patch to the licensing lead us to discuss whether we wanted to keep the “Radicle Linking Exception”, and ultimately, it was dropped.
We want to continue to work on the application architecture work by fleshing out a
git-server that would replace the
git-rad-remote in the future. This would be a daemon that would work over ssh and allow us to simply use
git commands for transparently interacting with the
radicle-link storage and network.
We plan to improve code organisation. We’ve noticed that the compilation of the test suite has become sluggish, so we want to explore ways of reducing that. We also plan to shift from
rad prefixed binaries to
lnk prefixed. This is to ensure that we work within our namespace and avoid stepping on the toes of other applications developing on top of
Something we would like to have is a NixOS SourceHut build so that it’s easy to see our build dependencies. Contributions are welcome if we don’t get around to it ourselves
If there are people interested in contributing, some low-hanging fruit would be to switch to using
clap >= 3.0.0 for the argument parsing in the binaries – these include
node-lib. We would eventually want to utilise something like
clap_mangen for generating man pages.
The Link Team