Published on 9/4/2025

Introducing v2 Editor

At Oktana, we are knowledge workers and our main experience is in the software production industry. Reflecting on our everyday practices building software, the current state of knowledge production in other domains and the way the aforementioned practices could benefit them, as well as the potential of knowledge as a commons more generally, we decided that a foundational problem we could work on is writing, and specifically prose in the form of rich text. Writing liberated human communication from the restrictions of time and space and was certainly revolutionary for the thinking process and knowledge production and sharing. Technology associated to writing, like the printing press and paper, released people from the domination of the immediate and the local in even greater scale 1. Although the arrival of digital media and computing has transformed writing, we believe it has fallen short of its potential, articulated by computer pioneers even decades before 2. Compared, for example, with the tools software engineers have at their disposal, contemporary writing tools just feel outdated and inferior. The tools we use shape our thinking and to a big extent define our capabilities and methodologies when attacking problems and we believe that, implemented right, quality writing tools can help us harness the complexity of the activity itself, facilitating the thinking process and allowing us to experiment fearlessly and collaborate effectively. Another reason we decided to attack this problem is that writing is foundational for challenges related to linking knowledge or achieving social collaboration at scale in producing it, which are of great interest to us.

It is always the case that certain foundational technologies and research, along of course with timing, play a role in shaping the terrain and the conditions of action. For us and this project of collaborative rich text writing, it is very important that there is now an exciting movement in software development culture, local-first software, sparked by a foundational technology relevant to collaborative applications, CRDTs. We are very much inspired by the relevant work developed and published by the Ink and Switch industrial research lab and the thoughtful discussions in the Metamuse podcast. We found there this missing element of utopian thinking for computing and digital media, a fertile critique of what computers have become in contrast to their great potential for being tools for thought and co-creation. What’s more, there has been important and concrete research conducted within Ink and Switch for rich text collaborative writing3 4 5, upon which we are building and which we aim to continue and extend. And we are very much aligned to the recurring theme that writing is a socio-technical process6, so alongside the technical challenges we have to talk to people to understand their workflows and also consider politico-economic factors and dynamics.

The product we are launching today in an early Alpha release is a local-first rich text editor with version control capabilities, v2. In the following paragraphs we’ll try to unpack this high-level description and highlight some important principles, design decisions and their consequences.

Rich Text

First of all, v2 is a rich text editor. For most people, rich text evokes the ability to augment plain text with annotations like bold, italics and hyperlinks and some basic block elements like paragraphs and lists. But, especially with the advent of Markdown, the notion of rich text has been expanded to include block-level elements like various levels of headings, images, code blocks, block quotes as well as more inline elements such as inline code spans and footnotes and arguably extending to blocks corresponding to more structured data, like database table views. So it’s more useful to think of the richness of text as a spectrum7, with product and design decisions affecting how each team decides to enable augmenting content in their product. For us, the goal at this stage is to offer some widely used and common rich text capabilities so that we have an editor people can start using and give us directions on what are the next, more specific pieces of functionality important for their use case, and this is why we opted to support the really core and common Markdown features. The flavor of Markdown we want to reach parity with is Pandoc’s Markdown, which is a superset of the most widely used Markdown flavors and which we consider a big step towards building a truly interoperable editor. We will touch on the interoperability value and Pandoc specifically later on; at this point it’s important to make clear that we wanted to leave the design open and ideally make it easy to iteratively push along the rich text spectrum as we make fewer assumptions in this initial stage and then try to better understand what features are important for our users. Also, for us, the importance of rich text lies not in the visual presentation of text (formatting), but in the capability it adds of conveying richer semantics and adding meaningful structure to our documents and eventually the thinking process itself. This means that we are much more aligned to how teams like iA approach rich text rather than Microsoft with Word. We agree with them that we need tools that reverse this trend of focusing on the superficial attributes of the document at the cost of losing the substance of the actual creative process, effective communication and critical thinking 8.

