worm-blossom

This Monday I took the train to Rotterdam to go speak at XPUB.

Before we started, Doriane (who had invited me after we’d met at FOSDEM) gave me a quick tour of the XPUB facilities, way up on the top floor of a building overlooking the Nieuwe Maas. I was really enamoured with the atmosphere of their space, which had zine-filled shelves, boards crowded with posters, and students working away in cosy, personal spaces. It didn’t at all have the feeling of a curated display case, but rather a living, breathing space with work flowing through it. Nice.

And as for my part: we neatly avoided a sammy slideshow situation (thank you doriane) and instead had a kind of guided discussion for two hours, in which we hardly talked about Willow. It was great. I had a big chalkboard behind me on which we assembled a timeline of nearly three decades of peer-to-peer trials and tribulations, from Napster’s legal dismantling to the state-sanctioned deactivation of Apple’s Airdrop. Interjections from the rest of the room were frequent and always thoughtful, and when we finished at 19:30 it felt like we could have kept on going.

Like I said last week, I couldn’t leave it on a downcast note. After all, what are we going to all this trouble for? I argued that we had an opportunity to remember that data is just a byproduct, and that the point is for it to change us somehow. Peer-to-peer protocols have some unique features which encourage us to learn to become conscious stewards — rather than hoarders — of data.

Anyway. Great time, great people, hope to be invited back again some day.

But that’s not all I got up to this week. I also implemented payload storage in the new Willow persistent store, using the Bab implementation Aljoscha has been working on. Streaming, verified storage! It’s a beautiful thing. Or it will be a beautiful thing once we’ve got all the bugs ironed out.

~sammy

Do I write a thoughtful editorial, or do I simply finalise this rather late update? While I have no idea about the identity of the BOTTLENECK in Blossoquest, I sure know that for this week’s update I was the bottleneck. But maybe there is time for sharing a few fun ideas still.

1. A live-coding environment for shaping the sound of digital instruments. Basically, you edit a function that takes as inputs a frequency, a volume level, the time since the note was triggered, and the time since it was released, and you return a value between -1 and 1. This function is called 44000 times per second to produce sound. Oh, and the function has access to the samples it produced for the past x seconds, so that you can employ feedback and self-reference in shaping the sound. (shoutout to the best repo on github, but this would have a live-refreshable js interface instead of compiling rust programs into command line utilities)
2. A theremin-like, mouse-based (or touch-pen!) UI for playing the live-coded instruments. Should have a toggle for switching between continuous frequencies and a mode that discretises into the 12 notes of well-tempered tuning. And while you move the right hand on the frequency-volume domain, the left hand can do key-presses: one key functions as a sustain pedal, another represents whether to produce sounds at all (pressing and holding that key is like pressing and holding a note on a piano).
3. A language for writing down instructions for triggering the digital instuments. Basically, what happens if you take the good parts of Lilypond notation and free it from the complexities of score engraving. You end up with a language for structuring events in a flow of time. The language would “compile” into a stream of MIDI or OSC signals. And, the theremin-like UI has a recording function that saves live input in the form of that written language.
4. Also, for something completely different: cellular automata (think game of life), but with a notion of continuous force fields. Cells can emit a force field, and the values of the field instantaneously propagates between cell updates, with a configurable decay based on distance to the emitter(s). Imagine a tree-drawing automaton where each cell of tree trunk acts as an emitter on the force field of treeness, and when picking a direction for growth, cells of low treeness are more likely to be picked.
5. And how do I turn the oscillations of a cellular automaton into music?

ALSO: I have taken some work-in-progress drafts of other ideas of mine and moved them from obscure branches into a work-in-progress directory here at the deployment of worm-blossom.org. There is an incomplete but already informative spec draft of the media file formats I wrote about some weeks ago. There is a sketch of a bit-level variable length integer encoding for usage in the media formats. And there’s a draft of the website for Macromania. Without styling, and without most of the content, but the getting-started guide and the introduction-to-macros writeup are functional. You could start using Macromania today!

Oops, I suppose I did end up writing a full editorial.

~Aljoscha

I’ve had repetition on my mind this week, most explicitly triggered by Lu Wilson’s writing on the subject, but also earlier through some reflection on the music I’ve been making. My commentary for last week’s background music track was simply I feel like I'm repeating myself too much with these =/. By now, I’m much more willing to embrace the repetition.

Later, I went to a free improvisation concert played by Fred Frith and Liz Albee, and the weakest passages by far were those where they did not feel comfortable to simply repeat themselves.

And later still, a book I’m reading had the following A. N. Whitehead quote:

[..] no rhythm can be a mere pattern; for the rhythmic quality depends equally upon the differences involved in each exhibition of the pattern. [..] A mere recurrence kills rhythm as surely as does a mere confusion of differences.

