worm-blossom

2026Week 2122 May

“consistent in-universe rules for how glasses work”

This is the final week showcasing material from Sammy’s archive. I saved some of my favourites for this one =)

~Aljoscha

A drawing of Sammy, with a bandana and sunglasses on, and a swollen chin.

Dear readers, I am kind of back. I had surgery a few weeks ago, and until today you could always hear the faint warning beep of having only a single heart container filled. Today I have just enough hearts to write a short editorial for famous music blog worm-blossom.org!

Outside of sleeping, eating, napping, and reading, I haven’t been up to much. Certainly no computering, or even drawing. But I’ve been walking. This is walking for the sake of it, without a purpose (getting bread) or a destination (my studio). I just wander around the neighbourhood, ambling down different streets, taking inefficient detours. I love how automatic walking is, you put one foot in front of the other and pretty soon they don’t need your supervision anymore. And then your mind starts wandering along with them, peeking down inner side streets.

My walks right now aren’t like how I imagine Aljoscha’s are. There are no ideas or insights, only impulses, quiet excitement, images. Maybe, someday, they’ll assemble into something which can be used, but for now all I have (all I need?) is forward propulsion into the next week.

~sammy

Yay, Sammy is (kind of) back! Though I feel like she needs to catch up with a couple of changes: clearly worm-blossom.org is not a popular music blog but a popular data structure blog. So let me tell you more about data structures! (I’m sorry, but this is what I thought about this week...)