Version Control

The defining feature of v2 and one at the core of its philosophy is version control. As professional software engineers, we can’t even imagine working on a software project without a sophisticated version control system like Git; setting up the Git code repository is often the first thing one does when starting a new project. And a core assumption of this project is that version control systems will be a great tool for most, if not all, knowledge workers.

Firstly, such a tool is indispensable in ensuring that we don’t accidentally lose progress in our work and it makes it easy to roll back to a previous version of the artifact, thus offering a reliable safety net. Also, it provides ease of experimentation and iteration with features like diffing, branching and stashing. Experimentation really requires seamless divergence from a given state of an artifact 9 and evolution requires the ability to converge to an accepted version so that we can incorporate successful experiments. Diff views make it easy to visualize what has changed from a previous or just different version of the project. Branching enables working on more than one idea concurrently and eliminates the need for this dreaded folk practice of maintaining different files for the same artifact in order to experiment without the fear of regression (thus serving as a rudimentary version control system)10. Stashing enables putting work aside to easily switch back to a clean, committed state of the project.

Speaking of committed states, we are touching on an important methodological element version control systems often come with. A version control system tracks a project’s evolution through time. And the basic building blocks for doing so are what we refer to as commits: checkpoints or snapshots of the artifact tagged with a descriptive message and timestamp. There are also tags that denote milestones and pin important versions of the project (e.g. releases in software projects). We mentioned above that tools shape the way we think and approach problems. And products come with principles 11 (which usually express values and methodology favored by their creators) that users can opt out of, but then they are probably fighting against the tool and the tool itself can feel confusing or even badly designed. With version control systems history becomes a first-class citizen in the creative workflow and we believe that commits and tags/milestones bring more structure and order to this history, which is why we borrowed this feature from Git. Although committing or tagging changes may feel weird initially, it cultivates a habit of batching work chunks in a meaningful way and communicating the intent of changes to co-creators. It also helps to form a narrative and contextual understanding about how a project evolved over time and can help newcomers familiarize themselves with it. So another core assumption behind the v2 editor is that, done right, committing brings order and cohesion in how a knowledge artifact evolves and in how people collaborate on it.

Collaboration

The effect collaboration has on production in general and knowledge production specifically requires analysis that goes beyond the scope of this introduction of our new v2 editor. That said, it is important to briefly outline some of its mechanisms and effects in order to understand the relevant possibilities tools like v2 bring.

In his analysis of the productive process in various modes of production, Marx analyzes the revolutionary effects cooperation brings to this process 12. He argues that a productive power with qualitative difference appears when people coordinate in a systematic manner, even just considering that the simultaneous employment of a large number of laborers makes it possible to carry over work in parallel and on an extended space, or perform big chunks of work within a critical time frame (e.g., field harvesting). He talks about social productive power of labor (emphasis is ours) and considers it an important development for humanity as a species. In his age, co-location was a more or less necessary condition for cooperation. Today, information and communication tools extend the sphere of cooperation beyond the confines of the industrial floor or the office space and define instead of following the material conditions of production. We believe that the most important reason why software has been revolutionizing production in the past few decades is the scale of social cooperation software engineers achieved, technically enabled by version control systems (e.g. Git), platforms for social collaboration at scale (e.g. GitHub) and package managers (e.g. npm or pip).

We see then that asynchronous collaboration is a necessary element for this increase in the scale of socialization of the production process. And to get asynchronous collaboration right, one cannot escape solving the version control problem 13. This is where we believe tools like v2 (and, of course, the underlying infrastructural technology like Automerge) can help. This happens because they allow concurrent evolution of the same artifact to happen in a structured manner, recording the authorship and intent of changes and thus offering a much needed transparency, traceability and visualization of changes. Their diffing capabilities allow people to compare different versions of the artifact and thus provide the technical basis for discussing or suggesting changes, even sophisticated review processes at scale. Of course, we also need platforms where people can interact socially for collaboration to happen, but we need the technical basis for it in place first.

