A photographer, Rae Romero, came by my studio a few weeks back. My apologies for dithering.
This week I've been working on things that aren't quite ready to be picked apart by the ravenous audience of worm-blossom.org.
The new worm-blossom 'mega bar' is now in operation across the many worm-blossom franchises. We deployed these two weeks ago, but the styling for each site wasn't completely right yet. Now you can skip across the worm-blossom-verse with ease.
I began working on new tutorials for Willow, now that the Store and Willow Drop Format APIs have been published. Writing a tutorial has the unfortunate outcome of making you see the things you've designed from a beginner's viewpoint. New areas for improvement have been identified.
Meanwhile I have been held in the grip of the phrase “nothing special”. When is “nothing special”... well, special? It's when you see how something has been assembled, and that all the parts are in fact quite boring, and that you too could make nothing special yourself if you wanted to.
~sammy
I took all my pondering over the WTP design and cast it into a single specificationcollection of Rust types for the different message types. This is a fairly dense artefact compared to an actual spec writeup, but I hope I can gather some feedback (from Heni in particular :3) nevertheless.
Aside from a continuous stream of Willow test vector improvements, that’s mostly it. I really hope that the WTP design will stay mostly stable; while it is fun to work on these designs it is also somewhat stressful, and I look forward to fleshing things out without reexamining the foundations all the time.
I will be offline for ten days of vacation now (again, what a decadent summer), for yet another choir trip. I prepared background music and an editorial for next week already, but I won’t be as responsive on the Discord server during that time. Sorry @Freckles =D
Not music, but a long-form audio podcast I am re-listening to currently. What starts out as a fairly slow-paced and meandering space-western-fantasy thingy turns into a tight, suspenseful kinda-horror-story (?) with well-executed plot twists and masterful worldbuilding. A bit difficult to describe, but just really, really good entertainment. ~Aljoscha
Reader, it wouldn't be unreasonable to look at last weeks plans of ‘support peers’ and think: that’s just another name for a server. You couldn’t find enough peers, so you had to turn to an always-online machine somewhere. Cop-out.
Well: nuh-uh. In this editorial I will argue that we are doing something meaningfully different from traditional servers.
Servers are (hopefully) characterised by their high uptime, but they are not fungible. If a Mastodon instance’s server is down, we can’t point our mobile client at another server and expect to have the same functionality available to us.
Peers in a p2p network are fungible. We can connect to whatever we can and exchange as much data as possible. But a peer running on a mobile device has only very intermittent uptime. It may only be available when an app is in the foreground, which is not very often at all.
A non-fungible machine with low uptime is just… a crappy server, so that’s not a very interesting combination. But a fungible machine with high-er uptime feels like it’s relatively unexplored.
??? = Support peers. Though I think we can find a better name, something that distinguishes them from intermittently available peers.
What kinds of infrastructure are possible when high-uptime peers are fungible? Sure, you get a ‘swarm’ of high-uptime peers that are more resilient to outages, but… how about something more intentional, like a relay of peers turning on and off as solar power becomes available to them?
Servers are also usually far more capable machines than the devices they serve: more processing power, more storage, more authority. But we’d expressly like to enable peers which can provide high uptime but which have other constraints such as low storage or processing power. If we can prioritise the storage of recent data, operators of constrained devices like this are still able to meaningfully pitch in.
And those high uptime peers can even sync with each other! I think it’s meaningfully different from ordinary servers, and I hope we can use this as a tool to change how we think about supporting infrastructure.
Finally, some graphs to explain how Pillow bridges between p2panda and Willow.
Hacker Post - A (deliberately) whimsical peer-to-peer routing protocol — for postcards. Inspired by Chaos Post, but not localised to individual events. I can report form personal experience how fun delivering Chaos Post is, so I definitely approve. Below the sillyness of it all, there is room for some more serious thoughts, around anonymity, openness, surveillance and abuse. Hacker Post has good reasons for restricting itself to postcards rather than allowing sealed envelopes or USB drives.
A good chunk of my worm-blossom time this week went into the Willow test vector repository. Before this week, that repo held inputs and expected outputs for a few Willow encodings, some of them outdated and thus actively misleading. Now everything is up-to-date again. Additionally, I started adding test data for more than just encodings: there is now also a directory for data-model related functions, such as determining whether an entry should overwrite another, or computing the lexicographic successor of a path (a task less trivial than it initially sounds).
There has been a flurry of other tasks on my mind, to the point where I started to feel a bit overwhelmed. Writing them all down is probably going to help, so here we go:
updating to the new major version of the ed25519 implementation we use in our Rust work,
mildly panicking about quantum computers breaking ed25519 in the not-entirely-unreasonably-far future,
planning Rust traits for Willow stores that allow aggregating metadata (for RBSR) and for splitting 3d-ranges into smaller ranges containing roughly equally many entries (again for RBSR),
more media file format details (in particular, I’m still exploring different mechanisms for enabling efficient seeking in audio/video files),
some macromania macros I should really write sooner rather than later (macros for integrating and possibly transforming assets for websites, macros for referencing these assets),
a data base file format for 3d Willow entry storage,
the prerequisite 3d-zip-tree work I need for that,
providing recommended ways of encrypting Willow data (and metadata) at rest as part of Willow25 (we already have generic designs, but no specific instantiation for Willow25 yet),
API and implementation designs for this encryption work in Rust,
figuring out how to make encrypted sneakerwebsites a thing (in a backwards-compatible way, ideally),
work on my writeup of p2p design principles/lessons,
plans for the first birthday of worm-blossom.org,
idle thoughts around more intentional background music tracks in the next year,
Thank you to Freckles for all their& feedback on the Willow test vectors, and the resulting discussions. Whenever they& found an inconsistency, they& scoured the specifications and our Rust implementation for the cause, uncovering and reporting bugs in both — including a rather serious missing check in our capability verification implementation. It turns out providing test vectors does not only help other implementors debug their code, it also helps debug our own implementation. And it has been pleasant and fun!
Unsurprisingly enough, the reason they& started scrutinising the test vectors is that they& are doing a Willow implementation. It is written in Typescript and currently lives here. Willow in Typescript means Willow in the browser, and that is quite exciting!
Slug has contributed a command to our sneakerweb implementation for locally removing sneakerwebsites without blocking them. I’ve wanted to do exactly that multiple times by now, it’ll be great to have that in there. It was merged into a branch called fix-all-the-things, so it is going to make it into main any minute now I’m sure!
Also I want to point out how all sneakerweb contributors so far consistently have neat personal websites. Not exactly surprising if you think about it for more than two seconds, but still. It’s been neat browsing through this unexpected trickle of free-spirited digital places. Here’s the collection of those who linked to their website in their codeberg profile:
“and this is me starting with something that was *useful*”
Back in March, Aljoscha and myself huddled at a hotel bar with adz, glyph, and sam from p2panda. We’d decided we were going to draft and submit a new grant proposal hours before said grant’s deadline. Collaboration between our projects had always seemed like a bit of a utopian idea, but we finally had convergent goals.
“Project title?” said Aljoscha, hovering his mouse over the empty form input. “Hmmm… put Pillow” said adz. “We can always change it later”.
Pillow is a new collaboration between p2panda and worm-blossom. It’s a way for p2panda apps to quickly store and retrieve data from highly available peers. These highly available peers don’t know anything about p2panda data, but they do have decentralised, capability-powered permissions, can happily evict stale data, and can efficiently sync with each other. That’s because they’re Willow peers!
In this grant we’ll be implementing WTP, meaning that at long last Willow peers will be able to sync over the internet via range-based set reconciliation. We’ll also be developing WTP-powered servers with web interfaces for configuring capabilities, data eviction, and viewing storage usage.
The first users of these Willow ‘support peers’ will be p2panda apps, which will be able to interface with them via Pillow. The idea is that the Willow-powered peers don’t need to do all the stuff a p2panda peer usually does, and will be freed up to act as oblivious (but permissioned) storage.
Not only will we be working with the pandas on this project, but we’ll also be bringing a new member into worm-blossom (more on that later).
In the meantime, I’m getting back on my feet and using those feet to make silly announcement videos.
~sammy
I just came home from a productive walk with some realisations about message encodings for the WTP. These center around statefulness of peers, optimised relative encodings, and request cancellation.
The most basic requests are purely stateless: a peer issues the request, and then simply discards all state that pertains to it. Consequently, the (encoding of the) response must be fully self-contained. First realisation: such responses are indistinguishable from eagerly pushed messages — a peer might as well send such responses without ever having received a corresponding request, and the other peer would be unable to tell. I spent the past two weeks trying to argue against eagerly pushed messages, and now I feel a bit silly.
The other option are stateful requests: a peer issues a request, assigns it a request id, and keeps some state associated with the request. The response contains the request id, and can refer to the state for more efficient encodings. For example, when requesting a Willow entry in a specific namespace, the response encoding can omit that namespace. Second realisation: protocols can easily support both modes of operation. Requests can simply indicate whether responses should be standalone (allowing for stateless requesters) or whether they should be optimised (forcing the requester to keep state).
Moving on to message cancellation: as far I can tell, cancellation (by the requester) serves two important purposes. The obvious one is that it can prevent large responses from being sent only to be discarded upon arrival. The second, less obvious purpose is that cancellation allows the requester to free up any state it had to keep around to be able to decode and process an eventual response. This leads to the rather obvious third realisation: there is no sensible notion of cancellation for stateless requests — if a peer does not even record that it sent a request, it cannot later cancel it. And there is no state for it to free up anyway (though preventing pointless responses would still be desirable, of course).
For stateful requests, there is a more interesting dynamic going on. When using optimised response encodings that rely on state kept by the requester, the requestor cannot immediately clean up its state after sending a cancellation. Concurrently to sending the cancellation, the other peer might have sent a response, after all. And decoding that response requires the old state. Hence, realisation number four: stateful requests imply that cancellations must be confirmed by the other peer before state can be cleared.
This, frankly, is not great. Thankfully, there is a way by which to combine efficient encodings of responses to stateful requests with immediate, non-interactive cancellation: prefixing responses with their length allows the receiver to discard the response from the communication channel and then keep decoding the next messages even after having cleaned up the state that would have been required to properly parse the response. This was realisation number five.
I'm happy with this outcome: letting peers indicate whether their requests are stateful or stateless allows for incremental implementation of a protocol, by starting with the easier-to-implement stateless variants only. And stateful messages with their more efficient responses still do not force requesters to keep around state until their peer cooperates. This is a lot better than what the current Willow Confidential Sync draft offers (mandatory stateful encodings, mandatory cooperative cancellation).
What remains is a final meta realisation: it feels odd that I needed to come up with these approaches myself, after years of being active in the space. We really need better teaching material. I know I'm slightly peculiar in my emphasis on (bounded) state management in communication protocols, and I know that using state for optimising message encodings is a topic that will be skipped by anyone who wants to simply use a serialisation library and not think about encodings at all. But still, everything I've been writing about today is fundamental to how communication works. Guess I need to add yet another article-to-write to my todo list =S
~Aljoscha
It is now a few hours after writing my first editorial, and the consequences of these realisations for the WTP are starting to sink in. The initial WTP draft had both RequestGet messages for requesting individual entries (and the corresponding ResponseGet messages) and RequestPut messages for eagerly pushing an entry to the other peer. Here is the key insight: ResponseGet and RequestPut carry the same information. The only difference is that RequestPut uses an absolute encoding, whereas ResponseGet uses an encoding relative to the corresponding RequestGet message. In a design where the same messages can be encoded either absolutely or relatively, these two message types can merge into a single type.
And this can be an overarching design theme for the WTP. Instead of thinking of messages in terms of requests and responses, as many messages as possible should admit both absolute and relative encodings. Specifically this means:
Asking for an entry (and/or its payload): absolute only.
Sending an entry: absolute, or relative to anything that asks for one or more entries.
Sending a (part of a) payload: absolute, or relative to a message asking for a payload.
Asking for all entries in an area or range (and optionally supplying metadata — fingerprint, entry count, and/or total payload lengths — about one's own entries in that area or range): absolute, or relative to a message asking for a super-area or super-range.
Cancelling a “request”: relative to anything asking for one or more entries.
I want to note that where I write “absolute” encoding, that is only meant in the sense that the encoding is not relative to a dynamically indicated message. To make the encodings as efficient as possible, the spec might still use relative encodings even for standalone messages. To give an example: peers could be mandated to remember the last entry they sent. Each send-entry message could then be encoded relative to the previously-sent entry, allowing, for example, to indicate with a single bit that the current entry has the same namespace id as the previous one. The crucial point is that such encodings require only a constant amount of space, irrespective of the behaviour at runtime, whereas encodings relative to any previous message would require tracking state proportional to the number of previous messages. Another application of this technique will allow transmitting payload slices while keeping the corresponding entry and/or slice start purely implicit.
Aside from a certain elegance, breaking up the request-response dichotomy has a tangible benefit: this design allows peers to express and run both symmetric and asymmetric range-based set reconciliation. The old design was restricted to client-driven asymmetric reconciliation only, exactly because requests for ranges could not be sent in response to other such requests.
This week I have a gazillion things to share; I blame the fact that I took a proper vacation for the first time in ages.
After planning for a long time, we stripped out all generics from our Rust Willow implementation. This makes things, well, less generic, but also provides a tangible and honestly rather necessary reduction in complexity. The pull request ends up reducing our lines-of-code by about 15000. We have published the new code as willow25 0.7.0, and we have deprecated the old, generic willow_data_model and meadowcap crates.
On the WTP side of things, I realised that there is little reason to keep the protocol asymmetric. If both peers are allowed to request entries, that might even be another way of removing RequestPut messages from the protocol. But this decision is sufficiently fundamental that I have postponed working on the WTP until Sammy has enough time on her hands again to have her say as well.
So instead I turned back to my media file format designs. I have now specified exactly how to encode samples. All that is left now are the boring details of format-specific metadata. With the exception of settling on the sample predictor for audio, all the hard work is now done.
And as part of that work, I nerd-sniped myself into thinking about the role of magic numbers in file systems. So I wrote down a half-specification half-rant document that overthinks the topic quite a bit. Turns out I harbour strong feelings about magic numbers (who doesn't, right? Right?), to the point where Emmy and Miaourt had to make me tone down the polemics. Thank you folks =S
Speaking of overthinking things in a good way, I'd like to draw attention to this sneakerweb PR about presenting a sneakerweb collection in a random order. Somehow that premise escalated into a discussion of social dynamics, non-uniform sampling, and time complexity of various algorithm choices. In a good way.
There's been some other progress on the sneakerweb as well, with Emmy spearheading the modestly-named WIP: fix-all-the-things pull request. At the end of that PR will be the release of version 1.2.0, bringing some new features and making the sneakerweb work in Chrome and Edge. Thank you, Emmy (and sorry that I have somewhat dropped out of the loop regarding the state of the sneakerweb implementation)!
Illich at 100 - Some folks are instigating gatherings to celebrate the centennial of Ivan Illich. Illich’s Tools for Conviviality is to me easily among the most important books I ever read. I will sadly be travelling on that weekend, but I strongly encourage you to read Silence is a Commons and, if it resonates with you, seek out (or plan) one of the gatherings.
A while ago, a friend gifted me a book on the condition that all readers should gift it on. These instructions were only verbal, but otherwise that's the idea of the invisible library. The same has certainly been done a bunch of times elsewhere too. At p2pbasel, Trav championed the practice of adding one's name to books one has read, and circulating them.
When I searched the web for Decentralised Library, the AI summary I didn't ask for told me all about how a decentralised library is a p2p system that uses blockchain, smart contracts, and ipfs. That... seems a bit excessive. I tried to figure out how to get away with as little technology as possible, and the end result was the invisible library.
Classic libraries are pull-based. The invisible library is push-based. Is it even accurate to call it a library? Especially considering that the basic operation is gifting rather than lending? Although, in some sense, the book always stays property of the invisible library, which is how libraries work after all. In any case, I quite like the connotations of the name.
At Dweb Camp, somebody told me they basically stopped discovering new music because algorithmic discovery is too repulsive a concept. That is an example of push-instead-of-pull going wrong. But with recommendations by friends, I feel less worried. Perhaps passing on a book from the invisible library should be accompanied by passing on a mixtape? And zines, of course. And a sneakerweb collection.
A pull-based distributed library would easily escalate into a more general resource-sharing framework. The p2panda crew is living proof, having gone from planning festivals to implementing Hoffnung3000, spinning off p2panda, and later coming full circle with Toolkitty.
With the invisible library, I deliberately wanted to keep the scope limited to books. The push-based nature helps with that. So does the gifting-instead-of-lending approach; books are almost uniquely suited to this — an unread book is so much more valuable than a book you already read.
The invisible library works just as well without the final sentence about adding other books by copying the instructions to new books. And I would like to think that it would grow even without that explicit nudge. But still, there is something fascinating about deliberately designing viral systems. Especially to spread practices that inherently challenge neoliberal assumptions.
When I merely lend out a book to a friend, I will eventually get it back and then I can lend it out again. With the invisible library in contrast, I relinquish the opportunity and responsibility for finding a new reader. I trust the receiver that they will do just as good a job finding the next reader as I would.
Unlike a traditional library, the invisible library emphasises adding annotations, drawings, or inserting extra pages. The readers leave something of themselves in the books, the books acquire personality. It is always nice to leave a trace, and it is always good to be reminded that you are not alone in a soulless world.
This week I’ve been with the kids. It’s summer holidays and a lot of their friends are away, so we’ve spent pretty much the whole week together. I didn’t even try to work, it wouldn’t have been any good.
The kids have a vague notion of what I do. It involves computers, they know that much. My older kid knows it involves ‘networks’. Mostly they know that I have a blog with fun music by Aljoscha, and comics which they like (their favourite is this one), and that my work means I bring home lots of stickers.
“I made this for you, mum!”
Several years ago I was a consultant working with commercial clients. After my son was born and started to become a little more conscious of the world, I started to get this sense of “I want my kid to think I’m cool” (I know, I’m doomed to failure, but I’m going to try). And I just couldn’t imagine my kids thinking it was cool that I made React apps for shoe stores (which back then was really pretty lucrative).
This week, I collected all music I remember that I have deliberately listened to multiple times. In the process, I relistened to a bunch of material. And for some reason, this Finnish pop-rock track from 2001 stood out. Sami had shared this years ago on Scuttlebutt (this was the opener of the Consonance 3 (?) mixtape, I think). The good old days of beaker-browser-powered music piracy. And now all these songs are on youtube for free...
After reading this interview with Milo Fitzpatrick of Vega Trails, I turned to the keyboard and recorded a series of somewhat minimalistic improvisations. Here is one of them:
The full set turned out surprisingly coherent, and I’ve added it to the sneakerweb site with my own music. This is a lot less stressful than uploading the whole thing on the www, which honestly sounds a bit scary to do.
In an odd sense, the full improvisations remind me of Bismuth’s The Slow Dying of the Great Barrier Reef (a recommendation from Emmy). But anyway, I should stop writing about music that I didn’t actually upload =S.
“the high-risk high-reward approach to improving the world”
The day before I headed to my vacation, I had an idea for a blog post that I started feverishly drafting. And now that I returned, the first thing I did was to complete it. It starts from a simple idea: what happens if you structure a programming language design around the broadcasting of information rather than calling methods on specific objects? This starting point has some interesting implications, from abandoning the notion of object identity, to spatial computing based on active broadcast rather than passive sensing. Read the full post on Broadcast-Based Programming here =).
I am slowly returning to more practical worm-blossom concerns now, in particular I want to start fleshing out the WTP into a full specification.
The WTP has three types of requests: RequestGet (analogous to HTTP GET), RequestGetMany (for requesting areas or 3d ranges), and RequestPut (analogoues to HTTP PUT). For a while, I was seriously considering to remove RequestPut, turning the WTP into a purely pull-based, read-only protocol. But while this has a certain elegance, it would force application developers to use a separate protocol (such as dripdrop) to write any (new) entries to a peer. In that world, you would either need to multiplex connections or to open multiple physical connections. And that would add complexity that outweighs the minimalism and orthogonality we would have achieved by trimming down the WTP.
With this decision made, here are the next steps toward a completed WTP:
Rework the start-of-connection message flow. The current definitions assume that the very first thing every client has to do is to prove that they have the secret for the public key they will use in their read capabilities. But RequestPut messages do not involve read capabilities at all, and I can easily imagine write-only clients that never work with any read capabilities. And such clients shouldn’t be forced to do useless signature computations, nor should they have to wait for a server challenge before they can start issuing requests.
Remove non-Bab usage. Partial verification is such a good feature that I do not want to encourage implementations that skip it. So no raw indexing into payloads by byte offset without Bab verification metadata.
Define encodings for everything. Surely this will be quick.
Sketch Rust types for all request and response types. Use this to guide the way the spec defines things; currently the spec describes many optional fields together with rules for when they have to be present based on the values of other fields, and this would be much nicer to define in terms of enums.
Pester Sammy to design a logotype.
And with that, we would have a completely specified and half-implemented WTP already. And we are already brainstorming applications we would like to implement that would be enabled by this.
~Aljoscha
Multiple people* have now confronted us about how confusing it is to navigate the family of worm-blossom websites. That there should be some kind of unified navigation between the worm-blossom, Willow, Bab, and sneakerweb sites. And being between projects, that seems like the perfect thing to do.
This is the kind of design work only I am qualified to do at worm-blossom.
We'll see when it gets done. It's summer holidays and I'm with the kids next week. Many things simmering but nothing to report.
After internal discussion, we at worm-blossom concluded that the underlying idea is sound nevertheless. So if anyone has tips for making satay sauce with fruit work, please reach out.
Also, I have no idea why Miaourt requested to pose this vital question in improvised song form, but who am I to deny them.
I am still on vacation. But you know how zoologists determine whether an animal is kept in a way appropriate for its species by observing whether it retreats into passivity or whether it is active, exploratory, and playful? By that same metric, I am having a great vacation.
~Aljoscha
I'm not on vacation. But I'm not really on top of it yet. So this week, part eight of “Why is it called worm-blossom?”.
“I made an app with earthstar! and the thing in the corner is internet time” beams Sammy, a new regular on the Earthstar discord.
Cinnamon eyes the number in the corner of the screen. It is @876, apparently.
The app is cute. It’s a little thing for microblogging in small groups. There are thoughtful touches, like icons generated from public keys to mitigate impersonation. The layout is tasteful. There’s UI for managing your workspaces. But that clock…
“I just wouldn’t want anyone to get confused and think this internet time thing is an Earthstar thing, you know? It's a bit corporate, I don't like the connection with Swatch.”
Sammy hadn’t really thought where this thing had come from. It was just something fun she remembered from her days playing Phantasy Star Online. But Cinnamon thinks about these kinds of things a lot, and Sammy admires that.
Sammy’s next Earthstar app, Twodays Crossing, is a roleplaying chatroom where messages gradually fade away over 48 hours. There are no timestamps on the messages, and the idea of a ‘low res timestamp’ comes up. Sammy asks what it’d be like if each fraction of the day “wouldn’t be a number but a symbol of some kind - a seed, a leaf, a tree, a shell”. Cinnamon seizes upon the idea, and pretty soon there’s a spreadsheet. This new system is built into Twodays Crossing.
At the beginning of 2021, Cinnamon has pulled out the system into its own Seasonal Clock app. There is a kind of golden era for the Earthstar community, people having fun building whimsical things together with an unassuming peer-to-peer core at the heart of it.
But by around the same time next year, things have changed a lot.
“we are firmly on the hedonic treadmill of development”
Readers, this week Aljoscha and I are on holiday. So I've done what I can this week to evoke the feeling of my holiday, a summer break in a family home full of old paintings and photographs of times long past. Aljoscha's buggered off for this week's update, and good for him.
Last week I promised a truckload of impressions from Dweb camp, but to be honest most of those remaining reflections are about presentations I saw and the speakers I met, and I would like to share accompanying recordings of them, and I'm waiting for those to become available.
Instead I've been enjoying the intellectual slack you get from being on holiday. First there is just collapse, catching of breath, recuperation. But then after a few days you pick up the thread again, start laying out little patterns on the floor, experimenting with interesting knots. And before you know it, you're 'just doing a little bit of research'.
The next phase of Willow will be about exploring what sits just above the extreme latency of the Willow Drop Format and sneakerweb. So: networked communication. My plan is to use the sneakerweb itself to find the limits of comfort, the point where you say "this is fun, but I really don't want to do this with USB keys anymore". I think it will be really nice to use our own tools to do research in this way (I think this is what people call “drinking your own champagne”).
A Trip to 90s Kansai: Exploring the XD FirstClass Network BBS - Misty De Méo explores a fully archived copy of a Japanese BBS from the 90s. There is so much to take in here. For one the spatial, Finder-like interfaces used to navigate the BBS. There are also the infodynamics of the BBS, how you had to dial in to a specific server to get new information. How BBS servers periodically retrieved information from each other. This of course was all replaced by an internet where information is anywhere, always. Is there anything to be gained by choosing where and when you exchange data, other than hardiness?
Reader I am shattered. Knackered. Demolished. But home and with enough experiences for several weeks' worth of worm-blossom updates. So let’s start unloading the truck.
Sneakerweb was very much at the heart of worm-blossom’s presence at DWeb camp this year. We had a table at the ‘demo night market’, in which we had to beckon passers-by with nothing but our charms. The only problem: our neighbour was the inimitable Christine Lemmer-Webber of the Spritely Institute, who not only had prepared an incredible multi-screen, multimedia experience, but also has the overpowering voice of a lady who sells onions at the market. We did our humble best, I developed my patter (“you publish websites to your computer — no web hosts, no domain registrars, no credit cards!”) and spread the good word. And someone even came to our table with a .snk file.
We also held a sneakerweb workshop in which we installed the sneakerweb CLI, claimed some domains, exported some .snk files, and sent our participants off to the four corners of the earth with the seeds of the euro sneakerweb. I had that fantastic moment where you see how other people use something you made unprompted, and you go ohhhhh this is what this thing really is? We are learning a lot about the sneakerweb and folding it back in as quickly as we can. For starters: Aljoscha added a wonderful new getting started section to sneakerweb.org.
During the confererence Aljoscha would often walk by me with a USB key in hand, and say something like “and this one is going to New Zealand”. He was the star of coordinating the physical distribution of our corner of the sneakerweb, so thank you Aljoscha.
It feels like we’ve got a project that has a life of its own.
Our sneakerweb.org did the rounds on Lobsters and Hacker News. The two comments above distill the respective site cultures quite well.
Sneeeeeeeaaaaaaaakerwebbbbbbbb! At the very least, the sneakerwebsites we brought made it to Canada, the US, Argentina, New Zealand, Switzerland, the Netherlands, the UK, Denmark, and Germany.
Also, there have been quite a few contributors over in our repo and issue tracker. We are going to release a new version with a whole bunch of improvements fairly soon I hope. And if anyone out there has expertise in setting up cross-compilation for creating Windows and MacOS builds from a linux machine, please reach out!
DWeb Camp was a lot more than only sneakerweb distribution, of course. Meeting old and new friends, electro-acoustic jam sessions, stumbling into people who know what certificate transparency (my phd topic, I guess) is, interesting presentations and discussions, learning to set up a tent, overcoming crippling social anxiety, all that good stuff.
But, somewhat surprisingly to myself, the biggest effect camp had on me is a renewed sense of how political this space is. Not only the need for decentralised tools over centralised tools, but also the nuances within the decentralised world itself. I am interested in software that minimises hierarchy and power-over, and that is definitely not the case for all decentralised technology. Blockchains tend to reinforce the notion that some participants have more rights and value than others. AI tooling has its own baggage when it comes to autonomy and agency. Even something as innocent as requiring a working internet connection to function forces a dependency on users that could perhaps be avoided.
This has given me quite a bit of energy. Both to work on our projects, and to perhaps attempt to be more vocal about those values that — for me — make the differences between distributed systems, decentralised systems, and truly peer-to-peer systems. The introduction to p2p systems I started drafting a while ago is going to be far from a neutral technical document. But more on that when the time is right...
Finally, I want to thank Christine for her guest comic again, and also Dan and Miaourt for their respectiveeditorials last week. A decade ago, I thought about how cool it was that so many webcomics ran guest updates when the authors took a break. And a decade later, I can finally confirm that being in a position to give the stage to friends is just as cool. Much love!
Some weeks ago, Gergely comissioned an icon set for the Seasonal Clock. With a couple of weeks of delay (due to my primary SSB room shutting down), I am happy to showcase the beautiful restricted-colour-palette icons that the fine folks at Hummingcrow made:
These are 32px icons, there are also 48px versions. You can find all icons in this repository (licensed CC-BY-SA-4.0).
And they started an alternate-reality game based on the sneakerweb. This is so cool! Thank you both for contributing and for immediately bursting open the possibility space of what the sneakerweb can do.