I don’t think this makes a lot of sense, at least not when applied to music. No sound happens in isolation, everything is shaped by the sounds that came before. Even when repeating a pattern verbatim, the effect on the listener does not repeat: the first time you hear it, it is new. The second time you hear it, the impression drastically changes, because it is not new. The third time, it is a repetition of something that was already familiar. And so on.

Each repetition has a different quality, because it was preceded by a different context. The quality of change arguably decreases (the difference between the first and the second repetition is more pronounced than that between the 50st and the 51st repetition), but it keeps changing. After 400 repetitions you get a completely different effect than after 32 repetitions. Just like you cannot step into the same river twice, you cannot truly repeat the same pattern.

Oh, wait, this is supposed to be a dev diary, right?

Our Bab implementation now has a well-documented public API, and Sammy has started coding against it! I will spend the upcoming week writing more thorough tests, and next Friday I think we will release it properly. Writing tests is well and good, but I need to accept that I’ll release buggy libraries anyway. So might as well put a disclaimer on the release and ask for bug reports.

~Aljoscha

Early this week I made a few wireframes for a kind of generic Willow management UI (with Penpot, which is nice).

Discord’s ‘server’ UIs have always mapped very cleanly to Willow’s namespaces, and it seems negligent not to appropriate their work. But as soon as you start wading into the more unfamiliar concepts like keypair and capabilities the difficulty begins to reveal itself.

One of the most beautiful ideas about systems like Willow is using a single namespace as a bucket for all kinds of data. What if your Discord server also stored a wiki, a webpage, or anything else its users wanted to put into it? What if you could easily inline your wiki pages into your chats, and weave your data together? And had decentralised permissions which could stay on top of this menagerie of data?

Do you interface with that data in a single mega interface, or many seperate ones? If the latter, does each interface manage its own personas and passes (keypairs and capabilities)? In that case, do you reveal those nitty gritty details like being granted access to /chat/general or something aware of its context, like “General discussion”?

We've bonked our heads against this many times over the years. We tried a reusable React component that you could drop into your (presumably React-powered) app. We tried a kind of web-based mini-OS with different interfaces running inside a managed UI frame. And now I am just starting to think that the solution is a set of agreed conventions, spanning from representation to UI. I uttered the cursed phrase “cultural API” earlier, but I suspect this might just be a rubbish way to say pattern language.

Next week I’ll make an appearance at XPUB (a two-year master in experimental publishing in Rotterdam) to talk about p2p, Willow, and how we communicate our work. I’m really looking forward to this, and I’m challenging myself to find different ways to tell a story about peer-to-peer and Willow. For this one, it’s going to be a timeline, thirty years of lessons learnt the hard way. I feel like it would be irresponsible to only conclude we need to march on with grim hypervigilance. Surely we’re guarding something precious with that vigilance? It’s not just our safety, but something precious, joyful, and unrealised?

~sammy

Let’s start with nuts and bolts dev diary stuff: I started working on a new persistent store for Willow. It’s a straightforward port of the previous persistent store, which used sled under the hood. Except things were just different enough that I could justify switching to Fjall instead. Translating from sled’s APIs to fjall’s was pretty straightforward! This store is missing a few pieces still, as the Store trait needs to be updated with a few methods for storing and retrieving payloads, which depends on the Bab work Aljoscha has been feverishly boshing away at. So: we’re getting there!

While that bubbles away, what else to do but learn about Tauri, and seeing what I can glue together with our Willow Rust APIs? I got about as far as creating one button before my head filled with question about how we’re going to present all of this to human beings. Like the keypairs which are used to sign entries, for instance. they’re just not anything like user accounts on something like Discord, or even Mastodon.

Since the earthstar days, we’ve referred to the set of features keypairs confer as an ‘identity’. But to me, identity smacks of some kind of vague proving humanity rubbish. But that’s kind of exactly the opposite of what we want Willow’s keypairs to do:

• they can be used to prove authorship
• but you can have a lot of them
• and they have as much or as little identifying information attached to them as you want.

So how about ‘persona’? Data can be verified to be written by a persona, you can have as few or as many as you like, and you can attach as much ‘identity’ information (e.g. display name, avatar) you want… or not. Miaourt suggested using little masks as the iconography for this, which I really love.

I'm not the only working on Willow GUIs right now, so expect more of this!

~sammy

So much has happened this week! This calls for bullet points!