Our focus in this initial version was asynchronous collaboration because it can provide the necessary privacy and quiet space for experimenting with an artifact before even considering sharing a first draft with collaborators. It is also the one that has the most potential in extending the scale of social collaboration as it by definition extends in time (does not require but also does not prevent concurrent editing). But we also didn’t want to sacrifice live collaborative editing, even if it’s not our initial focus. This is one of the important technical reasons behind our decision to build v2 on top of Automerge. Automerge is a CRDT implementation and therefore guarantees that, even if users are concurrently editing in real time, it can safely merge the changes without corrupting the document. So building on top of it, we are leaving the design open for building these live collaboration workflows in a future version.

Interoperability

Reflecting on the current state of knowledge production, it’s really the rule that our work is confined within the walls and limitations of specific tools. Naturally, the realm of use of a tool is often tailored to a specific part of the creative process, so we either have to go through a tedious and often lossy operation of converting the artifacts of one tool to formats that another can work with, or, even worse, there is no such capability at all, and we have to work around the limitations of the tool and use it in ways it has not been designed to be used. As Mielke observed, this lack of interoperability between creative tools is clearly antithetical to creativity 14. From a politico-economic perspective, following Marx’s thinking, this situation (along with data silos and paywalls around knowledge) does look like a great contradiction of capitalism: On one hand productivity would radically increase if our tools were interoperable; interoperability is essentially revolutionary from a technical standpoint, and this would benefit social production as a whole, including capitalist businesses. On the other hand, capitalist businesses have to “decree universal mediocrity” 15 and become conservative to protect their interests, being disincentivized to interoperate with others because of competition or the risk of an investment that would not pay off in the short term.

We envision a future where people are not confined to a single tool when creating knowledge. Ideally, users should be able to use different tools in different parts of the creative process, collaborate with co-workers who choose different tools and, as we’ll see in more detail in the section about longevity below, build artifacts that outlast any specific tool or company that maintains it 16. Fortunately, in the domain of rich text and scientific writing, there is one tool that is very mature and can actually provide interoperability between various representations. Pandoc provides a data model that can serve as an intermediate representation which can be used to translate the same rich text concept across different input and output formats. As far as we know, Pandoc is traditionally used via a command line interface to convert from one document format to another, and it is really popular in the scientific community, since it is very powerful with math and citations alongside features you would typically see in a Markdown document. We decided to integrate v2 deeply with Pandoc through a programming interface so that we can leverage its magic via a user interface, and this gives us really advanced capabilities when it comes to imports, exports and in how we can interoperate with other tools like Markdown editors and word processors. v2 can already export to Markdown, HTML, Docx and Pandoc native format in its pre-alpha version because of this integration. Additionally, we implemented a diffing algorithm on top of a data structure that is based on the Pandoc model. Currently, this algorithm is used to display the diff views in v2, but the fact that it’s built with the Pandoc model in mind means that other engineers can leverage it to display sophisticated diffing views in their tools, building on and extending our work. Finally, having a programmatic integration with Pandoc brings us in a very strong position to implement features like citations using much less effort, but also in a way that makes sense for researchers and is interoperable with existing citation technology and compliant with standards.

Local-First

v2 belongs to this exciting software movement born within the Ink and Switch research lab, local-first software 17. Local-first is a set of principles for software that enable both collaboration typical of cloud-based applications like Google Docs and full data ownership for the user, something that has profound implications on the politico-economic aspects of software development.

Data Ownership, Privacy and Political Economy

