Teamtype on becoming independent of big corporations and their cloud servers

Continuing our monthly interview series "Building a Free Internet of the Future", we bring you a three-way conversation with the people from the Teamtype project, which received a NGI Zero Core grant. Teamtype enables real-time collaborative editing of local text files. You can use it for pair programming or note taking, for example. In this conversation with zormit and blinry, as these two project members introduced themselves, we talked about technology, engineering, peer-to-peer collaboration, and a desire to empower people to be independent of big corporations and their cloud servers.

“Building a Free Internet of the Future" highlights the experiences and perspectives of individuals and communities supported by the NGI Zero (NGI0) grants. Funded by the European Commission, NGI0 supports free software, open data, open hardware and open standards projects. It provides financial and practical support in a myriad of forms, including mentoring, testing, security testing, accessibility, dissemination and more.

This interview has been edited for clarity and length.

Designing and building a collaboration tool sounds like a real sweet gig. What motivated you to take this path?

zormit: We were motivated by our own needs when working together. One initial memory is when we were organising a conference with a good handful of people and wanted to take notes collaboratively. Our best attempt back then was to use interlinked Hedgedoc documents, but keeping track of all the links seemed like a hassle. Some experiments to "scratch our own itch" followed, and when we later heard about "local-first" as promoted by Ink & Switch we realised that that was one core aspect of what we were missing.

It is indeed really sweet, because we've been using the tool for our own collaboration as early as possible and that includes building it. So-called dogfeeding at its best.

blinry: Also, we were really impressed by how good it felt to pair program on web applications using Glitch (back when that still existed). Allowing that kind of smooth collaboration, but from your own editor, and for a local source code directory, gave us a good vision of what we wanted to build.

You mentioned a few software programs that enable collaborative writing (text, code, notes, documentation, etc.). There are others, such as the CryptPad software suite. So from a tech-savvy engineer point of view, there's a gap to be filled, right?

zormit: CryptPad is an important piece of software and we're using it too, for example, to create spreadsheets together. As far as I understand, it only works in the browser. The gap that we want to fill is to collaborate on plain text files that reside on your computer with the least friction possible.

So far, Teamtype indeed mostly seems to get attention from tech-savvy people, because they might be used to other tools for collaboratively creating software – like Git.

However, we would love to be as user-friendly as possible, so that you could collaborate with a less-techie friend, for example. We want to make Teamtype easy to use, so that you'll be able to use it, as long as you know what a plaintext file is and what a text editor is.

The vision is a minimalistic piece of software that easily fits in the individual workflow of people who think about their computer workflows and who use more tools than a web browser.

blinry: In our documentation, we keep a list of related projects, where we try to document their features, and which text editors they support. We haven't found another tool that quite does what we want.

Three other technical aspects set us apart from existing tools:

First, it's important to us that you can also access and work on the project files even when you're not online. So we built in local-first support, using the Automerge library, which uses data structures called CRDTs (conflict-free replicated data type) to enable that kind of synchronisation with offline support.

Second, we wanted to build Teamtype in a way so that you don't need to trust your data to a central server. Instead, you can use it in a peer-to-peer fashion. For this task, we're using a Rust library called Iroh that makes it easy to establish peer-to-peer connections, even if the devices that should be connected are in different local networks, or behind a router.

And third, Teamtype is editor agnostic. This means that if you're a Neovim user, you can still pair program with someone using VS Code! Several people are already working on more editor plugins, for IntelliJ or Emacs, for example. We tried to make it as simple as possible to write new plugins, by designing a simple protocol that gives editors collaboration capabilities.

CRDT is really a wild thing in today's small world of software. How do you explain it to people who aren't experts?

blinry: For our users, it mostly means that they can make changes to a text file (which, for example, could contain a shopping list) independently, and even while they don't have internet access, and the changes will be integrated with each other the next time they can sync. All participants have their own, full copy of all files and their history – this is where the letter "R" from CRDT comes in: the data structure is replicated among peers. It's very different from the experience of editing web-based notes together, where you usually lose access to the notes without an internet connection.

Users sometimes ask us: "But what happens when two people edit the same line in parallel?" And our response is: The result is as if the insertions and deletions in that line had happened "at the same time": all insertions will now be present, and all deletions will also have been performed. In practice, the result is often very reasonable.

