How do you do?
First off, apologies for no written update for the previous month. It was a busy month But look at all the updates this month!
The overall story for the
gitd server has improved considerably. We were put through our paces as we made improvements. We had to change the
net::Peer stack by introducing stateless calls for
request_pull. We were then forced to dig deep into async Rust and figure out why our signing through ssh was deadlocking. After a considerable amount of time, we found the issue and unblocked the pipes. This all leads us to a successful
git push and
git fetch using the
gitd server. A script for performing a
git push can be found here.
Unfortunately, due to the limitations of requiring a
HEAD reference – a nuanced problem given decentralised development –
git clone will perform a fetch, but the working copy will be in a less than desirable state. To solve this we will be proposing a
lnk clone command which will handle picking a canonical reference.
The next step for an integrated experience between the
radicle-link storage, the
gitd server, and applications depending on these components is the introduction of storage hooks. These are proposed in the RFC [PATCH v3 0/1] RFC: Storage Hooks — sourcehut lists. This will allow applications to define executables that will be invoked upon changes to URNs and tracking relationships.
We have introduced a
lnk sync command to be able to easily synchronise with configured seeds in one go. We see this as a useful command for when you come online and want to synchronise your state at the start of the day
The stabilisation of
replication-v3 is coming along nicely. The final piece of the puzzle has been implemented and merged. The replication now honours the policy defined in the tracking configurations of peers.
With the many pitfalls of the
gitoxide dependency, we are discussing the removal of it here Replacing gitoxide — sourcehut lists. Whether this is necessary to implement before removing the
replication-v3 flag remains to be seen.
The #alt-clients team has been exploring the use of collaborative objects which has led to some changes, improvements, and discussions. The first major change was to remove hard-coded authorisation logic in the protocol itself. Instead, application developers can inject their own authorisation logic – this shifts the burden of authorisation but allows for a more malleable experience.
This in turn led to the discussion of removing the use of JSON schema to validate documents in the protocol COBs: The Case Against Schemas — sourcehut lists. For similar reasoning as above, we will be removing this validation and moving the responsibility to upstream applications.
We are discussing some improvements on the initial verification of identities that are initialised with more than 1 delegate [PATCH radicle-link v1] rfc: ammend quorum rules — sourcehut lists. It’s still up for debate on how we will move forward.
We’re planning on hiring in the next coming months. We’re currently fleshing out the types of roles we want to fill, but we will be looking for contributors that want to take on tasks involving automated maintainers, collaborative objects, and fleshing out the application architecture. We’ll be sure to post the roles to community.radworks.org as well as some other spots.
The Link Team