Good news: NLnet Foundation decided to extend their small grant for LibResilient! That grant funded bulk of the work over the last year and a half. It will now continue to do so for the next year or so.
The grant extension also helped to define the milestones for 2023. Here they are, in no particular order — the order they get implemented depends on many factors, including some non-obvious interplay between them. Some of these milestones are pretty simple, some will require substantial re-writes. Exciting times ahead!
LibResilient’s documentation used to be just a bunch of Markdown files spread across the repository, available through the Gitlab-hosted project. That was fine as the first jab at making it available, but it was far from perfect: for example, it was kind of difficult to discover and browse plugin documentation.
Now, documentation (both general docs, and per-plugin documentaion) is available directly on the website. Still not perfect, but considerably better nonetheless. Importantly, plugins documentation is also gathered in a single place.
LibResilient now has a large number of transport plugins, offering a lot of flexibility for website administrators. Some of these plugins rely on more than one way of making information available — for example dnslink-ipfs expects content to be published on IPFS, and the latest IPFS address to then be pushed to DNS.
How to push this information and data out was so far left to website administrators, creating a relatively large obstacle to LibResilient adoption. Now this might gradually start getting solved, thanks to lrcli, the LibResilient CLI.
After a long break (perhaps a bit too long, in fact), LibResilient is back in active development. As part of that, a two new transport plugins got implemented:
They fetch content using means that have been employed by LibResilient plugins before, but use DNSLink to figure out where to fetch content from.
Imagine this: you’re running a reasonably important site, and you decided to deploy LibResilient to make it, well, resilient.
Your config sets up the fetch plugin, then local cache, and then alt-fetch with some nice independent endpoints (say, an IPFS gateway here, an Tor Onion gateway there). Perhaps with some content integrity checking deployed too, for a peace of mind (no need to completely trust those third party gateway operators, after all).
So far most of LibResilient development was focused on proving the concept and implementing different content fetching plugins. After the project got a small NGI Assure grant, the focus for the previous milestone was instead making the project itself more, well, resilient.
Today another milestone was completed, focusing on integrity of content fetched via LibResilient, and thus on the security of websites deploying it.
Took a while (summer holidays got in the way), but LibResilient finally reached a milestone: “Improved resilience of libresilient”. It’s a reasonably big deal, for a number of reasons.
First, that means that development is actually happening again. Second, one of the goals of this milestone was to create a decent testing harness, so that any errors or breakage caused by code changes can be caught early and fixed.
Third, this is the first milestone covered by the NLnet grant for LibResilient. You read that right: LibResilient development is now supported as part of the NGI Assure project. There are six more milestones defined as part of that grant.
