Project report

Wednesday, July 20, 2016

I’ve not written anything in some time already, so I’ll use this post to give an update of what has been going on in Pijul lately.

Non-technical news

I never formally announced it, but I (Pierre-Étienne) got a talk accepted to the Rust Belt Rust conference. I’m excited to go there and meet fellow Rust users. Also, in November of this year, I’ll start a job at Inria in Paris, working mostly on molecular computing, but also on Pijul part of the time. I hope to have a usable version of Pijul ready before starting the job.

IRC, mailing list, …

We have lost our mailing list after I decided to switch to NixOS for the machine running pijul.org. After using several mailing lists engines for years, I’ve not found any which would be at the same time maintenance-free, and with a secure enough and easily configurable web interface. I’ve therefore decided to give up the search for now. The primary way to contact us now is by our IRC, #pijul on freenode.

Building “the Nest”

As Pijul is getting more complex, I’ve felt the need to start developing a web interface to visualise things. This web interface will ultimately become the Nest, whose goal is to provide a github/gitlab/… -like interface, but decentralised.

As part of this project, I needed to write bindings for the server side of libssh, to be able to run an ssh server with weak permissions, which is a great way to push patches. Unfortunately, that library has no examples of a working server, hence I’ve started to write my own, after realising that the SSH protocol is not that complicated. The result is called Thrussh, handles both the client and server sides. See my blog post about it.

The state of Pijul

Pijul is not yet usable, although we’re getting there. After announcing a pre-release several times and failing to make it, I prefer not to do it again. There are two main things missing:

  1. Full support for branches: we still need to make one small change to the format. The main thing is synchronisation between the repository and the filesystem, which is relatively simple in the case of a single branch, and not that simple when there are several branches.

  2. Stabilising the patch format. This would allow us to postpone improvements to e.g. Sanakirja, as the repositories could be completely rebuilt from patches, provided they are stable enough.