worm-blossom

Back at last. And I owe the faithful readers of worm-blossom.org not one… but two editorials, as these last two weeks I was busy attending two very different events: p2p-basel and FOSDEM. The former is intimate and deep, the latter huge and sprawling. And I had a great time at both. Let’s start with Basel.

p2p-basel invites researchers and p2p practicioners to a weekend of lectures and talks at the University of Basel. This year there were only approximately 16 participants, and that creates a very intimate atmosphere for discussion. For example, the catering of the event is also peer-to-peer, with attendees participating in cooking and cleaning. Those moments where you stand shoulder to shoulder with someone while peeling carrots present wonderful opportunities for deep discussion.

There are prepared presentations and a time dedicated to spontaneous unconference discussions, of which I moderated two this year.

The first was on ‘delay tolerant UIs', anticipating user confusion stemming from systems where authored data may only reach other users a week later. This might mean the arrival of a message divorced from its original context, or worse, placed into a new context which changes its meaning (e.g. a thumbs up emoji arriving during the discussion of something sad). Clearly we cannot simply lift the UIs of applications which presume near-instant data delivery and expect them to work.

The second was on ‘zero / low identity systems’, and I was really happy that so many others were also interested in this topic. Digital identity is often used to link different pieces of data together through a ‘digital double’ which can often be linked to a real person. The risk here speaks for itself, and I had a half-baked idea on how to reduce or eliminate identity in networks: random IDs for all data, with the option for the ‘owner’ of a random ID to derive a new one which everyone else can then verify is provably linked to the original ID. This forms a kind of ‘identity on demand’, or as someone else put it much more eloquently, ‘lazy identity’. It was pointed out that this is not conceptually unlike image board tripcodes (though I’ve since learnt these are apparently quite crackable). Maybe there’s something here, though? It would be interesting to plug such a system into Willow.

Huge thanks to p2p-basel’s organiser Erick, who has relentlessly improved the event year after year.

~sammy

Weekly updates and depressive episodes are not a good match.

I'm trying to take good care of myself, as much as I am able to. Even if that means taking a break in the exact week where FOSDEM has hopefully pulled a lot of fresh eyes toward us.

I often feel like Willow is coming into being too slowly. But even then, we are still doing meaningful and creative work, and putting it out for everyone to interact with. And that is something I can draw strength from, even when I am too off-balance to meaningfully act on that strength.

~Aljoscha

A handful of days after returning from Basel, I departed again for FOSDEM in Brussels. This was my first time attending, and I was a little overwhelmed by the size of the event. So many buildings, people, and cat ears. And for some reason I chose to wear heels the whole weekend.

Luckily I was met by friends of worm-blossom (FoWB) Miaourt and danmw, and we spent Saturday discussing blobjects, fictional Willow companion hardware / tamagotchis, radio-friendly Willow, and Miaourt bearing a seemingly inexhaustible bag of waffles. We had a lovely worm-blossom.org dinner that evening, and although I did not say it at the time because I wanted to appear cool and not overly sappy, I thought to myself that if these were the kinds of people worm-blossom is interesting to, then surely we are doing something right.

I spent Sunday in the Local-first, CRDTs and Sync Engines devroom. My favourite talk was from Modal Collective, in which they detailed their motivation for building a new secure, iPhone-quality OS with p2p at its heart. It shared a lot of themes with my own presentation and I was excited that this line of thinking is turning into action. It’s always lovely to see adz of p2panda, and lovely to meet Tobias Bernard of GNOME too.

Then it was my turn to present. I’ve been working on my talk since the start of the year, and it had been through several incarnations before reaching its current one, leaving me a week and a half to produce approximately fifty drawings. Fortunately I embraced the scrappy spirit of worm-blossom.org, and put together possibly the only talk of FOSDEM with an opening cutscene (music provided by Aljoscha, naturally):

(There is also a live recording if you’d like to experience the live vibes and Q&A portion).