• Good progress on the Bab implementation: we have well-documented public API for (persistent) single-slice-per-string storage with support for partial verification. Still requires better tests, but then it can be released. Before that, I’m creating a Bab-aware trait for Willow stores in the willow25 crate though, to unblock Sammy’s implementations of a persistent store and the Willow Drop Format.
• I attended a DWeb preparation event on Saturday. Was nice to run into many familiar faces, and to get to know some new ones. Went home with renewed motivation to get Willow out into the world.
• I met with Zelf to record an episode of her podcast. It will probably be a while until editing is finished and this episode is released, though.
• On Tuesday, a bunch of us p2p nerds ended up in a bar with Olivia Jack of Hydra fame. Hydra is a super cool environment for creating 2d graphics — basically a synthesizer for graphics. I may have spent too much time playing around with it afterwards. It is so easy to get something fun going. I also may have started reading the source code and begun sketching a WebGPU-based implementation. The chances for that ever getting anywhere near useable are close to zero, but at least I had a very fun day of rest.
• I have strong opinions on variable-length integer encodings. So I was happy when I read Brooklyn Zelenka’s new bijou64 spec, which is an interesting variation on my older VARU64 specification. Slightly more complicated, but also slightly more efficient, and arguably easier to detect non-nanonic encodings. An interesting read for the other three people who care about varints.
• This week I finished a super secret side-project that I will reveal... later :>

~Aljoscha

When last week's update went up, I was at the Internet Archive Europe HQ in Amsterdam ('HQ' makes it sound like a big shiny building. It's really a cute little house by a canal). Remember last week when I said I felt like a frog finding their special frog habitat? Well this was more frogs. Many people who I'd been looking forward to meeting, and (somewhat amazingly to me) a fair number who'd heard of Willow before. After a lot of conversation, a sensible amount of cheese, and maybe a little bit of schmoozing, I left feeling energised. For years I've been trying to find a local network of people interested in this niche field, and either I was too much of a shut-in (likely), or this community in the Netherlands has finally reached a kind of critical mass and level of interconnectedness with the broader network.

Meanwhile, I worked on willow_rs. Unfortunately (and kind of intriguingly) my work finally presented a dead end in how well Rust is able to accommodate Willow's generic and parametrised ambitions. Aljoscha has (hopefully) done a write up on this below (don't leave me hanging aljoscha). I've started working on an implementation of the Willow Drop Format (WIP pull request here), where I am practicing liberal use of the todo! macro to implement as much as possible without letting little things like not having that dependency yet weigh me down. This is like taking a breadth-first approach where instead I've always taken a depth-first approach to missing bits and pieces.

~sammy

What is going on in Blossoquest? Since when did it even have that name? Why are we suddenly in a Western? Does the crack in the wall have any meaning? How can Sammy claim dislike for Homestuck and unfamiliarity with Hussy’s work, and yet the third panel looks like Problem Sleuth and the name like a play on Bard Quest? What is going on?!

Anyway, apparently I am supposed to write about the limitations of the Rust type system instead of investigating these mysteries. So here we go!

The Willow specs are highly generic. So naturally, our Rust implementation is full of generics as well. Because this is rather cumbersome, we are also providing a non-generic implementation of Willow’25 for application developers who shouldn’t need to care about the flexibility offered by the parameterisability of Willow.

In our previous codebase, the willow25 implementation merely provided type aliases, with the consequence that compiler messages bombard developers with all those hidden generics. So in the reboot of the codebase, we went for proper wrapper types. We even have a wrapper! macro that automatically generates the structs that wrap the underlying generic types. So far, so good.

The first problem that stems from this arrangement is that of converting between references. Suppose our generic implementation has a function that requires a &Entry<Lots, Of, Generics>. To implement the willow25 version of that function by calling the original function, we need to convert &Willow25Entry into a &Entry<Lots, Of, Generics>. Reference-to-reference conversions are not exactly the most idiomatic Rust. But this was doable, with the `wrapper!` macro even completely hiding the required unsafe and #[repr(transparent)] shenanigans that make it work. And up until Sammy’s recent implementation work, this was good enough.

The real trouble started however once we needed willow25 wrappers for generic types made up from other generic types. For example, a generic AuthorisedEntry struct consists of a generic Entry struct and a generic AuthorisationToken struct. A Willow25 wrapper around AuthorisedEntry would internally still use generic components. But for some code, we would need it to consist of (or at least to be interpreted as consisting of) a non-generic Willow25Entry and a non-generic Willow25AuthorisationToken. But for this interpret-the-generic-components-as-being-non-generic-wrapper-types business, the generics must be instantiated with types that satisfy certain constraints regarding their memory layouts. The exact details are gnarly and do not really matter, the important part is that we ended up in a situation where there would be unsafe code galore. This in itself is bad but not a showstopper, but the real problem was that the safety of this unsafe code would depend on whether you instantiated the generics in a certain way.

The compiler has no way of enforcing any invariants here. And I have never seen any code whose safety depended on properly instantiating type parameters. Calling this situation unidiomatic would not do it justice, I’d rather reach for an unholy abomination whose creators should be barred from writing Rust code ever again.

