Howdy 
What’s been Served? 
Tracking
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 radicle-link.
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 
.
Replication
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 gitoxide library.
We are currently aware of a problem when enabling the
replication-v3
flag. This flag pulls inget-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
depend ongit-tempfile:1.0.6and disable it’s signal handlers with the
following:
git_tempfile::force_setup(git_tempfile::SignalHandlerMode::None);
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.
Peer Node
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.
RFCs
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.
CI
There were several QOL improvements to the CI builds. There’s even a GitLab CI manifest if you’re into that sort of thing.
Docs & Licensing
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.
What’s on the Hob? 
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 radicle-link.
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 rad-exe, rad-identities, rad-profile, and node-lib. We would eventually want to utilise something like clap_mangen for generating man pages.
Stay Radicle,
The Link Team 