Readers, four days later I am still glowing from the reception to my talk. I’m so, so grateful for all the kind things people said to me afterwards, and the lovely conversations it afforded later that evening.

As I took the train home, I thought about how the p2p community has grown over the years, and how the connections between us have matured alongside the theory and implementations. Perhaps we can do something really wonderful together?

~sammy

The music for the intro of the FOSDEM presentation is a beepbox piece, of course:

~Aljoscha

So, P2P Basel happened. I had a nice and calm train ride there together with Andreas and Glyph from p2panda, where we avoided talking about p2p stuff for the most part, knowing the weekend would hold more than enough of that. I did get a bunch of music recommendations from Andreas.

The evening had a couple of workshop participants meet for lunch. I had a nice chat with Pierre from Pijul, who gave me some much needed reassurance that most everyone has moved on from their phd thesis topic by the time it comes down to writing, and also that most everyone hates publishing by that time. The key is to do it anyway, I guess. So for the first time in well over a year, I've actually been motivated to keep chipping away at this phd thingy.

Then Friday was the first actual day of the workshop. Except I didn't feel terribly well. I made it through the day, but ended up shambling back to the apartment with a fever. And then I spent the remaining weekend lying in bed, with Sammy bringing me the occasional meal from the venue.

I'm still recovering, so no implementation progress report this week. Though I am a bit concerned how long it has been since the last actual code release. I hope I'll get over the hump of releasing the first storage-backed-Bab version soon, so that things can get back to more regular, incremental feature releases.

~Aljoscha

I’m writing this on the second leg of my seven hour train journey from the Hague to Basel. Like Aljoscha, I’m going to p2p-basel to listen rather than to speak. Tags: receptive, curious, critical. And frequently: confused. Plenty of leaning over to Aljoscha and whispering “what does that mean?”. I still remember him explaining monotonicity to me a few years ago with the patience of a saint (St. Numbers).

The FOSDEM talk’s shaping up rapidly. I’ve now updated its title and description to better reflect its contents: “Willow - protocols for an uncertain future”. This is going to be a very different take on Willow than we’ve presented before, so I hope it will be interesting even if you’ve been hanging around the project for a while.

This week, I want to start adding more random little one-off drawings to our weekly updates.

~sammy

I have been programming too much over the past weeks; it has been impoverishing my life. Case in point: tomorrow (I am writing this on Wednesday), I am leaving for p2p-basel, and I... have barely thought about that at all, being too busy doing computer things. I don't even have a presentation to give, whereas in the previous years my problem usually was having too many presentation ideas to choose from. Still, there is much to look forward to: I will be seeing old friends again, will meet new interesting folks (there'll be someone from the Pijul VCS, I might finally get closure on some question regarding this paper), there will be interesting discussions and fun evenings. And I'll be meeting Sammy in person for the first time in over a year!

Despite me programming too much, we will not get everything ready by FOSDEM that we had hoped to. Which makes me feel disappointed, despite the fact that I have actually been pretty productive: Bab slice verification is implemented, and I am close to having a simple storage backend that can store a single, contiguous slice. In terms of unlocking funding milestones, I am more productive than needed. Yet the self-imposed FOSDEM-deadline makes me feel bad about the current state of things.

Hence, I label the self-imposed deadline silly, and I will do my best to focus on everything I did implement instead of what is still missing. As usual, there is also the voice that wants Willow to finally become a real thing that people use. But if listening to that voice means wasting my time staring at a small rectangle all day, then I label that voice silly for now as well.

In less silly news, academia and macadamia have a Levenshtein distance of two. Hmmmm, macadamia... now that is something I can get behind!

~Aljoscha

This week my attention was once again fully occupied by the upcoming FOSDEM talk. After a run-through of a draft slide deck this morning, I felt dissatisfied, although everything was arguably there. Empty calories.