So what now? We will keep the generic code base for now, but new work will only provide willow25 APIs. Where possible, those will still make use of the underlying generic implementation, but where that does not work we will simply duplicate the generic code and then rip out the type parameters. Long-term, we will probably phase out the generic code base completely, doing concrete willow25-based implementations directly instead.

This is a bit of a shame. The genericity of the specs is a decision I still stand by, and generic implementations do have a certain elegance. But it turns out that (idiomatic) Rust is just not particularly well-suited to it. And we want to keep the codebase accessible and high-quality. The decision to move to non-generic implementations for now stings, but everything else would lead to an idiosyncratic code base that would have made Dominic Tarr proud, and scared off everyone else.

(Also, writing docs for two almost identical versions of our APIs was a pain from the very start, so I cannot truthfully report that I am entirely unhappy.)

~Aljoscha

Recently I’ve felt like a weird little frog who is finally finding their weird little microhabitat. The perfect temperature! Exactly the kind of slime I like! Other weird frogs like me! January put me in the path of lots of people who do and make things I’m excited about, and who seem excited about the work I’m doing too.

The only problem being that I actually have to do that work.

Our immediate goal with Willow is to implement the means to save and retrieve Willow data, and to have at least one way to exchange that data. For the latter, we’re going with the Willow Drop Format, which collects lots of Willow data into a single file that you can deliver with whichever way you like to send files.

Since I started working on private encodings last week, we’ve merged implementations of private path encoding, private area encoding, and private authorisation token encoding to willow_rs’s main branch. I had to get all these past the relentless scrutiny of our fuzz testing apparatus (and Aljoscha), so I’m fairly confident these new implementations are robust and well documented. Which feels great! There is definitely some kind of maladjusted satisfaction I get from merging code, which is something I should probably watch out for.

With that out the way I can get back to the important work of being a weird little frog. This weekend I’ll be heading to the Internet Archive’s new European Headquarters in Amsterdam for a little borrel, where I guess I’ll do borrel-y things like eat little cubes of cheese... and with any luck, meet some more frogs.

~sammy

I finally made good progress on the persistent backend of the Bab implementation. All the logic is in place; the remaining steps are to rearrange the public API, document it, and then to add more thorough tests.

And instead of writing a long editorial, I’ll continue programming now.

~Aljoscha

Shortly after last week’s update my body — sensing uncharacterstic relief — instantly succumbed to a flu that I’m still not completely rid of. So I spent a lot of time in bed reading The Rose Field and quietly feeling pleased with myself about my FOSDEM talk doing the rounds. Again, thank you for watching (and maybe even sharing) it, the response has meant a huge amount to me.

With no more slides to prepare, I returned to programming (shudder). It has been a while, and I feel clumsy and slow, especially in Rust. But I’ve started implementing the prerequisite encodings for Willow’s drop format. These use Willow’s private encodings, where items can only be successfully decoded with a bit of common knowledge. This might sound like overkill for a non-interactive method of exchange like the Drop format, but as Aljoscha reminded me: “turns out trying to omit as much data as possible results in short codes”. And what if that makes all the difference for someone to squeeze as much Willow data possible on their low-capacity USB key? That is what I tell myself as I port existing implementations to another, hopefully final incarnation of an Ufotofu-based encoding abstraction.

I’ve also been thinking about Discord, which will reportedly soon start requiring age verification to access all features. I belong to a few communities based on Discord which will sadly disperse if this ends up happening. And it doesn’t seem like there’s any persuasive answer for where to disperse to. Why is that? Is it because the pieces (protocols, people) aren’t there yet? Or is there a deeper problem in that even if we had all those pieces, fusing them into a monolithic whole requires an amount of coordination (and funding) we collectively can’t muster? I have included some links in this week's update to ponder.

~sammy

This week saw a fruitful discussion about Ufotofu, triggered by Dan’s implementation of chaining combinators. In a nutshell, the problem is that some methods irretrievably swallow up their arguments in case of an error.

There is an obvious fix, which is to have the error case return not only the actual error but also the original arguments. We should be able to apply this for bulk processors, but things are less clear for regular consumers: if consume returned the item it was supposed to consume in case of an error, then that would break the symmetry with the producer design.

For a terrible day-and-a-half or so, I was actually ready to break the symmetry here, in order to make the chaining combinator work without cloning (with a destructive consumer API, the only sensible workaround is to clone items before feeding them into the consumer, so that you still have the clone around after an error). But then I thankfully realised that everything works nicely for types that are Copy. So we can have “normal” APIs that require their items to implement Copy, and then do more expensive and clunky variants that require only Clone.

In any case, the discussion with Dan helped clarify a couple of muddy aspects around ufotofu, and has given me a new perspective on what makes Copy so special in the context of ufotofu items — Copy exempts types from linear typing, thus making them match my purely mathematical mental model of the design space.

~Aljoscha

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