Introducing v2 EditorIntroducing v2 Editor<br>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 writing 3 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 process 6, 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...