I am a person driven by dissatisfaction, and I work on things until I am happy with them. Aljoscha has the same malady. There is seemingly no cure. This makes the things we work on take a very long time. This website is a kind of compromise: we blog about our ongoing dissatisfaction on a weekly schedule.

So now I am restructuring the presentation for what is hopefully the final time. I mentioned last week that if you want to learn about what Willow is and how it works, we have a website. But why is Willow like it is? What kind of world made us feel such a thing was necessary? That is the kind of talk I think people will enjoy most.

It will be fun, maybe even insightful. If you have been reading worm-blossom.org for any amount of time, how this presentation turns out will not surprise you in the least.

~sammy

(also, Bab implementation notes)

~Aljoscha

My week was high-intensity but low-worm-blossom as I was single parenting. With the time I had between biking my kids to school through the snow, preparing meals, pleading with them to just open their mouth so I could brush their teeth... I mulled over my FOSDEM presentation.

I got stuck in a 'concept' phase. For me it would be a bit disappointing to just say what Willow is and explain it spec by spec. After all, we have a website for that. This presentation should act as a complement to it. But how? I sat around pondering. Thinking really hard. And guess what: it didn't help.

As soon as I switched to making — even with only a very vague idea — things began to progress. Being able to sketch, respond, tear down, iterate. Share an idea I'm excited about with Aljoscha, and he gets excited too. And now I can't wait to keep working on this thing.

And so the first thing we did was confirm with the devroom organisers that we would be able to play audio over the speakers.

~sammy

Rambly, reflective editorial incoming — creativity is fascinating (as is reading McGilchrist).

I was almost completely unable to make any progress coding this week, despite desperately wanting to. But whenever I opened the text editor, I would just be completely disinterested. I’d like to tell myself that I have the cognitive ability and trained skills to be able to work productively even when I’m not into it. But truthfully, the code I did force myself to write is so bad I will probably have to rework it at some point.

I usually struggle with creative output because I judge my own intuition too harshly and want to get things right. This website has been a good exercise in loosening up in that respect. But this week, the problem was of a different nature — I did not care enough to judge at all, leading to pretty bad code I normally would not let myself write. So where ideally there should be a healthy balance of generative creativity and quality control, this week had neither. And forcing things regardless just doesn’t work.

And then, out of nowhere, my brain delivered the solution for how to elegantly implement verification of incoming data streams in Bab. And suddenly, I felt like coding again, and have been happily coding since. This did not happen in time for finishing things by today, so I will detail this implementation approach next week.

Interestingly enough, while I was more or less unable to code, I did do some beepbox pieces I am not unhappy with after the fact — both of which I imagine working nicely in an RPG of some sorts, inspired by watching some Expedition 33 and Final Fantasy VII over the week:

And I did not dread the task of writing an editorial for this week either, despite having little idea what to write about before actually sitting down and starting to type. Not sure whether this says something about myself, or more about differences between writing, music, and coding.

~Aljoscha

It was time to take a pause. In the last week I've spent time with family, ate, took my customary New Year's Eve bath, ate, and started a new journal for 2026. What little worm-blossom related stuff I did was thinking and sketching out my FOSDEM talk, specifically thinking about what you should say to an audience who have just seen twenty presentations on similar projects for the past several hours. Something high energy, controversial, more about vibes than details?

In honesty I am bracing myself for another intense year, perhaps harder than the last. So I am looking for ways to make it easier on myself. I found the practice of trying to make a funny comic each week a challenging one (with questionable results). I envy Aljoscha's free-form noodling in his little musical corner. So I'm going to have a little experiment with some more improvisational visual storytelling.

I hope you took some time to catch your breath over the last few weeks too, let's try our best!

~sammy

Friday arrived so quickly, and I had not written an editorial yet. I have barely thought about the website update at all this week, actually. Does this mean I finally found a healthier attitude toward my work and this website, will I now lead a life of increased inner harmony and peace? Will my output dwindle as a consequence?