This inverted model of data ownership is at the core of local-first software, so let us dive a bit deeper at this point. Cloud-based applications like Google Docs and Figma offer the benefit of being able to access and process our creative work from multiple devices and seamlessly collaborate online with colleagues. But this comes at the cost of essentially giving up the ownership of our data, its storage and access control management, to the creators of these apps. Technically, all the data need to go through a server owned by the company that manages the software and stored in its databases. So it’s important to remember that the “cloud” is just a buzzword, we are really talking about someone else’s computer. This way, the power dynamics between the company that owns the software and its users are very asymmetric in favor of the former: The owning company can really prevent you from accessing the data, or (something common lately with the advent of language models) has the freedom to alter the terms of usage and privacy policy to allow it to process it in any ways that generate profit. And this also means an essential resignation from privacy when working on a knowledge artifact, which is presented as a necessary evil of all our online activity but really has to do with these twisted power dynamics, the motive of profit in capitalism and the ubiquity of digital surveillance.

We must challenge this unacceptable situation, being able to work in private and only share our artifacts when we want to do so and understand the implications. And we need the technical foundations to build our alternatives. The way local-first apps technically invert this paradigm is that the data is typically stored primarily on the local storage of the end user device and secondarily (and optionally) in servers, while using technology that allows collaboration and sync without requiring (but also without excluding) a central server. Faithful to this ideal, v2 stores data in the user’s device (currently in the form of files) and is built on top of Automerge, which is the foundational technology for asynchronous or real-time collaboration (along with version control capabilities) and whose promise is to become the new filesystem of computing upon which local-first apps can be built 18. Combined with the potential qualitative increase in the scale of social cooperation that can be achieved with platforms built on top of software like v2 (like GitHub was built on top of Git’s foundation), we truly believe that a challenge to the dominant paradigm of knowledge production is possible.

We acknowledge that achieving such a challenge will require more than just technical advancements and tools; one can deduce this from the fact that software development is technically local-first (since Git stores the data in the developer’s computer) but this hasn’t been enough in challenging the politico-economic status quo: it often feels that big corporations manage to subsume and steer open source software and co-opt it, rather than the opposite. Also, importantly, local-first presents some challenges regarding how software can support creators’ livelihoods and thus be sustainable. To put it simply, we, as v2 creators, cannot hold your data hostage and charge you a subscription. So, in our opinion, it is important this exciting cultural movement in software to become connected with political and cultural ones that challenge the essence of capitalism, the ideology around scarcity and how it affects knowledge production, and eventually develop a critique of work itself with a view to weaving emancipatory alternatives. As discussed in the introductory post of our collective, we favor an approach that combines multiple forms of struggle and aims to connect with other initiatives with similar goals which will also bring skills we are missing. This is a socio-political problem and the struggle around technics and tools is part of it. We must start somewhere, given our conditions, expertise and timing factors. For us, building v2 as local-first software was something that both excites us technically and allows us to lay the technical foundations that allow people to experiment with different models that challenge the status quo in knowledge production.

Longevity of Digital Knowledge Artifacts

Thousands of philosophers, scholars and writers have labored to increase human knowledge and every discovery and technological advancement owes a big part of it to the physical and mental travail of the past and the present 19. And, historically, the medium through which this knowledge has been transmitted, from clay tablets to printed books, has inherently been making it trivial to read the information and obtain the knowledge: one just needs a pair of eyes to read something written on paper. But our generation is creating vast amounts of digital artifacts that, unlike paper, can be rendered unreadable not only socially through enclosures, but also technically through the mere passage of time and evolution of software applications and media formats 20 21. Although software longevity is a subject that cannot be examined in detail within the scope of this essay, we’ll try to briefly touch on some important aspects of it and describe some relevant decisions and strategies in the design of the v2 editor.

