Heads up!
I'm in St. Louis September 21-23 for Strange Loop and a Local-first Unconf. Reach out if you're around!

The Long, Slow Hunch

I have this idea, this nagging, gnawing hunch that's been growing for years. It's a slow hunch. I've seen the hunch play out in different trends and systems and successes over the years. The hunch could be summarized in the phrase: "It's the environment, duh."

When I think about what DXOS is building, sometimes I worry that we're taking on too much. Persistence, replication, synchronization, identity, interoperability, an application environment, all following the local-first principles. It's a lot. There are other companies that are taking on one or two or sometimes three of these things. There are few, if any companies attempting to roll the whole enchilada.

Reshape your notebook, reshape your brain

The past few weeks I've been re-organizing my personal Lab Notebook in order to better orient myself around my goal of Discovering and Disseminating Generalizable Insights to enable computers to help us think better, together.

"Re-organizing my notebook" sounds suspiciously like busy work. Why have I invested 10-20 hours into it over the past few weeks? Simply to make it easy to do the right thing. I believe we have the opportunity to architect our environment such that we can accomplish goals merely by being in sync with our surroundings. Putting my lab notebook into order is putting that principle into practice.

Sometimes an article you read years ago resurfaces and hits like a bolt of lightning. Andy Matuschak's Ratcheting progress in tools for thought was that bolt for me the last few weeks.

If you've followed along with my journey into applied research, you already know that while I've explored different topics related to the future of computing, I've also reflected on how to do that work. What does it "result" look like in future of computing research? Andy's post answers that question with his typical precision:

the goal of future of computing research is to discover and distill generalizable insights.

Andy suggests this approach:

Since joining DXOS, I've been reflecting on the intrinsic architectural characteristics of peer-to-peer, local-first software systems. My brain has lived in client-server mode for a few decades; I've internalized the pleasure and pain of working in that architecture. Peer-to-peer is a different beast. There are no servers. Everything is a peer (albeit with different capabilities). How does that change the developer's experience? Does that make for a better user experience?

My tentative conclusion is that peer-to-peer, local-first apps are simpler to build than client-server apps due to a simpler architecture.

My working mental model is that a well-architected peer-to-peer framework such as DXOS solves the distributed systems problem inherent in client-server apps and bakes the solution into the framework layer. Developers simply build client-side apps and treat state as if it's local. The platform solves for replication and synchronization behind the scenes.

Let's dig a little deeper into the intrinsic shape of client-server versus peer-to-peer apps.

Hail, fellow explorer! Last time I wrote about joining DXOS.

One doc, many apps, many views

I'm intrigued by the idea of sharing a single "document" between applications, where each app can be good at the thing that it's good at. Unfortunately, this is not where we find ourselves today. Software is structured around application silos, each with their own private data. And every app wants to own more and more of your data and your time.

Oh my! I can't believe it's been ten whole months since I've written to you! It's been an interesting season. I could tell you quite the tale of all the things I've worked on, but instead I'll skip over to where we are today and fill in those gaps later.

The tl;dr is I've joined DXOS to help build a developer platform for building local-first, collaborative, interoperable apps.

Software of the future with DXOS

In March, I was introduced to Rich, the DXOS founder, by a mutual friend. As soon as we met, he fired up a demo environment called Kai and within a few minutes I recognized something that has the shape of software that I want to see in the world.

It’s been two months since I wrote to you. And what a two months it has been. This missive will be a sampler platter of updates on the projects I’ve been working on. Bon apetit!

Tools for Thought NYC, Medium Mashup: The Game

In July, I made a trip to NYC for a conference (Funding the Commons, more on that below) and managed to squeeze in an in-person Tools for Thoughts Rocks meetup, as well as some live jazz. I must say, I was more excited about the meetup than the conference, and it did not disappoint. Collaborating with others face-to-face, swapping ideas and book recommendations, getting to know one another, and general banter; utterly delightful. Please enjoy some photos.

