Ermahgerd, #LibResilient ( https://resilient.is/ ) got a code contribution and, more importantly, someone is putting a lot of effort into diving into a somewhat complex issue they are affected with!

I am very excited about this development.

I am at the #GlobalGathering in Estoril, Portugal this weekend, and have booths about #LibResilient (Saturday, 15:30 - 17:30) and about #Quad9 (Sunday, 15:30 - 17:30).

If you're there as well, come say hi!

Got interviewed about #LibResilient for NGI
(emojis added by the editors)
https://www.ngi.eu/ngi-interviews/michal-wozniak-libresilient/

Here's the link to the project (that somehow does not show up in the published interview, sigh):
https://resilient.is/

And here's the talk I gave at MCH2022 about it:
https://media.ccc.de/v/mch2022-198-trusted-cdns-without-gatekeepers

A few issues got created by someone and another merge request was submitted to my little side-project!

One of the issues is about having a release. My little project is growing up so fast!

The project website is here by the way, in case anyone is wondering:
https://resilient.is/

I just finished Doing A Thing and I am very proud of myself. Winning at adulting. And #LibResilient just got content-based MIME type deduction. Weee!

I just spent 30min thinking about how I would implement a specific thing that would help me test improvements to #LibResilient with less fuss…

…and then discovered that I had already implemented that very thing months ago.

I am a highly skilled professional, I swear.

Rewriting #LibResilient tests in #Deno and… damn!

The number of random "add a timeout to wait here and hope all random promises started deep in the code resolve before it" I am removing — partially because I now understand my code better, partially because Deno has sane, reliable implementations of WebAPIs — is quite substantial.

Makes me a happy camper.

Rewriting #LibResilient's tests in #Deno (from NodeJS and Jest) not only helps me write cleaner code and get rid of the mess that npm dependencies are, but also it helps me understand #JavaScript better, it seems.

In a number of places (in tests and in code they test) it forced me to actually *understand* some quirk of the language and re-write stuff in a cleaner, more unambiguous, easier to debug way.

Can't wait for the rewrite to be done so that I can remove the last bits of npm crap!

About a thousand lines of code re-written from NodeJS/Jest tests to Deno:
https://gitlab.com/rysiekpl/libresilient/-/merge_requests/19/diffs

About 1/5th towards the milestone:
https://gitlab.com/rysiekpl/libresilient/-/milestones/12

Rewriting all tests for Deno will mean I am able to completely remove NodeJS stuff from #LibResilient. Which I am very excited about!

#LibResilient got more #NLnet funding, and so there are new milestones!
https://resilient.is/blog/more-funding-new-milestones/

> 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.

#LibResilient documentation is now more usable
https://resilient.is/blog/better-exposed-documentation/

It took me a good while but finally LibResilient's documentation (including that of its plugins) is available in one place:
https://resilient.is/docs/

There's an index, the whole thing is nicely browseable, and it's all a nice static site, because of course it is.

I'm hoping this will make it easier for people to engage with the project and maybe deploy it on their websites.

Wow, did two #LibResilient blogposts week after week. I wonder if I can keep this up next week.

#LibResilient got a CLI
https://resilient.is/blog/libresilient-cli/

It's a tricky beast to implement, mainly because most relevant functionality comes from plugins anyway, so the CLI necessarily also has to basically be a thin layer over the plugin code.

The nice thing is that it's implemented in @deno_land. Compared to NodeJS, the difference is like night and day. Deno has a built-in test system, and implements all the WebAPIs LibResilient uses natively.

Might have to re-write all my Jest tests in Deno!

New in #LibResilient — two #DNSLink based transport plugins:
https://resilient.is/blog/new-dnslink-based-transport-plugins/

DNSLink makes a lot of sense in LibResilient: DNS is often more reliable than web, and DNSLink offers a way to make certain information — here: where to fetch content from — available in case the main site is down without having to put that in the configuration.

This means more flexibility in case main site is down. Easier to push out updates related to alternative endpoints or current IPFS CID.

Writing tests in #Deno is positively *pleasant*.

No clue how they achieved that, but compared with Jest, and especially if you're testing stuff that relies on WebAPIs, Deno is a clear improvement.

Much recommend:
https://deno.land/manual@v1.28.3/basics/testing

Looks like I might be able to tear all the NodeJS/npm crap from #LibResilient after all. Fantastic.

Guess who's got two thumbs and is re-writing #LibResilient CLI from scratch?

https://gitlab.com/rysiekpl/libresilient/-/commits/wip-cli

What is LibResilient you ask?
https://resilient.is/

Here, have a talk from #MCH2022 about it:
https://media.ccc.de/v/mch2022-198-trusted-cdns-without-gatekeepers

@rysiek I was thinking, add the idea of #LibResilient to have a server list in the client. This way, if a server goes down, there will be others to connect to. Would need to be tamper-proof though and I'll leave that as an exercise to the security expert.

Can you create a services that runs entirely #p2p and only on low power, unreliable devices, like mobile phones and #raspberrypi s?