Nah, I simply spent most of the time learning and thinking about audio file formats and video file formats, in anticipation of the Cobweb and Rummager.

The number of file formats you would need to support to provide somewhat decent coverage for the media content on the web is intimidating, as is the staggering complexity of the individual file formats. So I have been pondering what a significantly more simple stack could look like. Only one file format per media type (images, sound, video), and simple formats at that.

The file formats would be pure delivery formats, no niceties for editing included. Further, the formats should support both lossy and lossless compression (which, sadly, rules out the Quite Okay Image format and the Quite Okay Audio format), down to extreme measures such as one-bit images or audio. And, ideally, the three formats would have identical or at least similar structure, and reuse the same underlying techniques. A nice challenge would be to fit all three formats (including their shared components) into 400 * 3 = 1200 lines of C code — the reference implementations of QOI and QOA take 400 lines of code each, after all.

A rough starting point for a unified approach to the three different file formats:

• Regard each media type as a collection of channels, where each channel is a list of integer samples. For images, the four channels are three colour channels (YCbCr, specifically) and the alpha channel, and the one dimension is the row-wise content. For audio, each channel (one for mono, two for stereo, possibly more for more fancy stuff) is a stream of PCM data. For video, one channel encodes time-warying images, and the other channels are audio channels.
• Channels are interleaved. Each channel has an independent frequency. For example, a video could encode images at 30 Hz but audio at 44.1 kHz. And an image could use lower frequencies for the colour channels (aka chroma subsampling).
• Before encoding, quantise all signals to a channel-specific bitwidth. This is the (only) part where lossy compression enters the picture. The bitwidth of a channel can even be zero — say, for an alpha channel that has the same value everywhere. The simplemost quantisation scheme is simply to right-shift each sample by some amount, though for audio it is tempting to go with a non-linear quantisation scheme (because using fewer bits for high frequencies compared to low frequencies neatly exploits properties of human hearing).
• On the quantised signals, use some form of Lempel-Ziv compression. When a value cannot be reconstructed from the dictionary, it is not encoded verbatim, however, but as a residual from a prediction (see next bullet point).
• Each file format has a (different kind of) predictor, which tries to predict the next sample from the previous samples. We never encode samples verbatim, instead we encode the difference to the predicted value (the residual). With a good predictor, this means we will usually encode only small numbers, a property we can then exploit for more compact encodings. For images, the prediction is probably simply the previous sample. For sound, I’d tend toward reusing the LMS of the QOA format. And for video image frames, the pixel of each frame would be predicted as being the pixel at the same position of the previous frame, offset by a frame-specific x and y value (i.e., simple motion compensation, I'd also consider simple forms of Dolly and camera rotations if they admit simple integer-based implementations).
• Finally, encode the residuals or the LZ compression stuff nicely and compactly. The easiest approach here would be to define a bit-based encoding and simply encode every sample separately, but it would also be nice to have a byte-based encoding — and grouping multiple samples together can be more efficient than encoding them individually. So there is a lot of design space here. Further, there are concerns around seeking: how can you efficiently jump to an arbitrary point of time in a time-varying signal? First, there probably needs to be a balance between absolutely encoded samples and relatively encoded samples. You'd use the absolute samples for seeking, and then do a linear scan across the remaining relative samples. The original anti-monotone binary linking scheme would be a really neat way for providing (only a bounded number of) forward-pointers between absolute samples. But still, with interleaved channels of different frequencies and bit-depths, and LZ compression, finding a good mechanism here is tricky.

There are further concerns such as container formats, and accessibility features like subtitles. But this would be the general idea for building an image format, an audio format, and a video format that all work in essentially the same way. It might not be unrealistic to use identical subsampling, quantisation, LZ compression and final encoding steps for all three formats. Aside from working out the specifics, the big remaining question is whether the lossless compression yields acceptable file size reductions compared to raw data, and whether the quantisation step (which is the only form of lossy compression in the whole approach) yields sufficient quality for the selected degree of compression. The two Quite Okay File formats make me fairly optimistic in that regard, however.

~Aljoscha

About two years ago, we published willowprotocol.org, and our server took a million requests on the first day. Soon we were getting emails from companies, universities, weird individuals, and it felt like we were really making something that made people sit up and take notice. We received our funding to build a rust implementation of Willow, and then… things stalled. It got quieter and quieter, until I imagine to the outside it seemed like nothing was happening at all. A lot did happen, of course, just not in a way we’d choose to have things happen again.

The end of 2025 brings the close to a weird era of willow, an era whose weirdness I’d like to reflect upon as I think I can recognise some of the ways it went differently than we’d hoped.

Our first mistake was maximalism. Willow Confidential Sync was the newest member of the Willow family, with the most novelty and flash. Range-based set reconciliation. Privately determining common interests between peers. Teeny tiny privacy-preserving message encodings.

As a poster child of privacy and efficiency, Confidential Sync radiated complexity onto everything around it. Willow storage needed to be able to efficiently fingerprint and partition ranges of local data for range-based set reconciliation. Storage needed special push-centric APIs so that new data could be broadcast to peers. Ufotofu needed a menagerie of encoding traits to be able to accommodate the private encodings which Confidential Sync uses to mitigate man-in-the-middle attacks.

We started to recognise the weight of this complexity early on, and specified the Willow Drop Format just a few months after the launch of willowprotocol.org. It’s a vastly simpler spec which asks far less of its dependencies. But at that point our funding goals and our destination were locked in: Confidential Sync was where we were going. And that path led us straight into the swamp.

At the same time, we were refactoring willowprotocol.org to use a new version of Macromania, the system we use to author the entire site (and this one!). Aljoscha made a big effort porting all the existing content to the new version, and it was so much nicer to author pages with that we couldn’t really go back to doing it the old way. And now we had a branch of the website with the new, not-quite-ready system and new content all mixed together. This interdependency congealed into a kind of seal which stopped us from making small updates to willowprotocol.orguntil everything was ready in one giant mega-update.

So willowprotocol.org was not getting updates. Which not only made it look like we were inactive to the outside world, but it also hurt our morale because we felt like we were digging into a bottomless pit with no recognition for our efforts. The longer the silence became, the worse our perfectionism got: we wanted to have something to show for ourselves after that long period of silence.

So we found ourselves working in frustrated silence amidst a myriad of interlocking dependencies. It was gruelling. In a struggle to keep the project on track, I ended up breaking personal connections which I treasured. There was also life outside of Willow which insisted on happening.

So what did we learn? Avoid complexity. Deliver frequently. Focus on doing as little possible to achieve your goal. Communicate often. How often have you heard these things? How many dozens of blog posts and presentations have you seen stressing these very points ad nauseam? I had certainly heard those hard-won lessons countless times — but found out I had to win them the hard way for myself, nevertheless.

I also have anti-takeaways: we were led into a swamp, but it was a very fruitful swamp. We used lots of time to make difficult, foundational design decisions, decisions which are already giving us increasingly stable foundations to work upon. It was long and tedious but it was also instructive, and we have the opportunity to actually use that experience.

worm-blossom.org is our antithesis to the era described in this editorial: frequent, ad lib, joyous. That’s what I want to bring more of to 2026!

~sammy

What a year. Sammy looked back, and I will lay out some future plans — specifically, plans for Willow. By the end of January, we want to have a simple persistent storage implementation and a Willow Drop Format implementation. Obviously, we have many more plans. Here they are, roughly in the order in which we want to make them real.

With Meadowcap, persistent storage, and the Willow Drop Format implemented, it will be possible to build actual sneakernet-based applications. While it is tempting to add more powerful data synchronisation as the next step, we should probably revisit end-to-end encryption of entries and payloads first. The earlier we implement this, the fewer moving pieces we will need to change based on our learnings. The concrete scope of this will consist of specifying specific techniques and primitives as part of Willow’25, and then to augment our storage implementations with the ability to encrypt and decrypt data on the fly. Ideally, this work will introduce only small changes to our public APIs — but ensure that most everything going forward is encrypted by default. Realistically speaking, a whole bunch of data is going to end up on the servers of large cloud providers, after all.

Before I can describe the next endeavours we have planned, I need some slightly abstract groundwork: the distinction between pull-based and push-based APIs. In a pull-based API, the entity that wants data needs to actively ask for it. In a push-based API, a data provider can proactively send data to its subscribers as new data arrives. Push-based APIs have several advantages, but they are also significantly more complex to get right. To a large degree, I blame the subpar progress we have made in the past on prematurely trying to nail the perfect push-based APIs: the Willow Confidential Sync protocol for replicating data, as well as ambitious subscription-based APIs for interacting with local data stores. This is why we have adopted a pull-based-only approach for now; this decision has played a significant part in our frequency (and hopefully quality) of recent releases.

Keeping this push-vs-pull distinction in mind, the next logical step in making Willow more “real” is a synchronisation protocol over the internet. The Willow Confidential Sync protocol is deeply push-based, so it is not an option. Instead, we have concrete plans for a more HTTP-inspired protocol of relatively simple requests and responses. This is the Willow Transfer Protocol (WTP), and you can read a draft version here. Completing the WTP specification and implementing it will be the next larger chunk of work, and one I am looking forward to!

Once we have a WTP implementation, we will have a complete (pull-based) Willow stack. It will then be time to slowly move to more efficient push-based components. The first step there will probably be local APIs. More specifically, a Bab implementation that allows subscribing to new incoming data, and then a Willow storage implementation that allows subscribing to change events. This will be crucial for more advanced applications that want to dynamically maintain custom indexes for more efficient queries than simply interacting with a Willow storage directly. In the long term, I actually hope that Willow stores will be used for replication and as a foundational source-of-truth exclusively, whereas any data access would go through more appropriate special-purpose indexes. Subscribable stores are the key stepping stone for moving toward that world.

Another step we will need to take eventually is to provide a more efficient storage backend. Right now we are building simplistic, linear-time storage that simply scans through all data and filters out unwanted results. But in the mid-to-long-term, we will need a proper three-dimensional data structure to provide access in logarithmic time. I have thoughts already around a three-dimensional generalisation of zip-trees (and, possibly, G-trees). But these details are a topic for a different time.

Speaking of improved local data access: we currently provide only embedded Willow storage, but long-term we would like to move to an actual database server with which multiple applications can interact concurrently (using capabilities to scope access rights, of course). The basics of this are fairly straightforward, but the challenging part is making push-based APIs work. Ideally, we'd like applications to be able to maintain persistent subscriptions even across several sessions. This would require the database server to maintain an event log, and applications would supply an offset at which to resume their subscription upon connection. When an application falls too far behind, it would catch up via set reconciliation. This sounds nice in theory, but the actual specification and implementation process will probably be rather thorny.

And after all of that, there is Willow Confidential Sync. I assume that we will learn enough from the WTP to warrant reworking the confidential sync spec. And then we will need to implement it, of course. Which feels a bit daunting right now, yet also exciting — confidential sync is were so many of our design decisions converge into a package that will likely be greater than the sum of its parts. I want to live in the world where you can integrate that package into your application designs with miniscule effort.

Other Willow-related plans include benchmarking suites, transactional APIs for our local data storage, a peer-sampling service (possibly in concert with confidential sync), and implementing the Willow URIs spec. Then there are application ideas — Rummager, the Cobweb, perhaps libraries of common UI components. And beyond Willow, we still want to release Macromania, and we have too many ideas for other side-projects to even start enumerating them here.

This is already far more than we can hope to accomplish in 2026. And we’ll doubtlessly accumulate even more ideas along the way. 2026 will be a busy year, but also a fun one, and one brimming with potential.

~Aljoscha

I want to share an application idea I have been dreaming up: the Cobweb. The Cobweb is a hypertext system with four distinguishing characteristics:

First, it has a built-in operator for transcluding multiple documents at once. Think like an iframe in HTML, but for a whole directory, or even multiple directories accross domains. With this functionality, you can replicate design patterns such as microblogging timelines or nested reply threads, while requiring neither ad-hoc server-side logic nor ad-hoc client-side logic. Everything simply arises from the document markup. I have written a blog post exploring this approach more thoroughly here.

Second, by virtue of being built on Willow — hyperlinks take the form of Willow URIs, of course — the Cobweb provides mutability without link rot. We need to normalise such systems.

Third, extreme simplicity. The complexity of the web necessarily concentrates power in the hands of browser vendors. I consider it imperative for alternative systems to pursue a contrary approach without compromise. The markup of the cobweb is essentially a subset of markdown, together with a bulk transclusion operator. The only inline media beyond text are images; only a single, simple image format is supported. Arbitrary files can be added as attachments at any position in the text, but without any special rendering logic beyond, effectively, a download button.

Fourth, efficiency. Markup is stored in a computer-friendly format (you might edit things as markdown, but that markdown would be saved in a binary format) — possibly even designed so you can mmap documents into memory and then work with them directly. The image format employs a form of interleaving that allows resource-constrained clients (or clients in low-bandwidth environments) to download only prefixes of images, which can then be rendered as low-quality versions of the final image. Bab ensures the integrity of the prefixes. Compression everywhere, though always preserving simplicity and thus ease of implementation.

The end result would be fairly constrained compared to the www, yet still intriguingly powerful — especially with bulk transclusion. And I envision extremely performant and low-memory-footprint Cobweb browsers, which would still manage to make everything really slick: great typography and customisable styling, inline-editing and authoring, real-time updates of transclusions, excellent UX around access control, storage size management, and so on.

Inspiration includes Gopher and Gemini, Man Pages and IETF RFCs (seriously, just imagine having something like the Cobweb instead of these — it keeps getting better the longer you think about it!), Mastodon, TiddlyWiki, and Joplin.

~Aljoscha

Last Sunday we received the news that our proposed talk for FOSDEM had been accepted. I’ll be presenting “Willow - A family of peer-to-peer storage protocols” in the Local-first, sync engines, and CRDTs track. I’ll do an overview of the Data Model, Meadowcap, etc, but I’d like to also get into some of our motivations, and maybe we’ll have some surprises too.

The last time I did a talk like this was in the Summer of 2023, at Offline in Berlin. We’d just started working on Willow, and we thought it wouldn’t be too long before we had a working implementation. Innocent days.

Looking back two and a half years later, without complete implementations of everything, is bittersweet. I recognise all the cul-de-sacs we wandered down, the missteps we made, and how I’d do things differently if I could go back in time. But in order to become the me who can recognise my own failures today, I had to go down all those dead ends first with my own two feet. There was no other way available.

So in the end I’m just grateful I get the opportunity to still do the things I wanted to do, even if it’s taken longer than I’d hoped. On many levels.

However, I do not want to get up on a stage and talk about Willow again, and then tell interested folks that they need to wait a bit longer: we’re aiming to have implementations of persistent Willow storage and the drop format completed by the time I head to FOSDEM.

ngl it’s going to be a little crunchy. To have persistent Willow data storage, we need persistent Bab, so this week I implemented a filesystem backend for Bab, implementing Bab’s ByteStorage trait over a thin wrapper over async-fs’s File. Aljoscha did a great job of designing this trait, I needed to know next to nothing about how Bab works to get this thing working. Ignorance truly is bliss.

Ping me If you’d like to meet up at FOSDEM!

~sammy