Version control systems like Git often go a different way, and present a "conflict" to the user, which they need to resolve. This often makes sense when asynchronously collaborating on code, where you want the result to be syntactically correct. But when editing shared notes, or actively pair programming, this is less important. The letter "C" from CRDT stands for conflict-free – users will never be prompted to manually resolve something. Instead, the algorithms make sure that the directory content is consistent between all peers. 

zormit: The idea to be able to collaboratively work on things has been around for probably as long as the internet has existed and there have been a lot of approaches and solutions over time. A CRDT is just one approach. The appealing thing about CRDTs is that they work even if you're not connected some of the time, as blinry explained. My personal take is that it's giving some control back to the user to have all data replicated locally. And that's why it's so popular in the times where a lot of companies want to nudge you to use their products and make you dependent on them by vendor lock-in.

As for how they work, one really simple example could be collaborative drawing. Imagine two people (say Carmen and Edith) want to draw pixels on a board. Then each position can only have exactly one color. A CRDT is then a smart way to figure out whose pixel get to show eventually on each of the boards. It merges both user's edits and sorts it out that eventually both users will see the same pixels in the same place. One simple way would be to decide that Carmen always wins, if they're drawing at the exact same time. There's a great interactive article by Jake Lazaroff where I got this idea from.

Note that blinry's example with text is different, because we have a growing space instead of a finite board. If Carmen and Edith both insert some text, in the exact same position and at the exact same time, then we just have to make sure that Carmen’s edits are always going in front, and we have consistency, and both have their text in. That's very much simplified, of course, but the fascinating thing is that distributed algorithms work with a lot of these simple tricks that are elegantly interacting to build something complex.

A great deal of engineering goes into a technology that is then used to write and draw the world as we perceive it. It also influences our perceptions. Does Teamtype's philosophy and technique of “local first” have anything to do with your way of thinking about the world and about relationships with people?

blinry: Pair programming with Teamtype can be a quite intimate experience, and benefits from good communication skills. An analogy we recently drew is cooking together.
You're working in the same place, and on the same medium. You can do different things at the same time, but you still need to coordinate. If one person wants to make soup, and the other one sandwiches, the outcome won't be very good. When we first started programming together that directly, we definitely needed a bit of time to find a good rhythm for it. But I think it's a skill that's worth practising, as it might translate to other areas where you want to attempt close and compassionate collaboration and learn from each other.

The "peer-to-peer" and "local availability of data" aspects doesn't fit so well into our cooking analogy (as long as we don't have food replicators!), but to me, it's about resilience and a desire to empower people to be independent of big corporations and their cloud servers. It's in line with one stance of the "hacker ethic" as popularised by Steven Levy in the 80s: "Mistrust authority – promote decentralisation". 

Why did you choose NGI0 to apply for a grant to work on Teamtype?

zormit: On a basic level, we deliberately want to make open source software, and that's kind of hard to monetise. Funding like NLnet really helps to bring out such ideas that are good for the public.

On a specific level, NGI0 Core's mission of creating an "open, trustworthy and reliable internet" really was fitting to our idea of an editor-agnostic, peer-to-peer, local-first real-time editing experience. It's open in many ways, you can trust it because you can have everything under your own control and check the source code, and we're doing our best to build something that is reliable.

We're not operating deep down in the internet stack, though, and are rather building something on top of it. In the call we applied to, it seemed that NLnet was happy to fund an actual user-facing application, something that they didn't seem to get a lot for NGI0.

blinry: Another strength of NGI0 funding is the offered partner services in their network: the HAN University of Applied Sciences helped us improve the accessibility of our software, Radically Open Security did a security scan, a team from NixOS packaged Teamtype for Nixpkgs, and a member of the Free Software Foundation Europe encouraged us to use REUSE-compliant licensing. Everyone has been really pleasant to work with, and they've added a lot of value to the project!

Finally, I perceive the team at NLnet as very aligned with our hacker mindset and values. We could tell from their writings even before we applied, and it certainly held true afterwards! To me, instead of to trying to receive funding from for-profit companies or venture capitalists, that's a much better fit for us and our project.

Last but not least, do you have a message to pass on to our audience?

blinry: Build more bridges instead of silos! :)

zormit: We're still in a bit of an experimental/prototype phase with Teamtype and there are a lot of concepts to figure out and things to get right, so that users have a good experience using our software. We could need help here in order to find out what works well and what doesn't.

Also we're aiming to create and standardise a way to make editing interoperable through a protocol. If you now feel inspired and desire to contribute to this project, we invite you to get in touch via Mastodon or via the email at the end of our documentation!