As McGranaghan and Wiggins observed 22, software, as a special class of information, is highly dynamic and complex and presents unique challenges in serving its stated purpose in the long term: First, one needs the actual software, either the compiled code or the source code one with the all the dependencies and instructions to compile and run it. Then, the whole runtime around it, broadly defined as the operating system and its APIs, potentially including some interfaces that are only available via some kind of network. So one really needs to preserve or emulate the environment a piece of software can run on to be able to run it after some time has passed. Local-first applications like v2 have an important advantage over cloud-based ones here, as, done right, they carry all their dependencies with them and, implemented right, become resistant to the availability of server-side components and the network, even the continuous support of the team that has developed the software in the first place 23. With the help of emulators that can provide the proper runtime and environment, the user can run the original software itself even if it has become old or is not actively maintained, similarly to how vintage games have been preserved with frameworks like Mame.

But more importantly, the actual data we create via the software is usually more important than the tool we use to create it. It’s the data that holds the content and the ideas that we want to preserve and communicate. And we need access to the data that we want to process with the software, which is not a given with today’s prevalent cloud-based applications, as the data is often stored in a company’s servers, which the software depends on to function properly. Beside the unacceptable risks on privacy and asymmetrical power dynamics mentioned in a previous section, this is also harmful for longevity. Companies do not last forever and their products and policies may change with retroactive effects to data that the user has labored to produce after using the software for a long time. Another angle here is that within a medium that is so dynamic as software, it is important that the user is able to the data to the next generation of software or a different tool. Besides the conscious effort needed to get the data model right and building the software in a way that it can interpret the data in the best way it can, ignoring parts of the data it can’t understand, the most important safeguard here is the adoption of open and interoperable formats and artifacts that are owned by the end user. In today’s mediums, a file in an interoperable format like plain-text, PNG, JPEG, MP3 is the closest we can get to a self-guaranteeing promise for longevity.

File Format

Our vision for v2 includes it being a fully interoperable editor, one that operates on artifacts that can also be opened with other apps and which are owned by the end user. In this initial version, we opted for a custom file extension (.v2) for reasons that have to do with user experience, our product’s maturity and some open questions around how authorization will affect our long-term decision. More concretely, we believe it’s valuable and intuitive for our users to get a file that contains all the text, assets and document history and which is portable and shareable. This means that we can’t simply output the data to something like a Markdown plain text file (which cannot capture document history and also can’t contain any referenced asset files). But it’s also important to consider that in a local-first context it’s not wise to follow traditional authorization strategies where the data is stored unencrypted and you control access to them via a centralized auth server. Authorization needs to travel with the data 24 and this usually means encrypting the data in a way that only authorized actors can access it, which seems to exclude storing the data in a plain text representation like Markdown. We are confident that open formats based on technologies like Automerge and Keyhive will emerge, so that users get files that can be opened by many applications without compromising privacy and security, and we are of course very interested in helping to shape these interoperable representations.

Easy Conversion to Pandoc-Supported Formats

Finally, as mentioned in the interoperability section, v2 is deeply integrated with Pandoc and already supports conversions to various rich text representations, including Markdown and HTML. And, of course, it also supports conversions to the Pandoc native format, which would then make it easy to convert to any format that Pandoc supports as an output. This is a big deal for longevity since it at least guarantees that our users will be able to export all the committed versions of a document in a format that can be leveraged by other tools of their choice, and we think it’s a great foundation for longevity.

A Tool for Thought

Creative thinking and action, knowledge and artistic work, although sometimes perceived as floating apart from time or space, takes place through concrete, material mediums and processes: actual people produce it combining their physical and mental activity with tools that enable, facilitate or impose constraints on it. And these tools have qualities and embody principles that leave their mark on the creative process and the artifacts themselves 25. And today’s computing is all but helping us think and systematically apply knowledge: it favors superficial thinking, even completely resigning from the need to think by having a language model fake it. It constantly tries to steal our attention, distract it from thinking and convert it to a desire to buy, flooding our inboxes with notifications and ads, or even just making us do its chores 26, leaving our mind in a state of exhaustion mixed with compulsion which Fisher calls insomniac overstimulation 27. And it is really no surprise if we consider Marx’s critique of capitalism: machines become an alienating and dominating force to the worker, depriving them of all interest and creative activity, as best manifested in the factory floor 28 but really ubiquitous to all other domains or production, including knowledge and art. In contemporary capitalism, this also extends to leisure activity, which increasingly resembles labor and produces data that big tech capitalizes on.

