The 2nd workshop of the Substrates community was held on March 17th, 2026, hosted at the ‹Programming› 2026 Conference at Munich, Germany.
The Call for Contributions solicited papers, demos and other artefacts from the invited participants, which were then circulated for review. The papers and their resviews are collected here.
HyperDoc is a research project about growing a hypermedia sub- strate for knowledge workers that integrates code as a representation of knowledge. This paper explains the motivation for this work, dis- cusses the research and development strategy, and provides a concise description of its current and possible future state.
Lopecode is a document you can double‑click or throw on the web. It’s readable prose and a live programming environment. It resists bit-rot because it's a local‑first, single HTML file that works without network.
It's a tool-for-thought and a distribution format: a reactive runtime that self‑serializes with all dependencies bundled. The core is a tiny UI-less microkernel; features are userspace modules you can inspect, edit, and change live.
It’s made for experimentation: extremely extensible, engineered to be fast (no network round trips), durable (plain‑text, git‑friendly), and immediate — change code and see the system update in place.
To use any authoring system, you need to get familiar with its concepts and available tooling. Especially if we want to create systems that are malleable and adaptable, users need to find out what they can change - and how they can change it. But how do we enable this? Substrates aim to be malleable for everyone, not just system developers; this likely means users should find answers within the user-facing part of the system, rather than requiring a switch to a lower level of abstraction, such as the virtual machine. Additionally, substrates might explore new interaction methods that differ from most established IDEs, making easy explorability and discoverability even more critical.
However, in our software engineering courses, we noticed that students struggle to explore new systems that aim to contain their own documentation. Even if a system has a variety of tools and is self-documenting, it can be challenging for a new user to know what to look for. In this submission, we will report on some approaches we have tried and the struggles we encountered in our courses.
Representing user actions as source code modification is an under-explored approach to state management. In the current naive form the idea is roughly language-agnostic I built a JavaScript live coding environment to play with it.
I'm excited about it for 2 reasons:
There are obvious concerns including ⚠security, scalability, and software updates. Yet if you want to build malleable, bi-directional, home-cooked, end-user-empowering experiences, I propose this is a fruitful starting point. Prior art links are spread through the sections, trying to focus on relevant aspects. The core idea is so simple that I'm sure more people independently discovered it before, but I'm not aware of an agreed-upon term; I hope "Model View Self-Modify" name might stick by comparison to well- understood Model-View-Update architecture?
Pencil-and-paper supports a naïve “notational freedom” where notations can be conjured up on demand. Although programming was born in such a world, it has since been locked in to textual notation. Efforts to support alternative notations have required them to be designed long in advance, or have followed a “Modernist” paradigm demanding investment in a particular drawing, programming, and storage ecosystem. We propose a “Postmodern” alternative: treat SVG diagrams as a substrate for notational freedom. By exploiting the de-facto status of SVG across editors and browsers, we can largely avoid reinventing various wheels and instead focus on the missing piece: the interpretation and macro-expansion of vector graphics as programs. We sketch a “Vector Vision Engine” (VVE) that extracts spatial properties from SVG diagrams, executes embedded code, and understands user-defined ad-hoc notations. Static diagrams, whose processing terminates in arbitrary output, contrast with “self-raising” diagrams which bootstrap themselves into interactive apps. We describe some principles and challenges of such an architecture, and close with some open questions for discussion.
2025’s Substrates Workshop garnered a wide spectrum of approaches to this nascent field of software construction. As the call for this year’s workshop acknowledged, these could be fitted onto one or more dimensions, reflecting different modes of enquiry and the interests of different research communities. Articulating these dimensions and trying to place the work of our contributors along them might help clarify the relationships between the work of different groups and how they can complement each other, and how they could be scheduled as part of the work of a larger research programme.
This short paper makes some highly provisional attempts to identify such axes and place some relevant work on them. It should be considered as a spring-board for discussion and mutual illumination rather than a finished taxonomy.
This post explains why reactivity is a key requirement for openly authored, malleable substrates, and motivates fluid.cell, a reactive library designed to support the needs of these substrates. It preserves the good properties of widely available commodity reactive systems whilst expanding their domain. I explain the core reactive competencies of glitch freedom and early cutoff, and how fluid.cell delivers these competencies whilst supporting reactive graphs with bidirectional arcs, asynchronous propagation of reactive updates and allows the cause of these updates to be tracked to their source, and why these expanded capabilities are vital to support successful substrates. The post includes a interactive visual demo of the reactive library on some simple test fixtures.
The social model of disability holds that disability is produced by environments, not by bodies — that when software fails to accommodate a person’s needs, the environment is disabling them. We argue that the dominant organization of computing produces such interaction mismatches structurally: the commodity form of software requires a standardized consumer, and everyone whose needs diverge from this imagined subject is disabled by the software environment. The substrates research community has identified properties — disclosure, composability, malleability — that would address this, but the commodity form actively selects against these properties because they dissolve the boundaries on which exchange value depends. This raises a question: how can infrastructure organized against the grain of commodity logic be made durable? We find a precedent in accessibility infrastructure — sustained not by patronage but by the organized counterpower of disability rights movements. Through Allio, a system for cross-application augmentation built on accessibility APIs, we illustrate both what this foundation makes possible and where its limits lie. We argue that the accessibility case reframes the substrates programme’s central challenge as political-economic: the question of who sustains substrate infrastructure, and through what social mechanisms, is as important as the question of what properties it should have.
In this position paper, I present work we have conducted around the goals of making software malleable. Malleable software is software that a computer operator can appropriate and adapt to suit their own situated, idiosyncratic needs in ways not explicitly envisioned by the software designer. I describe past work in this space conducted with a variety of collaborators and students, as well as historical influences in this space. I conclude with a hint at a direction we are currently exploring in which computation is embedded in composable substrates rather than articulated through code.