NYC and in-person proved the perfect opportunity for one of my favorite activities: an interactive workshop. I’m a big believer in using collaborative exercises to explore ideas together. We are smarter than me, and all that. A question I’ve been pondering for a while is the difference between mediums, notations, and tools. With a captive audience of thoughtful and tools-for-thought-y folks in a room for three hours, it was the perfect time to workshop that question together. With the help of Jared Pereira, Brendan Schlagel, and Matthew Siu, we designed an innovation game called Medium Mashup that can be played in small groups. If you’ve ever played The Thing From The Future it’s like that, but for Thinking Tools.

This last week, I’ve been splitting my time across three major projects and made significant progress on each one. Which felt really good!

mumblr: a decentralized blogging platform

I’m still not quite sure what mumblr is. My initial goal was to learn about decentralized application architecture and get familiar with Fission’s WebNative library. At the same time, I wanted to build something real that I would actually use. It has successfully served both purposes!

On this week’s livestream, I updated the UX of “logging in” to reflect a stronger notion of “connecting to a user-owned resource.” I’m quite happy with how it turned out, including a nascent little “status” indicator. I’m hoping to further improve the UI on it.

Over the last month, I've been working on a decentralized blogging tool called mumblr (remember tumblr?). It uses Fission's WebNative library to store blog posts as markdown files in IPFS. Boy, do I have some thoughts.

But first, why do I call this blogging tool decentralized? It's due to a bizarre shift in architecture; the notion of "application", "my files", and "servers" is completely different than the client-server, centralized world that runs much of the web today.

I've spent a few hours drunkenly stumbling around in Excalidraw trying to capture that new architecture for you, and the results are mixed. Suffice to say everything changes. All of our familiar terms that we've been relying on as stable for the last few decades change.

b

Many of you have joined in the last two weeks. Welcome, and thanks!

Since we may not have been introduced, my name is Jess Martin, and I'm an applied researcher inventing the future of computing. I'm particularly interested in making software a more expressive medium so that humans and computers can think better, together.

This weekly newsletter is structured like a research summary, sharing what I've discovered, learned, and built over the last week.

Yesterday I was musing on automations for note-taking tools and I was struck by the idea that automations in our tools can go too far. It seems there is some amount of desirable friction in working with our tools that changes the tool and our selves for the better.

As sometimes happens, these musings took the form of a poorly-worded tweet that was understandably misunderstood:

https://twitter.com/jessmartin/status/1517233384585674756

Favor automations that encourage time spent in the resulting environment

In the last update, I announced that I was joining the team at Fission as a research engineer. If you visited the Fission home page at the time, you might have had trouble connecting the dots between Fission and the research interests I’ve been exploring in this newsletter. So what does Fission do exactly?

Fission does industrial research

Fission is set up as an industrial research lab, in a similar vein as Ink & Switch. Industrial research stands at the intersection of academic research and industrial application. Academic researchers generally develop techniques and solve problems that are decades ahead of current practice in industry. Furthermore, they are not often interested in or incentivized to bring those ideas to bear in industry. In order for those new techniques to leave the ivory tower, someone has to do the work to translate those ideas into practice, often reworking and adapting them to fit the context of reality. Translation often falls to industrial research, where the work is done by people familiar with both parsing research papers and practical software engineering. If you’re interested in learning more about industrial research, I highly recommend this podcast with Peter VanHardenburg from Ink & Switch.

So, that’s how Fission works. Fission doesn’t sell a product, but rather builds technologies for people who build products. When Fission does build a product, they build primarily to learn whether the technologies are well-adapted solutions to the problem. In other words, they approach the problem like a scientist. As Fred Brooks has said:

Today's update will be a quick one. I'm at the beach with my family, and I'm writing before anyone wakes up. But I wanted to update you on a few fun things from this week.

A New Research Notebook

How Buildings Learn