v2 is the first expression of our desire to reverse this trend, as it culturally belongs to the emerging ecosystem of tools for thought. Such tools aim to enhance and augment the creative process and help us focus without distractions on the thoughts that matter, often just by offering an environment of serenity 29. This is why we consciously avoid cluttering the user interface with ribbons and a million controls that would distract us from focused thinking and writing. And, of course, we will be very careful not to add redundant notifications as we are adding features related to collaboration. Finally, we are statutorily opposed to advertising, so our plan is to resist polluting our products with annoying ads.

A Call for Support

If you happened to experiment with v2 and liked it, or just endorse our vision for it laid out here, there are various ways you could support us. If you are a student, researcher, writer or journalist who feels the tool can be a good fit for your work, please experiment with it and send us some feedback regarding what’s missing or is problematic. We are also especially interested in understanding your workflows as we are planning to build a layer of social collaboration on top of the capabilities v2 brings. If you are a software engineer, v2 is free software and has really interesting technical challenges, which we’ll describe in detail in a follow-up post. We definitely welcome contributions and ideas to make the code more robust, fix bugs and add new functionality.

Finally, let’s not forget that the tools we produce interact with the social forms we live within and express our disposition to reproduce these forms or challenge them. Against arguments claiming the neutrality of technology, different kinds of tools and product decisions will fit a society that maximizes profit generation than one that favors communal sharing and care. We want v2 to be a statement that we can do things differently and build technology that truly benefits and sustains the commons. If you like the vision and our work on it, please consider supporting us financially so that we can do more of this. We statutorily do not accept venture capital investment so that we stay independent and our resources are currently limited and based on personal savings from previous work we’ve undertaken. It would be amazing for us to reach a point where our work is community-funded as we plan to de-commodify knowledge production as much as possible and organize with like-minded people and initiatives.