I think I made a mistake with the two-dimensional skip-list of last week: the links from top-right and bottom-left sublists back to the pivot are not needed. The variant without them should actually be the default. In particular, this is not connected to the two-kinds-of-edges observation about one-dimensional skip-lists, I got something mixed up there. And while removing these edges destroys unilateral connectivity, you gain the property that there is a unique path from the "least" vertex to any other vertex.
I made some progress to generalising G-trees to the multidimensional setting. In the one-dimensional setting, you can pair up each item in a G-node with a lesser subtree, and then you add to the G-node the single subtree of items of lesser rank that are greater than the greatest item in the G-node. In the two-dimensional case, things are more tricky. You can pair items with a bottom-left and a top-left subtree of lesser-ranked items, and this works fine. But what do you do about the items that lie to the right of any items of the G-node? If you add a single right-subtree to the G-node, you end up not generalising the 2d-zip-trees; to do that you'd need to also split up those right items along the y axis. But then you get a number of right subtrees scaling with the number of (terminal) items in the G-node. And how do you (elegantly) store this variable number of subtrees?
A more fun observation regarding multidimensional G-trees: you get 1d-zip-trees by instantiating 1d-G-trees with sorted linked lists as the inner set datastructure. And it just so happens that sorted lists are what the layers of a skip-list are. And for the multidimensional case, it looks very much like you need to indeed instantiate k-dimensional G-trees with k-dimensional skip-list-layers to obtain the k-dimensional zip-trees. Well, assuming the whole right-subtree problem had been solved =S. But this feels very, very neat to me!
Let me get out one more point that requires good understanding of G-trees: I came up with a new interesting instantiation, and a painfully-obvious-in-retrospect one at that: use almost-complete binary search trees as the inner set data structure. Where zip-zip-trees try reduce the height penalty of having successive items of equal rank (i.e., with no item of higher rank in between them), this instantiation simply defines the problem away by always using a minimal-height tree to arrange such sequences. Maintaining these is inefficient (you cannot do insertions and deletions on almost-complete binary search trees in logarithmic time), but we know that G-nodes are small with high probability, so we do not need to care. This instantiation is still history-independent (because almost-complete trees are required to “fill the lowest layer from the left”, they are uniquely defined for any item set — and if I'm missing something here, then you can always redefine them in a history-independent way). The only drawback I see, aside from somewhat complicated insertion and deletion algorithms, is that this instantiation is not clamping-invariant.
Finally, a short observation on skip-lists: the same generalisation that goes from zip-trees to G-trees also works for skip-lists. And it is a lot more simple and obvious for skip-lists even: you keep the inter-layer connections, but instead of using sorted linked lists as individual layers, you use arbitrary set data structures as the individual layers. I've seen some papers that do this with specific replacement data structures, but none that actually works out generalised algorithms, and the algorithms that the underlying set data structure has to provide. This should be fairly simple though; certainly less elaborate then the G-tree case. And from this, you get at least one immediately interesting data structure: the skip-skip-list, which uses skip-lists for its layers (fully analogous (and properly isomorphic to) zip-zip-trees).

I'm starting to think I should do my phd about this sort of stuff, instead of older research that grew out of append-only logs and that I barely care about any more...

~Aljoscha

2026Week 2015 May

“I refuse to use a self-referential motto”

A digital drawing of two people sitting in a stylised tree. — In my headcanon they are sitting in a one-dimensional zip-tree.

Like last week, the collection of images comes from Sammy’s archive. Except for the hand-drawn sketches of data structures, those are mine. May the contrast bring out the quality of Sammy’s work even more.

~Aljoscha

I made a thing: a visual guide to zip-trees.

Every once in a while, I think about data structures. Efficient implementations of the three-dimensional data model of Willow require three-dimensional data structures. And those are tricky: whereas the one-dimensional case admits various search trees that allow for both querying and updating in logarithmic time, the multi-dimensional case is more difficult (here’s a rough introduction). There are problems with all existing data structures, so I have pondered a generalisation of zip-trees to three dimensions for a while now.

This week, I finally worked out the last missing algorithms. As part of my note taking I developed a graphical notation that could record the algorithms a lot more concisely than pseudocode can:

A hand-drawn diagram representing an algorithm to split a two-dimensional search tree at a given point. — Splitting a two-dimensional zip-tree rooted in `R` at point `P`. If you know what the various elements mean, this drawing (almost) completely describes the algorithm.

While I used this notation only as an aid in developing the algorithms and as a means of recording them, I naturally started to wonder whether the notation contained enough information to fully replace pseudo-code in a proper writeup. I need to share my algorithms for them to be useful to anyone, after all, but writing pseudocode is a pain. In particular, when it comes to symmetries and rotations, pseudocode is either verbose or littered with difficult-to-grok parameters. The graphic notation, in contrast, handles rotations and symmetries gracefully.

So I started refining the notation a bit: properly handling empty trees, teasing apart individual diagrams into sequential steps, incorporating item ranks, etc. Additionally, I started wondering about generating the diagrams instead of drawing them by hand. And when I was somewhat confident that all of this could possibly work and even be useful, I decided to create a proof-of-concept document based on one-dimensional zip-trees. And that is the thing I made this week.

~Aljoscha

Before the graphic-notation-frenzy took over my week, I made some additional progress on multi-dimensional data structures. I did a complexity analysis of the multi-dimensional zip-tree algorithms. In a tree of logarithmic height, query times are logarithmic. Update times are logarithmic on average, but they can be in O(n^0.792) (master theorem for 3 subproblems of size n / 4) in the worst case. This is not great, but probably good enough maybe? At the very least, there are such results in the first place, whereas R-trees and their ilk typically just hope for the best.

Okay, this update is now officially turning into a data structure fiesta, because I have one more insight to share, but it takes a bit of preliminary work. Let me start with a sketch of my definition of two-dimensional zip-trees.

Given a set of points in a two-dimensional space, and a function from those points to ranks (natural numbers), the 2d-zip-tree on the set is a 4-ary tree, defined recursively: the root is the point of maximal rank (I’ll simply write "maximal rank", implicitly assuming that there is some deterministic tie-breaking in place in case of duplicate ranks).

Next, partition the remaining points into four sets:

bottom-left (less than the root in both dimensions),
top-left (less that the root in the first dimension, greater than the root in the second dimension),
bottom-right (greater that the root in the first dimension, less than the root in the second dimension), and
and top-right (greater than the root in both dimensions).

Recursively build the 2d-zip-trees for these sets, and use the resulting trees as the bottom-left, top-left, bottom-right, and top-right children of the root.

A hand-drawn diagram representing the recursive nature of 2d-skip-trees. — Two-dimensional search trees, with rectangles indicating subtrees.

This definition directly generalises the corresponding one-dimensional definition.

I want to sketch a definition of two-dimensional skip lists, but to get there we first need to take a look at one-dimensional skip-lists. I’ll assume familiarity with the concept, but want to present an alternate, non-standard definition. This definition makes the isomorphism between skip-lists and zip-trees much more obvious than the standard definition.

Given a set of points with associated ranks, we can define the bottommost layer of the skip-list recursively: select the point of maximal rank, call it the pivot. Partition the remaining points into two sets: those less than the pivot, and those greater than the pivot. Recursively construct the bottommost skip-list layer for each of these sets. Add an edge from the greatest point in the lesser recursive construction to the pivot, and add an edge from the pivot to the least point in the greater recursive construction.

A hand-drawn diagram representing the recursive nature of a single skip-list layer. — A single layer of a skip-list, constructed recursively. This surfaces a hierarchical nature that is obscured by the traditional definition.

For the higher layers, you proceed identically, except that you filter out items whose rank is less than the layer count. Then you add inter-layer links as usual.

This definition might seem overly complicated, given that it simply results in layers that are ascendingly sorted linked lists. But it has two advantages: first, it is utterly obvious how the definition relates to that of zip-trees, and second it generalises nicely to higher dimensionalities.

From the preceeding definition of one-dimensional skip-lists, we can easily get to a definition of two-dimensional skip-lists. And the connection to two-dimensional zip-trees will be just as obvious as in the one-dimensional case.

Given a set of points in a two-dimensional space, with associated ranks, the bottommost layer of the 2d-skip-list on the set is defined recursively: the pivot is the point of maximal rank.

Next, partition the remaining points into four sets:

bottom-left (less than the pivot in both dimensions),
top-left (less that the pivot in the first dimension, greater than the pivot in the second dimension),
bottom-right (greater that the pivot in the first dimension, less than the pivot in the second dimension), and
top-right (greater than the pivot in both dimensions).

Recursively build the bottommost 2d-skip-list layers for these sets. Add an edge from the "greatest" (defined later) element of the bottom-left one to the pivot, and add an edge from the pivot to the "least" (defined later) element of the top-right. Add an edge from the pivot to the "least" elements of the top-left and bottom-right ones, and add edges from the "greatest" element of the top-left and the bottom-right one to the pivot.

The "least" element in a subset is defined as follows: throw away all elements that are greater in both dimensions than some other element in the subset. Of the remaining elements, the one of least rank is the "least" element. Analogously, the "greatest" element in a subset is defined as follows: throw away all elements that are less in both dimensions than some other element in the subset. Of the remaining elements, the one of least rank is the "greatest" element.

A hand-drawn diagram representing the recursive nature of a single 2d-skip-list layer. — A single layer of a 2d-skip-list, constructed recursively. Unlike the one-dimensional case, the hierarchical nature is required to make sense of the construction, because ranks influence tie-breaking in the choice for "least" and "greatest" elements.

And then you do the usual business of constructing sparser layers and connecting the layers. The resulting data structure supports efficient range queries (unlike Nickerson’s ad-hoc constructions), and is isomorphic to two-dimensional zip-trees.

The structure of the resulting graphs is quite neat: effectively, you get a linked list from the bottom-left to the top-right, with choices between incomparable successor candidates tie-broken by rank. This main diagonal doesn’t contain all items, but it sprouts off smaller diagonals, which go from the bottom-left to the top-right of smaller quadrants. And those have smaller sub-diagonals themselves, and so on. And because those sub-diagonals are connected back to the mid-point of their super-diagonal, you get the expected connectivity properties of one-dimensional skip-lists: for any two vertices in the data structure, there is a directed path from one to the other.

For higher dimensionalities, the pattern generalises nicely: you have a primary diagonal from the least to the greatest element, and then a bunch of sub-diagonals, each again with their sub-diagonals.

A final fun fact about two-dimensional skip-lists: if you do not connect sub-lists back to the pivot of their super-list, you loose the fact that there's a directed path between any two vertices, but every vertex is still reachable from the least (bottom-left-most, ties broken by minimal rank) vertex in the list. In fact, searching for items starting from there (and also doing range queries, I think), still works. This is analogous to my observation about two kinds of edges in one-dimensional skip-lists in Figure 18 of the G-tree paper.

2026Week 1908 May

“un jour je serai de retour près de toi”

Sammy is taking some weeks off, so I will be publishing the next few updates on my own. Unlike the last time, Sammy left me with quite a collection of drawings to spruce up the place in the coming weeks.

~Aljoscha

I lack context for most of these images. Some are “drawings” and some are “dreams”.

Some are a quite old, others more recent, and I have little idea which are which.

What I do know is that I am giddy to share these, despite Sammy probably groaning about my curatorial and presentational choices.

And I remain continually grateful that a person with this sort of creativity and skill is choosing to collaborate with me.

Speaking of collaborating on things: there's all this software stuff we are working on. I am still rather slow when it comes to making progress. Still have a cough that refuses to disappear, and still have a bit of a hard time focussing on programming.

The other day, I had a surreal experience of alienation. I opened my text editor, looked at the code, and for a few moments I saw that code as if I didn't know how to program. A jumble of hostile characters — all sorts of parentheses, isolated words of English, random punctuation; and everything in a stark monospace font, with high-contrast colours assigned seemingly at random. Utterly inhuman and hostile.

And then things started to fall into place again. The parentheses are balanced. The indentation gives high-level structure. The fragments of English are terse commands. Commands whose semantics I know.

And yet, I was unable to put everything together into full understanding. Some of the functions do so much that even a single line of code conveys more information than I can grasp at a single moment. And there are 50 of these lines on the screen at a time. I have a rough picture of what the code should do, but I know for certain that the actual behaviour deviates from my intentions. The computer has no notion of a rough picture, it must work on a level of detail that I am fundamentally unable to handle. So our exchange will necessarily be fraught with frustration.

This experience has passed, and I am now in the process of making the high-level rough picture of the Bab APIs more precise. Throwing a fuzzer at the thing, finding integer overflows, documenting and asserting invariants to turn these low-level failures into workable semantic concepts. Not the most enjoyable kind of work, but it has to happen. Perhaps someone else would be faster with this than I am, but that line of thought doesn't actually get any work done, so...

~Aljoscha

We're listening to...

Kollaps

Einstürzende Neubauten

Ten internet points to anyone who knows about the connection between this band and this week’s motto.

Call for Pixel Art

A worm-blossom project we have not really posted about here before is the Seasonal Clock. Over on Secure Scuttlebutt, Gergely Polonkai has started a neat project: porting the seasonal clock to the Pebble e-paper watches. Quoting their post:

I’m very bad at making anything that even borders artistic. If anyone around here has the time to draw all 24 emojis in 32×32 and 48×48 sizes, both in 1bit and using the Pebble palette, I’d be very grateful.
I’ll release it as open source (as many other watchfaces out there), but I’m willing to pay a commission fee to whoever picks up this task.
Here’s a quick draft of the face as it looks in my head (just with your emoji art and better text 😁):

So if anyone feels like exercising their pixel art skills, please reach out. Gergely is on the worm-blossom Discord, and I can also relay messages via Scuttlebutt.

2026Week 1801 May

“I will narrativise until proved otherwise”

A four panel comic titled Blossoquest.

In the first panel, the Bottleneck looks at Bonnet. "Why me?" he asks. "Aw stop it now" she replies.

"I know how you broke everyone out of Bigburg", she says. In this second panel, we see the Bottleneck lifting his head off of his shoulders, light emanating from his neck. He stoands surrounded by other figures, a huge hole broken into a brick wall.

In the third panel, the Bottleneck ruminates to himself. "Bigburg...". In the background, we see distorted, angry, sad faces.

In the fourth panel, we see the giant buildingi in the horizon. Bonnet says "Where that train's headed makes Bigburg look like... Smallburg! You see why I'm talking to you now?".

bab-hash.org is online!

We've launched a new website for Bab over at bab-hash.org. You don't know what Bab is? Go over to the website and find out! It's informative and our cutest website yet.

bab_rs is particularly unique as a kind of 'batteries-included' API: it goes beyond creating digests, and provides APIs for persisting Bab-annotated data to disk. We've been using it in Willow's persistent store implementation and it's something we're very proud to share.

A drawing of Sammy, one arm holding up her head with a pencil in it, the other resting on a piece of paper.

This week I wrapped up my work on bab-hash.org! I’m very happy with the cuteness of this website, not just in how it looks, but also in how succinctly and sweetly it conveys the purpose of Bab.

I always start out with drawing logos and visual motifs.

With all due respect to the BLAKE3 fans out there, it’s not easy to make an engaging website about a family of hashing functions. What’s this stuff for? Why should anyone care?

We designed Bab for peer-to-peer data exchange. This is a context where we expect interrupted transfers, we expect malicious peers, and we expect to be connected to many peers at once. These scenarios lead to real problems and opportunities for ordinary people: nobody wants to have to start over an interrupted download; nobody wants to unwittingly store (or even propagate) illicit data; and everybody wants fast downloads.

These are very tangible applications for something very abstract, and that’s exactly what I wanted to foreground on Bab’s website. I started thinking about each of these settings as a transfer, with a source on one side and our user on the other, with little comic panels no less!

Or I could represent these scenarios as familiar download windows with styled progress bars. A very familiar UI.

Some marker sketches of both the connection comics and dialog boxes.

Which was better…? In the end I decided to do both.

While styling the dialog windows I wanted to play with a classic computer feeling, so I plonked in a pixel typeface designed by my friend Robin Mientjes, a typeface which was originally designed for a webcomic I made a long time ago. The version used on bab-hash.org is actually a hugely expanded version of that typeface, and it’s so nice to have the extra symbols, italics, and family variants!

The pixellated aesthetic of the download windows then natually took over everything else. I wanted a fuzzy, hand-drawn feeling despite how low-res the artwork is, so I drew all of the artwork using a stylus with a desktop pixel art editor called Dottie.

The setup of mirroring a desktop app to the tablet so I could use the stylus was a bit convoluted, but got the job done.

For me the real star of the website remains Aljoscha’s specification. It has wonderful interactive diagrams which you can step through, and which use colour in such a smart way. It was invaluable in figuring out how to approach this site’s design.

And of course, the site is totally static, and built with Macromania. I don’t even think about my usage of Macromania anymore, it’s become such an everyday tool for me. We really need to release it someday.

Speaking of someday, I'm going on a short break! I'll be back in a few weeks. I've provided Aljoscha with materials from my archives to decorate the place with while I'm gone.

~sammy

Whereas Sammy's editorial represents a burst of concentrated productivity, I am still in a phase of intake and reflection. I'm still nursing a particularly persistent cold (I'll have to pass on singing in the Berliner Philharmonie this weekend :[), but at least my mind is slowly drifting back to programming again. Optimised Bab slice streaming won't test itself, after all. And then there's wrapping up the Bab grant by implementing a storage backend that can store multiple subslices of a single string, and append to those slices concurrently. We now have a website that promises parallel downloads from multiple peers, after all, so the implementation better catch up.

Here's some music I improvised today:

Compared to the miniatures from last week, I think you can tell that I stabilised quite a bit. So I'm optimistic I'll get some worm-blossom work done in the near future. And with Sammy taking a break, I better should.

~Aljoscha

2026Week 1724 Apr

“Fun? What's that? Let me find a paper for you”

This week I have been working on the website for Bab. This effort has finally taken the turn where the initial psychological lift has been done and now I am looking forward to each session of working on it (i.e. I have reached the point where I am making drawings for it).

I've also taken on the duty of curating and stewarding the p2p tent at this year's DWeb camp in Alte Hölle. If you're interesting in presenting, holding, or just meeting up, please get in touch.

There is no comic this week, but there is a terrifying ~~dependency chart~~ skill tree for our Willow related efforts.

Slight feeling of biting off more than I can chew, but I've bitten now!!!

~sammy

These past weeks have been a confluence of stuff happening. I didn't manage to write a single line of code this week. So, uhm, have some music at least.

Also, it looks like looping beepbox miniatures have become my default mode of self-expression. Huh...

~Aljoscha

2026Week 1617 Apr

“you started reading William Blake, it is time to seek help”

A four panel comic, titled 'Blossoquest'.

In the first panel, we see a train moving across the horizon. Above it is the text "That train's movin' fast".

In the second panel, we see a train track leading into the distance. A giant, wide structure stands on the horizon, a cloud looming over it. In the cloud is the text "and it's goin' nowhere good".

In the third panel, we see the Bottleneck looking down on Bonnet. She asks him: "Will you stay here, Bottleneck?".

"Or will you be with us when we get there?" she asks him in the final panel.

Persistent Willow Store

We have released version 0.5.0-alpha.1 of the willow25 crate. This release provides the storage module for working with Willow stores. In particular, it offers the PersistentStore for saving Willow data on disk.

Note that this is an alpha release: we expect the persistent store to be buggy. And we hope that some of you are brave enough to play around with it regardless, and to then report the bugs you encounter to us!

Late last year I was sitting in on a session about a shutdown resistant chat app. We were told that the problem with other shutdown resistant chat apps is that their experience sucks, and so to avoid that this particular app was going to copy the interface of Signal as closely as possible. A few minutes later the peer-to-peer aspect of the app was introduced, as was the idea that a message sent by a user a week ago might only arrive today. I asked them how they squared this behaviour with their stated goal of being like Signal, where messages arrive very soon after being sent. No answer was given.

Chat interfaces create the expectation of messages arriving in a orderly, timely way. But peer-to-peer systems are meant to handle networks where messages are possibly exchanged long after they’ve been authored, and where users may have not seen each other’s messages and aren’t aware of what they’ve missed. Is it wise to re-use interfaces built around a completely different type of network?

So I hosted a very enjoyable session in Prague about rethinking interfaces for peer-to-peer applications, specifically resisting the dominant form of the chat app.

Every device in a peer-to-peer network will have a different ‘view’ of that network. Are there precedents for users understanding that they might have a different view of the same ‘thing’? Arguably email has set this precedent. Can we piggyback on the rich history of email client design?

There are interfaces which can ‘collapse’ many messages into an interface where order doesn’t matter: emoji reactions are like this. Many people may send reactions at different times, but they are reduced to a single count where order is hidden. Can we do something similar for more complex message types?

Different views of a network raise the question of archival: what’s the canonic state of a network? Does this imply that peer-to-peer systems are inherently ahistoric and thus resistant to archival? How can we take advantage of that?

By the end of the session, we had two wonderful emblems for the opposing structures of centralised and peer-to-peer messaging:

The linear, causal, ordered ledger of the centralised system; and the overlapping, scattered, unlinked pinboard of the peer-to-peer system.

~sammy

links of the week

The William Blake Archive - I didn’t know there was a high-quality website that makes the works of William Blake available. Now I do, and so do you. Also, the Proverbs of Hell are phantastic. You never know what is enough unless you know what is more than enough.

~Aljoscha

2026Week 1510 Apr

“pininit”

A four panel comic.

In the first panel, Aljoscha shields his eyes with his hand and asks: "ugh... where am I?"

In the second panel, we see many screens displaying silhouetted figures. One of them says "Aljoscha! You have been brought before the super secret p2p shadow council so that you may join our ranks..."

In the third panel, Aljoscha says: "I accept your invitation. I look forward to making many theoretical contributions to th-"

In the fourth panel, one of the silhouetted councilmembers interjects: "Woah! Hold on! We just want someone to write our grant proposals". Another council member adds: "that shit is tedious". Aljoscha says oh.

A drawing of Aljoscha, fingers interlaced, eager to deliver some interesting news.

At the workshop in Prague, a surprising number of people had been on Secure Scuttlebutt (SSB) at some point, and SSB also kept popping up as a reference point in conversations. And a few days ago, someone on our Discord was asking about the relation between Willow and SSB. So I'd like to reflect a bit on how SSB still influences my design work.

I still subscribe to several of the mantras of SSB. The most important ones:

No global singletons: if a system depends on any kind of global singleton — be it a server, a network, a legal entity, or a blockchain — it is brittle and ~~can~~ will be co-opted.
Against consensus: those parts of a system that depend on global consensus between all participants will be unable to evolve as needs change. My personal take on this mantra is more nuanced than its classic formulation: I believe that there is value in a minimal foundation that is guaranteed to remain unchanging. Eventually it will have to be replaced because of its inability to adapt. But until that point, it will provide a stable foundation, superior to a continuously moving target that accrues complexity over time. As long as such foundations are clearly labeled and allowed to retire eventually, things are great. But: these foundations should be minimal. And everywhere where evolution is desirable, there should be no need for global consensus.
Free listening: free speech has to be counterbalanced by the ability not to listen. Listening should be opt-in, not opt-out.

Many other aspects of SSB have not aged well. I've detailed my views on immutability-by-default elsewhere. Another pattern I would not want to see repeated on top of Willow is the public follow-graph of SSB: everyone publicly recording whose data they want to follow. While this enables a nice replication mechanism with the ability to transitively fetch data for improved reliability and discovery, the public nature of this graph also enables spidering and surveillance. This tradeoff feels inacceptable to me by now.

More generally speaking, SSB was emphasising discoverability and interlinked data, in order to optimise for network effects and virality. The public follow graph, immutability, a single multi-purpose log per user... many SSB design decisions are in support of fostering network effects. But these are also the design decisions that make the protocol unsuitable for vulnerable users.

The tradeoff certainly payed off, chances are SSB would not have reached its level of adoption without these deliberate design choices. Perhaps projects such as Willow are fated to being crowded out by projects that emphasise virality over privacy. At least as long as the majority of tech users are not vulnerable users themselves. This feels sobering, but it cannot change the kind of technology we are building — because we desperately need this tech to be available and reliable.

So while the average techie is safe and confortable, I guess we'll simply have to rattle a tin can every once in a while.

~Aljoscha

Shout-outs!

Aescsocket opened not one, not two, but three pull requests to willow-rs this week. We now have a typesafe EntryBuilder, can derive the Display and Error traits, and will soon have some convenient tooling for running a whole bunch of cargo commands in one go. I don't quite know whether they are a polygonal dog or a markov chain, but in either case, thank you!

This Danmw person keeps contributing to Ufotofu. And here I thought making them a maintainer would pacify them. Now we have nicer skip adaptors, and new filter adaptors. Yay!

Here's a clean version of the lightning talk I gave at the Dweb virtual meetup the week before last. ~sammy

Why is it called worm-blossom?!

← Previous instalment

why is this website called ‘worm-blossom’? In this series we will explain why in a concise manner.

Let's talk about sets, baby

It is late 2019. Aljoscha Meyer has a scheduled call with someone who reached out from Secure Scuttlebutt. gwyl? Something like that. They want to learn about ‘Bamboo’, a kind of append-only log Aljoscha had designed some time ago. They’re clearly keen to build something with it, but Aljoscha gives it to them straight: append-only logs aren’t really good because you can’t use the same identity across multiple devices. Okay then. Predictably, the call doesn’t really go anywhere, and the two of them shall not interact for a long while.

When Sammy ends the call, she can’t help but feel like she still doesn’t have any idea how this peer-to-peer stuff works. And didn’t that Aljoscha guy seem a bit… disillusioned?

But Aljoscha is not going to let a little thing like disillusionment get in the way of what he’s really interested in: abstract nonsense! With regular expressions, choice and concatenation are dual. Doesn’t this suggest that unordered sets are dual to logs? And whereas you cannot easily combine two logs into a new log, two sets certainly combine into a new set. If only there was an efficient algorithm for computing set unions across two devices (i.e., to efficiently sync), then you could easily achieve composable multi-device identities.

A few months later, Aljoscha presents his set union algorithm at p2p-basel. Originally his session had an hour allotted to it, but discussion runs over to two hours. There’s clearly a deep interest in the notion of sets, but no implementations come of it yet. And Aljoscha is certainly not going to write any code himself.

Months later still, Aljoscha is browsing Secure Scuttlebutt, and on a whim joins a kind of virtual hangout which another user named Cinnamon has organised. Aljoscha joins the call, and listens in on a showcasing of… React components? But it turns out Cinnamon also has an interest in sets, and soon Aljoscha and Cinnamon are the only ones left in the call. Cinnamon is working on something called Earthstar, and has yet to figure out how to efficiently synchronise their mutable, unlinked datasets.

Cinnamon also tells Aljoscha about their terminal diagnosis. Cancer. Aljoscha doesn’t really know how to respond to that, but the call leaves a deep impression on him. When he selects the topic for his masters thesis in early 2021, Aljoscha decides to flesh out his set union algorithm, as a present to Cinnamon.

Meanwhile, Cinnamon has been figuring out what to do with an enthusiastic new contributor to their project.

A prominent topic of last week’s gathering in Prague were sneakernets. There is something about this method of transporting data — the ultimate fallback mode of peer-to-peer transport — that seems to capture people’s imaginations. Embodied control of where data is, and tacit recognition of whose hands it is in, understandable to anyone.

On the first day I found my own understanding (and implementation!) of sneakernets being interrogated. What is Willow’s view of the sneakernet? Oh, so a user needs to choose what is in this ‘drop’? How do user's express what they want from others? They can’t? I see.

By the next morning, my view of sneakernets was dismantled (alongside a few others) to construct a new view, one where sneakernets take on an almost homeostatic nature. In this model of the sneakernet, data is not only pushed into the world, but the need for certain data is also expressed. The overlap between these two forces creates a hot zone of data worth transporting.

Reeling a little from this model, I started wondering if there was a way to make it so that users could query a Willow drop, shifting its design from linear access to a random access (thus neatly nerd-sniping Aljoscha, who mentioned this idea first thing last week).

Then Aljoscha announced at breakfast that sneakernets were really about congestion control. As I understood it (while trying to carefully eat from a bowl I’d filled with entirely too much yoghurt and fruit), if you have a USB drive filled with data from many people, at some point you’re going to hit storage constraints and have to choose what’s worth sending. This is analogous to throttling, and is effectively congestion control.

But here’s the tricky (Aljoscha: fun) part: sneakernets are non-interactive, so you have the problem of congestion control without explicit feedback. But perhaps you could use implicit feedback of tracking which data you receive from other people, and use that to prioritise what to send yourself?

A day after the event ended, we received this message:

We are the Memory Commons, just that nobody told us about this when we met in Prague. It is memory that we care about. Some call it replicas, other fancy about USB sticks. When discussing Sneakernets, Aljoscha suggested that this is a discussion on congestion control, which now makes even more sense as congestion control is about memory of the router packet queues, managed by a social contract that can't be technically enforced. Memory commons all over the place.

When we take this view, we must be mindful of the distinction between a commons and a hoard. We spent the last thirty years building the memory hoard. This hoard’s purpose went far beyond archival, and into the wholesale weaponisation of data. While the constraints of peer-to-peer certainly encourage us to prune and forget data, we should still steward the memory commons mindful of the fact that the value of data is in how it affects us, and nothing more.

~sammy

2026Week 1403 Apr

“you say beep, we say boop”

An illustration of many overlaid images, vignettes from Sammy and Aljoscha's busy week in Prague.

I went to a workshop, and I was not immediately struck down by illness. Yay! I am completely exhausted as I am writing this on the train back: the workshop was well-facilitated and the participants were great, so I ended up overexerting myself quite a bit. I do want to share some notes I took during a fun session of discussing the limits of CRDTs.

Also, I may have gotten nerd-sniped into sketching an alternate version of the Willow Drop Format (with the creative working title “Super Drop Format”) that supports efficient seeking within encoded drops: a super drop file would store a three-dimensional search tree, so you would be able to obtain all entries in a given area in time logarithmic in the total number of entries in the whole drop, or linear in the number of entries in the area (whichever is worse). But I'll be pragmatic and give this format extremely low priority. Probably.

~Aljoscha

Like Aljoscha, I am completely spent after a very good week. It has been 24 hours since I got back home and I think I could still do with another big sleep. Was this because of all of the thought-provoking discussions we had, or the inevitable fallout of ingesting more sugar in four days than I have in the last two months? Who can say.

A cartoon frog wanders in a quasi-realistic airport. — Life be like that sometimes.

For that reason, I am going to shower you in drawings today, and go in depth in the coming weeks. I have so much material on sneakernets, designing new kinds of UIs for p2p systems, and thoughts on collaboration in our little niche space that we're good until May probably.

But, if the other attendees — or especially the organisers — of the event are reading this: thank you so much for a wonderful week.

~sammy