I've been reading a bunch of books on architecture lately, both out of general interest and necessity as we work on a major remodel of our home, and this weekend I finally dug into How Buildings Learn by Steward Brand. It's definitely the best book on architecture I've read since I dove into A Pattern Language nearly twenty years ago. (On the subject of A Pattern Language, Stewart charmingly refers to Christoper Alexander as "Chris Alexander" and relays "the following mini-lecture [...] pieced together from a conversation we had one afternoon in his backyard.") How Buildings Learn is not your typical architecture book, and that's good thing. As Brand puts it, it's designed to help us "learn how to learn" about buildings, examining the big picture and how the problems and solutions are linked together. It reminds me of Doug Engelbart's Type C activities: "improving our ability to improve."

One might fear that this focus on the meta would leave the book dry and abstract. Far from it. Brand does an excellent job grounding the book in specific examples while drawing out lessons that have broad applicability. His tone is direct and witty, while carrying the weight of wisdom.

A lot of my time the last few months has been focused on getting our homeschool up and running and adjusting to life with a new baby. This translates to a lot of time with one hand scrolling a phone while making dinner or holding the baby. All that to say, I’ve read a lot of Internet in 2022, and there’s some great stuff out there.

Allow me to be your Internet connoisseur, taking you on a tour of the latest-and-greatest digital happenings:

Taylor Hadden presented Tangent Notes at Tools for Thought Rocks in January (recording here). Taylor has built his own note-making tool, from the ground up. In fact, I’m using it to write this update. One of the cool things in Tangent is the concept of a “Tangent Map”, a non-linear browsing history that you can visually curate. It feels like an evolution of browser tabs. If you’re into new UI paradigms, you can jump to this spot in the recording to see a demo of it.

Also on the Tools for Thought Rocks train, the February event (recording here) was jam-packed with goodness. Alexander Obenauer presented on the concepts behind an Itemized Operating System. Geoffrey Litt showed off Twemex and some of the novel Twitter workflows he uses. And Dalton Banks took us on a dizzying tour of control theory.