Footnotes

  1. Lewis Mumford, Technics and Civilization (University of Chicago Press 2010), 136 ↩

  2. Ted Nelson, Computer Lib/Dream Machines, “On Writing”, “Hypertext”, “Everything is Deeply Intertwingled”, “Doug Engelbart and The Augmentation of Intellect”, “Fantics” ↩

  3. Geoffrey Litt, Sarah Lim, Martin Kleppmann, and Peter van Hardenberg. 2022. Peritext: A CRDT for Collaborative Rich Text Editing. Proc. ACM Hum.-Comput. Interact. 6, CSCW2, Article 531 (November 2022), 36 pages. https://doi.org/10.1145/3555644 ↩

  4. Karissa Rae McKelvey, Scott Jenson, Eileen Wagner, Blaine Cook, Martin Kleppmann, March 2023. Upwelling: Combining real-time collaboration with version control for writers. https://www.inkandswitch.com/upwelling/ ↩

  5. Geoffrey Litt, Paul Sonnentag, Max Schöning, Adam Wiggins, Peter van Hardenberg, Orion Henry. Patchwork: Version control for everything. February 2024. https://www.inkandswitch.com/patchwork/notebook/ ↩

  6. Sarah Lim, Marc McGranaghan, Sarah Lim’s interview with Adam Wiggins and Mark McGranaghan, Metamuse Episode 48, Rich text with Slim Lim, 00:14:23, podcast audio, January 20, 2022, https://museapp.com/podcast/48-rich-text/. ↩

  7. Ibid. 00:18:20 ↩

  8. iA, Markdown and the Slow Fade of the Formatting Fetish, https://ia.net/topics/markdown-and-the-slow-fade-of-the-formatting-fetish ↩

  9. Peter van Hardenberg, Local First: The Secret Master Plan, 00:11:21, https://youtu.be/9s8OA08ggbM?si=bYmohSlsj_5gL1Nc&t=681. ↩

  10. Described in the Upwelling essay cited above. ↩

  11. Max Schöning, Adam Wiggins, Mark McGranaghan, Max Schöning’s interview with Adam Wiggins and Mark McGranaghan, Metamuse Episode 8, Principled products with Max Schoening, 00:02:38, podcast audio, July 11, 2020, https://museapp.com/podcast/8-principled-products/ ↩

  12. Karl Marx, Capital, A Critique of Political Economy, Volume 1 (Penguin Books 1976), 439-508 ↩

  13. Peter van Hardenberg, Discussion session on Peritext, a CRDT for rich text (with Martin Kleppmann, Geoffrey Litt and Sarah Lim), 00:30:14, https://youtu.be/07j2AXC9BH8?si=OGho9fcwc_NsoAbL&t=1814. ↩

  14. Molly Mielke, Computers and Creativity, https://www.molly.info/cc#stan (accessed Aug 28 2025) ↩

  15. Karl Marx, Capital, A Critique of Political Economy, Volume 1 (Penguin Books 1976), 928 ↩

  16. Mark McGranaghan, Molly Mielke’s interview with Adam Wiggins and Marc McGranaghan, Metamuse Episode 30, Computers and Creativity, 00:31:28, podcast audio, May 12, 2021, https://museapp.com/podcast/30-computers-and-creativity/. ↩

  17. Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software: you own your data, in spite of the cloud. 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward!), October 2019, pages 154—178. https://doi.org/10.1145/3359591.3359737 ↩

  18. Peter van Hardenberg, Local First Podcast hosted by Johannes Schickling, Special episode: Apps vs Files with Gordon Brander, Peter van Hardenberg & Jess Martin, 00:19:41, podcast audio, December 31, 2024, https://www.localfirst.fm/s1 ↩

  19. Peter Kropotkin, The Conquest of Bread and Other Writings (Cambridge University Press 1995), 15-16 ↩

  20. Steph Ango, File over App, https://stephango.com/file-over-app ↩

  21. Pallab Ghosh, Google’s Vint Cerf warns of , BBC News, https://www.bbc.com/news/science-environment-31450389 ↩

  22. Marc McGranaghan, Adam Wiggins, Metamuse Episode 49, Software longevity, 00:04:20, 00:10:52, 00:13:12, podcast audio, February 03, 2022, https://museapp.com/podcast/49-software-longevity/. ↩

  23. Martin Kleppmann, The past, present, and future of local-first, Local-First Conf, June 18, 2024, https://youtu.be/NMq0vncHJvU?si=lWvkmgFKCG8P5aid&t=438 ↩

  24. Alex Good, John Mumm, Brooklyn Zelenka, Keyhive: Local-First Access Control https://www.inkandswitch.com/keyhive/notebook/#layers ↩

  25. David Graeber, Toward An Anthropological Theory of Value, The False Coin of Our Own Dreams (Palgrave 2001), 54, 83 ↩

  26. Adam Wiggins, Molly Mielke’s interview with Adam Wiggins and Marc McGranaghan, Metamuse Episode 30, Computers and Creativity, 00:25:30, podcast audio, May 12, 2021, https://museapp.com/podcast/30-computers-and-creativity/. ↩

  27. Mark Fisher & Darren Ambrose (Editor), Time-Wars: Towards an Alternative for the Neo-Capitalist Era in K-Punk: The Collected and Unpublished Writings of Mark Fisher (Repeater Books 2018) ↩

  28. Karl Marx, Capital, A Critique of Political Economy, Volume 1 (Penguin Books 1976), 548-49 ↩

  29. We are pretty aligned on the environment creative tools should offer with the vision Adam Wiggins and Mark McGranaghan present in Metamuse Episode 30 cited above, but also pervading their Metamuse podcast more generally. ↩