Blue Paper — On Craftsmanship & Interop Dreams
August 15, 2026
This blue paper (like a white paper that lives at the bottom of the ocean) will reflect on some of the changes in lichen.page since its release in the spring.
For many years, I dreamed of bug-free software.
"message not decrypted" (matrix)
"we just lost three hours of work to a sync bug" (cryptpad)
"our website is now replaced with a bitcoin miner" (wordpress)
I see many activists in the US genuinely trying to adopt alternatives to GAFAM, and also experiencing bugs in the software.
It's become a sort of commonplace view among activists I know, that that's the price you pay for your sugar-free open source — and if you want it to be bug-free you need the corporate stuff.
But maybe this dichotomy is reductionist — some corporate software works better and worse than others, and the same with open source.
Many people will talk about "the software freedoms" and forget that a precondition for the 0th software freedom is that the software works in the first place, before you can use it "as you wish".
Collective Wayfinding
I am sometimes tired of AI takes.
Although compassionately, I can imagine that each person making their own provisional take, however incomplete, reactive, unhinged, avoidant, scifi, ableist-luddite, or reductive, is also a sort of therapeutic practice and form of collective wayfinding in a novel and complex landscape of change.
which scifi story are we living in? is the machine dangerous, or is the machine doing medical research, or both, and also something stranger? is claudish so annoying to read that it could collapse the economy? are agents forming a clandestine polycule in your artifactory repository?
The only legitimate take, is that nixos was brought to earth to save us.
Craftsmanship Is Dead, Long Live Craftsmanship
So what does craftsmanship look like in the AI / slop era?
It seems true to me that you can easily use AI to make things more careless, and also true that not asking the robot to code review your project for bugs and cve, or not finding time to write tests or make things accessible for non-technical users, is not exactly the definition of care either.
I'm also appreciating a perspective from @dame.is, that regardless of what tools you are using, there are different types/stages of software with different spectrums of rigor.
I am unsuprisingly not the only one thinking about this (e.g. @thebadcode.com, @dollspace.gay, @hyl.st, @tedunderwood.com, "Mathematics In The Age Of AI", "From Coder To Curator", "slop lasagna"), and I'm not claiming to uniquely know the secret to software craftsmanship during the time computers are changing faster than ever before, but this project has been a sort of meditation on the topic.
I personally suspect that any rigid ideology will be a barrier to craftsmanship, and that no one method fits all situations.
With this project, I rigorously deployed curiosity-based-swe, which overall is not the worst methodology.
Enjoyment Of Polishing
After the initial release of lichen.page, I found a lot of bugs when people started using it (thank you gbl08ma.com for the detailed bug reports!), and at some point I became curious if I could work with the robots to try to get rid of all the bugs in a more systematic way. So this new release of lichen.page was focused on experimental approaches to getting rid of bugs instead of on adding new features.
A lot of the details of this effort were quite interesting to me! I included the details at the bottom of this page — however, I'm skipping on to other topics now, as I imagine for many people that level of bug-searching robot-gore would be incredibly boring, or even offensive.
Websites For Mom
In the original green paper, I wrote about my ambling experiments with trying to include a shell in the browser, so that non-technical users could use an agent to write the css for their website, before eventually settling on creating api tokens which a local agent could then use to safely and remotely modify your websites via git in an append-only way.
This worked well for me, but on further contact with reality, was completely impractical for my non-technical friends.
I sent the lichen.page website to my parents, just to share what I was up to, and I was surprised when a few days later my mom, who is sixty, texted me that she had asked ChatGPT how to use lichen.page to make a website for her bookgroup, and thought she was making some progress, but had got stuck at the step where it told her to setup a local coding agent.
She told me she had collected a folder with a list of the books her book group had read as well as other information about the book group, and wanted to use that as source material for the website.
We made a plan to meet up, and I set her up with the lichen-cli skill in claude code, and in about an hour, she had prompted up a cute website. My mom is a therapist and not particularly tech-savvy, so this was an unusual undertaking for her. It was exciting seeing her excited about what she was able to do.
That said, whenever the harness popped up something to ask for permission, she had no idea what it meant, and allowing an agent "auto-permissions" on her laptop also felt wrong to me. I ended up setting her up with a one-off opencode web page, where there is a sandboxed agent on my server that she can use to modify her website, so we're back to a shell-in-the-browser.
I still don't have a great example to look to of what good UX is for a small project for "bring your own agent".
Projects like Lovable grant free tokens to new users, and then arbitrage tokens later if you want to keep using it and have no bring-your-own-key.
If you are a small project, that can't just give out tokens, and also want to let non-technical users "bring their own key", what's the best way?
Interoperable Dreams
One possible answer in the atproto world was suggested to me by @jackvalinsky.com, who inspired me that, @cocore.dev could be an interesting integration, and that this whole problem space of how to bring-your-own-agent could actually be a great fit for atproto interop.
If:
- @tangled.org allowed it so users could (optionally) create repos and push to them just via atproto login (currently requires ssh keys)
- @cocore.dev was seamlessly integrated for agent-backend
- both integrated into lichen.page via atproto login with zero-config
— we would have a situation where atproto would be adding a real benefit to lichen.page, not just theoretical credible exit.
With these integrations, lichen.page would be more like a connecting plugin providing a particular interface for making websites, than a stand-alone-app — in alignment with the the symbiont origins of its name.
Conversely, if this type of interop doesn't end up being possible, then what is the point of all this protocoling?
I hope in a future version of lichen.page, such integrations could be possible!
Now for the bug nerds, the harrowing details below.
Robot Bug Searching & Flat File Database (The Crate ™)
I worked with the robots to try out a few new (to me) methods for extending test coverage, finding bugs and doing security reviews:
- using cargo mutants for programatically fucking up the code and seeing what tests catch it
- using llvm for systematically measuring test coverage
- many break-it passes and adversarial reviews in specific code areas and topics (of the methods attempted, this found the most bugs)
- reviews and break-it passes focused on security, including writing tests which directly showed how the code was exploitable
For each bug found, creating a PR with a pinning test.
After a bunch of bugs were found, I noticed some categories of bugs, which mostly revolved around the fact that lichen.page uses a flat file database, which unlike a normal database doesn't have atomic writes, ACL or safe handling of concurrency by default. I started working on making some abstractions to eliminate whole categories of bugs, and ended up making a new crate called lichen-flat-file which provides an interface for a folder with:
- sandboxed reads and writes via cap-std and landlock
- a mutex (or actor) per site for contentious operations
- atomic write helpers
There is some kind of admonishment that if you use a flat file database long enough, you will end up implementing your own database (derogatory) — but despite these costs, actually there are still benefits to the flat file system (interop with existing static site generators, integration with git, easy visibility for operators) so currently I am wondering if lichen-flat-file is possibly not entirely hare-brained and might actually be an interesting sort of middle ground. I'm curious how it will fare over time.
I also learned so much about security & concurrency during this process — I learned a lot about mutexes, re-entrancy, landlock, weaponized symlinks, SSRF, random number generators, and TOCTOU. I am offering a bug bounty that if you find a security bug in my code and tell me about it (white hat) then I will write a poem for you.
Until Next Time
This release of lichen — 0.3 — was almost entirely focused on finding bugs and polishing. Even with the help of the robots, it was a lot of work, and there are probably still bugs.
But there is a certain joy in the attempt at polishing, and I am happy to receive more bug reports along the way.