These days, my mind feels locked in a three-way tug-of-war. Aside from adjusting to life with a newborn (we've got 4 now!), my priorities and thoughts are wrapped around three seemingly-separate projects:

• homeschooling my kids (an 8 year-old, 6 year-old, and 4 year-old)

• making computers better thinking tools

• remodeling our home

While these projects may seem separate, they actually fit neatly into three of my life-long passions: learning, thinking, and building. And furthermore, these are not truly distinct domains, but rather integrated parts of a whole and complete human life.

We are all learning constantly. We take in new information, learn new skills, facts, people, ideas. And learning blurs indistinctly into thinking. We apply our cognitive capacity along with the skills and facts we've learned. And what do we apply our cognitive capacities to do, but to build, to create, to manifest our ideas into the world? Learning, thinking, building are all strands of the braided rope we call life. They can't be removed any more than they can be separated.

Happy New Year!

In June of 2021, I stepped away from full-time employment to focus on research. Over the last six months, I've been scouting the territory, trying to understand what "doing research" means, searching for valuable problems/questions, and getting to know the other folks who are on this journey. While I haven't narrowed down to a single research problem I want to invest the next several years into, I have learned some valuable things that I look forward to pursuing in 2022.

I wanted to share some of my learnings in case they might be helpful to others who want to chart a similar path through this unmarked territory.

First off, a reminder of the focus of my research:

It’s been almost a month since I’ve written an update. Things have been busy! If I don’t write these on Monday morning, they mostly don’t get written.

Here are a few things I’ve been up to.

Building real-time, multi-user apps

I’ve been working with the Croquet team for the past two months. Croquet is a library and platform for building multiplayer web applications with no server. What Firebase did for databases, Croquet does for multiplayer. I believe that in the future, most applications will feature real-time collaboration and Croquet is a great solution to quickly build those applications. For example, here’s a collaborative todo list that I built on Croquet. The app is less than 150 lines of JavaScript (according to cloc) plus a bit of HTML and CSS. Take a look; it’s quite readable.

I have a bunch of half-finished articles I’m working on right now, none of which are ready for publication. Instead, enjoy a few inspirational links I’ve come across in the last two weeks!

Glimpses of the Future

is happening on Friday, October 29th @ 10:30am PT. As always, it should be fun!

My Research Portfolio, Updated

A few weeks ago I wrote about what blockchains are, describing four technological analogies for the blockchain: the blockchain can be thought of as a database, a network, a computer, and a bank. And yet, it's not any one of those things; it's all of them. Now we need to depart from the land of analogies and talk a little bit about what the combination of those four technologies produces.

Why do blockchains matter?

Here's my formula:

Oh my! I've missed sending out my weekly update the last two weeks. And I've genuinely missed it! Writing this update each week has become an important rhythm for making sense of my thoughts, priorities, and a reflection on what I've learned in the last week.

My time, Looted

These past two weeks have been dominated by two things: Croquet and Loot.

As I wrote three weeks ago, I've started working with the Croquet team to help them drive adoption of their innovative collaboration framework. The Croquet library is simple to use and handles a lot of the headache of writing collaborative applications. In a few dozen lines of code, I was able to set up a collaborative web app. Pretty neat! But going beyond a simple app has helped me realize that writing multi-user applications requires different mental models than building single-user applications. My brain has been working hard to process these shifts.

I know I promised part two of Blockchains are a big deal where I describe why they are a big deal. That’s still coming! Instead, today I’m giving a quick update on my contracting work.

Kickin’ tires with Croquet

Blockchains are a big deal

If you’re where I was several months ago, you may have this general sense of “something is happening over there with the blockchain stuff.” You may have even purchased some ETH or BTC at a friend’s recommendation, or read some polemical post on the importance of decentralization. It may all look crazy to you, or maybe you’re starting to get a sense that something important is actually going on.

Today I want to talk about “what’s up with blockchains?” in which I attempt to convince you that blockchains are, in fact, a Big Deal and one that you will be forced to reckon with one way or another within the next decade.

About three months ago, Lambda School asked me to investigate the blockchain space and evaluate launching a course to train existing developers on blockchain technologies. Is there demand? What should we teach? What’s the gap between an experienced web developer and a blockchain developer? The last three months have been a wild ride, exploring a space shrouded in mystery, math, hype, and lots and lots of money.

Today marks the 8th week in a row I’ve written an update. If you haven’t read the past updates, they are available online here.

In my first weekly update, I reflected on these weekly update as a means of “working out loud”:

It's Monday and I'm back at my desk, in my home office, after a bunch of travel. I was on the road for three of the last four weeks, in Texas, then Utah, and finally Kure Beach, NC. That means my computing experience was entirely mediated by one of several small, glowing rectangles: my iPhone XR, an iPad, or my M1 MacBook Air. While there's a glorious freedom to the mobile computing experience, travel always makes me yearn for a rich physical computing environment.

What do I mean by a physical computing environment?

Tools need embodiment

For starters, knowledge workers need more than a single glowing rectangle to do their work. Think about all the tools you use as you work: drawings on a whiteboards, scrawlings in a notebook, sticky notes arranged on a wall, index cards scattered about a table. We embody our thoughts in the physical world and use space to arrange them. Our current computer screens are far too limited a palette, in terms of size alone, not to mention the atrocity of software and input devices!

In the past week, something finally clicked for me: mediums > tools.

About a year ago, I was the recipient of a 2+ hour lecture from Alan Kay on everything from the history of computing to the promise of the computer as a new type of medium. I furiously took notes and over the past year I’ve been traveling down all of the trails that Alan pointed out that day.

One trail was “mediums for thinking.” It’s common these days to refer to various pieces of software as “tools for thought”, after Howard Rheingold’s 1985 book of the same name. While each of these pieces of software is individually a tool, I agree with Alan (he discusses this at length in ) that a is a more useful abstraction than tools. For one thing, a specific medium for thinking may have dozens or hundreds of different specific software applications, which I would refer to as “tools,” that facilitate thinking using that specific medium.

Today I’m going to be facilitating the third Tools for Thought Interchange event. While each of the speakers will have something interesting to show off and talk about, that’s not why I’m most excited.

Thinking is difficult. Thinking well requires discipline, intention, and technique. Just like our physical muscles, our mental muscles have to be built up in the intellectual gym in order to do the work. And also like our physical bodies, our efforts in thinking can be multiplied with tools.

Writing itself is one such tool. “Language is the policeman of thought,” as . Writing helps us clarify our thinking, spot faulty logic, simplify and synthesize different strains of thought. We think better when we write.

I'm setting aside my devices for a full week to enjoy a digital fast / analog feast in the Utah mountains with my extended family. I wrote the following thoughts a few weeks ago as I reflected on the coming of AI-powered programming tools that will change what it means to program. Enjoy!

Humans are tool makers.

Programming is one of the most powerful tools humanity has created, right alongside spoken language and writing, and the destiny of programming mirrors their ubiquity. Like speaking and writing, programming is an expressive medium. Speaking enables you to communicate your ideas. Writing enables you to capture and replicate your ideas. But programming enables you to make your ideas executable. Programming will eventually become a fundamental human capability.

Like reading and writing before it, programming will morph and adapt over the next few hundred years and spread through the human race until it's considered part of "basic literacy." By the time the majority of the human race is "programming literate", it will barely resemble what we think of as programming today. To get a glimpse of how radically it will change, let's consider how writing changed throughout history.

Research as a portfolio

Over the past year, I've been soliciting advice for how to pursue "transformative research." The cornucopia of counsel I've received is worthy of its own essay, but today I wanted to focus on one nugget of wisdom that's been particularly challenging to follow: pursue a portfolio of bets.

Some relevant background about me: I'm a one-thing-at-a-time guy. For me, reading Paul Graham's "The Top Idea in Your Mind" was not a revelation about priority; it was a description of lived experience. In a User's Guide to working with me, I wrote:

I like to focus on one big initiative at a time. When I have to divide my days between two or more large initiatives, I start to feel drained. I can only have one top idea in my mind, and I'd prefer to not have competition for that slot.

Happy 4th of July, observed!

I was talking with a friend recently the challenges of working at the fringes of several established fields. I see computers as a medium for thinking. My goal is to make computers a more expressive medium so my current research interests are all aimed at improving expressiveness. But what do you call that? What "field" is my research in? If I were going to join an academic department, what would the name of that department be? If I were going to write a grant, what category would that grant be under? The best shorthand "name" I have right now is "tools for thought." While evocative, it's too broad and non-specific and it's also seen a lot of hype around it lately.

Here are some of the questions I'm pondering:

• How might we represent knowledge visually? With text? Images? Video? Or would a video game more accurately convey knowledge? This is near the field of HCI. With a little information science and epistemology thrown in.
• How should we represent knowledge within the computer? Currently, a lot of "knowledge" is held in text, or in relational databases. Are there other ways we could better represent it? Graph databases are catching on in the "personal knowledge management" space. What characteristics do they have that lend themselves well to representing knowledge? This sounds like the field of databases.
• What does it even mean for someone to know something? If our goal is to build an expressive tool for representing and transmitting knowledge, we should probably have a good idea of what our goal is. How do we know we've accomplished the goal? Ok, this is definitely epistemology and maybe some ontology as well. Are we doing philosophy now?
• How might humans collaborate to simultaneously interact with some knowledge representation? What should the interface be like? How do we collaborate in real-time, with as little delay as possible? Now we're into distributed systems territory.
• If knowledge is represented in a dynamic way via a simulation, how do we allow people to rapidly construct simulations of what they know? Can effective simulations be built without code? Can we make it easier to write code that represents a simulation? Now we're thinking about programming languages, formal systems, and dynamic simulations.

Happy Monday!

Today marks day one of my return to the land of flexible employment. That's right: as of today, I don't have a full-time job. 😬

For now, I plan to do some contract work, likely part-time, while I figure out how to fund the basic computing research work I'm looking for. This transition has little do with my employer, and far more to do with my career goals: in fact, one my first contract gig will be working with Lambda School to explore an educational program in the blockchain space.

As I've been planning this transition out of my full-time role, one of the things I've had to mourn is the loss of working with a team. When I wrote down my work values over a decade ago, I focused a section on teamwork: