Intertwingler

Intertwingler is an application server, which is designed, as its name implies, to help hypertext authors create dense hypermedia experiences.

The central premise of Intertwingler is that the computer is underutilized as an expressive medium. That may seem wild at first to say, but if you look around, you can find copious examples of the computer as a tool for preparing media, or as a vehicle for transporting or rendering media, but the actual content of the media in question would work just as well as if it had been made a hundred years ago:

Texts that would lose nothing if they were printed on paper,
Audio that would lose nothing if it had been recorded to tape,
Photographs and movies that would lose nothing if they had been printed out on film.

In these scenarios, the computer is used as a surrogate or simulator for old media, rather than a medium unto itself. You can almost forget the computer is even there—until something fails, that is—otherwise very little of the audience's experience is occupied by behaviour that only a computer can do. Except for video games—which tend to simulate entire worlds—ultra-niche genres like interactive fiction, and experiments like Black Mirror: Bandersnatch, very little of the computer's expressive idiom surfaces as a first-class citizen in the media landscape.

Two effects in particular are extraordinarily difficult to achieve without the help of a computer:

Interactivity: This is the obvious one, although historically it wasn't: you act on the computer somehow, and reacts accordingly. Or, as we're increasingly finding out, computers do things by themselves, and we do the reacting.
Random access: People tend to foreground the fact that computers are digital, or that they're electronic, but the real salient affordance of the computer is random access: the ability to jump from anywhere directly to anywhere else in an address space with the same amount of—often minuscule—effort. Without random access, computers would be a completely different experience.

Put these two affordances together, and you get something terrifically powerful: the ability to create narratives that branch, expand, and even contract, in ways that respond to each individual's capabilities, interests, and proclivities, and even alter the narrative structure or content on the fly. What I have just given here is a high-level description of hypermedia.

Why I believe these capabilities are important, and why I ultimately made Intertwingler, is because I find that even just staying on top of life entails just too damn much to read. And in business contexts, too damn much to write. One might be inclined to offer AI as a solution, but it's a band-aid, and an unreliable one at that. The problem, as I see it, is that old media is too sparse for modern business—where business here just means you are trying to get the information into your brain for some reason other than fun:

All you need is an update on the situation, but you have to read (watch, listen) through paragraphs of information you already know, to get to the information that you don't.
There's a central message that hinges on one or more esoteric concepts, that, if any adult understood, would understand the whole thing, and would not need to be taught a second time.
There is an argument for a course of action that the wonks and the lawyers are going to want to see the receipts to, but the CEO will not.

The traditional way to handle these situations is to produce multiple versions of the same essential information for different audiences. But the overhead of doing that—and the overhead of managing it—is a problem unto itself. Maintaining message consistency across all the variants, and keeping up to date on the facts, implies a communications strategy at a level of sophistication and resource-intensity that a typical office worker can't reasonably be expected to muster. Especially given that the tools at their disposal are almost never any better than the ordinary ones that we're all familiar with.

I see hypermedia improving business communication and information infrastructure in a number of ways, but I'll highlight the ones that I believe are the most important:

Authors can write for a superposition of audiences: Audiences for instrumental communications fit roughly into an overlapping Venn diagram of people who need to be introduced to the concepts involved, and people who insist that any assertions be rigorously justified. The overlap is whatever information or argument you're actually trying to convey. Now imagine how short that message would be if everybody reading it already understood all the concepts and already bought into all the arguments.
New information is just a delta against already-known information: Journalists are trained to organize news articles so that the current information is at the top, and successive details are farther down the page. As a reader, though, you still have to read the entire article in case they buried the lede. Moreover, the entities news stories are about—people, companies, governments, etc.—persist across time, and assembling the necessary information about them to construct a longitudinal picture is often quite a chore. What I'm suggesting instead is to start with the longitudinal picture as the goal, and then accumulate the changes incrementally.
Dramatically improved information integrity: An important structural property that contributes directly to misinformation and disinformation is when it is easier to copy a piece of information than it is to reference it. This in turn stems from a lack of addressability, and a concomitant lack of mechanisms for transcluding content rather than copying it. The most benign scenario is when a piece of information that was once correct goes stale, and more malign situations involve unsourced rumours that get repeated and propagated through the network. You can't address either of these problems of information freshness or provenance without first solving for durable, fine-grained addressing.
Novel opportunities for sense-making: Analog media is called that because its shape is analogous to the information it contains. There are typically only one or two physical transformations that get the information in and out of the medium. In digital—or should I say computational, random-access—media, stacking successive transformations on top of one another is the name of the game. Different views of the same information, from straightforward moves like graphing a spreadsheet, to elaborate one-off interactive experiences, can help everyday people get their heads around even highly complex dynamical systems.

Isn't Hypermedia Just the Web?

Hypertext predates the Web by several decades. The idea of pulverizing information so it can be accessed from multiple angles dates back to McBee cards and Paul Otlet's Mundaneum over a century ago. Vannevar Bush—Oppenheimer's boss—wrote his famous article As We May Think for The Atlantic in the summer of 1945. (Given his advance knowledge that the war would soon be over, the essay was a meditation on how scientists would occupy themselves during peacetime.) This in turn inspired people like Ted Nelson to coin the term hypertext in 1960, and Douglas Engelbart—who is most widely known for his least interesting invention, the computer mouse—to design a system to do nothing less than augment human intellect. Between The Mother of All Demos (1968) and the World-Wide Web (1989), there are dozens of hypermedia systems, academic and commercial alike. Some of them are even still around.

The Web is a hypermedia system, to be sure, but it's a pretty mediocre one compared even to systems that were already mature when the Web was invented. There are lots of things about the Web, however, that are great about it:

Instantaneous global publication
Durable open standards
About the lowest-barrier-to-entry software platform ever created
Tons of infrastructure for free
URLs are magical and can go anywhere any other text can
Anything can link to anything else, anywhere

What's not so great:

Biased toward bulky, conventional documents
Links are scarce, often relegated to menus
Links only go in one direction
Anemic, ad-hoc data semantics
Surprisingly hard to reuse content/data/information
Transclusion is particularly primitive
404s and other link rot

The Web is like this, I submit, because it began its life as text files in a folder, and without a thorough, comprehensive retrofit, it's in that direction that it reverts. Pages are bulky, links are sparse, and content reuse is weak because the marginal tool for editing Web pages is the same as for plain text files. Same story for data semantics. Link rot happens because it's cheap to rename a file, but expensive to edit every other file in existence that points to the old name—especially if the file is someplace you don't control.

Fortunately, because the Web is such a flexible software platform, these are tractable problems. That doesn't mean it isn't hard work. To get denser hypermedia you need better authoring tools, for which you need better data semantics, for which you need stable URLs—or better yet, that plus a mechanism that remembers what URLs used to be called. All this is where Intertwingler steps in. Its goal is to furnish authors with the Lego-like pieces necessary to make rich, dense hypermedia experiences, without being bogged down by technical bookkeeping.

So What Is Intertwingler, Anyway?

Intertwingler is an engine for creating dense hypermedia experiences. By dense hypermedia, I mean in contrast to sparse hypermedia, which is what the Web provides out of the box. Intertwingler helps you, the hypertext author, by managing an otherwise unmanageably large number of arbitrarily small, reusable, formally typed, structured data objects, connected together by an unbreakable thicket of typed, bidirectional links. It also maps these objects between a set of durable canonical identifiers—designed to last forever—and the friendlier, albeit more mutable kind of typical Web URLs we're all used to seeing.

Technically speaking, Intertwingler's main job is to turn an RDF graph database into Web pages with embedded RDFa metadata, while furnishing the same information as JSON-LD variants for mechanized consumers. Intertwingler also provides a mechanism to POST changes to the graph, plus handle things like backlinks and URL continuity. The net effect is that you, the author, get a complete—albeit naked, Times-New-Roman-and-blue-links-on-a-white-background—website, that you can click around and explore while you work to sculpt it into whatever creation you're trying to make. It was very important to me that Intertwingler produces wholes, that are intact and serviceable in their own right, and that you transform into new wholes, rather than the customary strategy of tacking together broken fragments.

Intertwingler has two modes of operation: static site generator and live application server. The former is handy for immutable, taxidermied presentations, while the latter is necessary for proper interactive applications.

Intermingler

Intertwingler has always been difficult to talk about because it grew organically out of a set of ideas, opinions, and gripes about how to make the Web a better substrate for dense hypermedia, and the fact that you need quite a bit more than just bare pages to make a website. As such, a sizable chunk—arguably most—of Intertwingler's architecture, at the time of this writing, has nothing to do with the functions I just described a couple paragraphs ago. There's a second parallel track of innovation going on that doesn't actually contemplate dense hypermedia at all, and is more about creating durable websites—like websites that could truly work for decades—by embracing a principle of intelligent heterogeneity.

A huge contributor to the ongoing decay of the Web is the replatforming cycle. Organizations tend to redesign every few years, which is attended by, if not driven by changing Web platforms. In the process, a bunch of content gets moved around—or deleted—and this naturally breaks stuff for anybody else linking to it.

Motivations for redesigns, destructive content overhauls, and changing technical platforms are myriad, but what they have in common is some business impetus or other. While this outcome can usually be palliated by some trivial technical interventions and a little elbow grease, breaking some links is going to be pretty low on most executives' list of priorities. Any solution, therefore, has to solve that problem while also being just plain better.

You change platforms to get something new that the previous platform couldn't do for you. But what if you rejected the idea of a platform entirely? That's the idea underpinning a part of Intertwingler which is rapidly coalescing into a separate software product, which I'm tentatively calling Intermingler.

Individual websites age like milk, but the Web itself is legendarily durable. You can load the first website ever from 35 years ago into a browser released today, and it still Just Works™. How it achieves this is through open standard file formats and protocols.

A platform, by contrast, necessarily has an owner. That owner has their own strengths, weaknesses, tendencies, agenda, and life cycle. They also have a stack, each element of which has its own owner, all the way down to—and including—the programming language that everything is necessarily written in. What to observe about this situation is that the interface to the rest of the internet is 100% standard. It's what happens on your side of the fence that puts you in lockstep with vendors, from whose paths you may eventually diverge. So why not bring the standards indoors?

One thing that you notice, after making a few websites, is that there are the parts that implement the content and functionality that is peculiar to that particular website, and then there are the parts that are the same for more than one, or even any website. You can actually go farther than this, and say that there is code in the system responsible for originating content, and code for performing activities other than originating content, such as transforming existing content. If you look at the situation through that lens, these two species of software have the same interfaces but different life cycles, and when you decouple them this way, their respective footprints get dramatically smaller. That is the central innovation of the part of Intertwingler that will eventually become Intermingler.

The goal of Intermingler, then, is to present a uniform address space to the network, while providing the connective tissue on the back end that affords an extremely crisply-defined class of development target called a handler. A handler is just a microservice that responds to at least one URI via at least one request method, and can be written quickly and cheaply in any programming language. The only constraint that makes a handler a handler is that it conforms to the handler manifest protocol—currently under development—which advertises the handler and its capabilities to Intermingler, and provides any other necessary configuration. As such, converting an existing server-side component to a conforming handler should be a relatively straightforward task.

Technically, this makes Intermingler a fancy reverse proxy and microservice bus, and Intertwingler will become just another microservice that plugs into the bus. The vision is to create a space such that a person or organization could maintain any number of websites, that could undergo major technical overhauls—up to and including swapping out Intermingler itself—and the audience would be none the wiser. That's how you create durable Web properties.

Status & Development Plan

Intertwingler is the centerpiece of an emerging suite of software, data specifications, and theory I'm calling The Wholeness Stack. This development is so recent, I haven't even finished the one-pager for it. The code that is now called Intertwingler began life in early 2018 as a bundle of ideas and opinions about how the Web ought to function, and depending on how you count, is the third or fourth incarnation thereof. It's written in Ruby because it relies heavily on RDF, and Ruby is one of the few programming languages other than Java that has an RDF framework with a functioning reasoner. (It was designed to be ported to other languages; Intermingler, which does not need an RDF reasoner, is slated to be written in Rust.) The two tracks I outlined contain architectural elements that can be traced concretely back to work I did in 2008 and 2006 respectively, and more ephemerally even farther back than that.

There are a lot of reasons why Intertwingler has taken so long to come to fruition. One major cause is what I characterize as a high degree of un-handwaveability: it was impossible to fake it till I made it. Unlike the kinds of projects that easily attract interest and funding with little more than a pitch deck, this thing had to exist first, and function—an all-or-nothing proposition—before most people could grasp its value. Another is simply that for many years I had written it off as too ambitious a project. A third reason is that it took until 2023 to finally get significant outside resources to develop it. Last but not least, the whole stack is still in a pre-delegation phase that consists largely of getting enough material out of my own brain and into some kind of artifact that can serve as a nexus of discussion, and my time is unfortunately largely consumed by more pressing demands. Anybody else could have solved the problems Intertwingler solves anytime in the last, say, fifteen years, though, so I'm not too worried about getting scooped.

As of mid-July 2026, Intermingler is still a part of Intertwingler, and Intertwingler is still very much pre-release. The exact design specifications for both have been in flux until very recently, with the first breakthrough that cemented an approach for handler manifest protocol around the cusp of the new year, and an implementation of an all-important caching infrastructure that was only completed and deployed in early July. This completes the design, and determines the minimal footprint for an installation candidate.

Here is a list of what needs to happen to get to a working gem install intertwingler:

Addressable transforms: There is one outstanding component that actually pre-dates the original design—indeed that has been waiting for nearly two decades for the infrastructure needed to do a proper implementation—and that has to do with how to define information resources that are derived programmatically from other resources, in particular by pure functions.
Comprehensive documentation: The API reference situation for Intertwingler is actually not that bad, but the product documentation could use fleshing out: getting started, tutorials, etc.
A proper test suite: Intertwingler has heretofore been really difficult to test because it depends heavily on instance data, and is extremely system-y. A test harness that does a better job than just eyeballing log output has been out of reach until very recently.
Better CLI for initialization/bootstrapping: Intertwingler has a two-stage configuration: a minimal file that tells the executable what essential components and resources to load and where to look for them, and the bulk of the configuration which is live in the RDF graph database. The command-line initialization process only walks you through the first of these; the second still has to be crafted by hand. It would help a great deal if this first-run procedure got users all the way to a serviceable configuration.
Open-source diplomacy: About half a dozen third-party modules need to be upstream-patched, which entails getting the attention of their respective maintainers and doing whatever it takes to get the patches merged. Or, in lieu of that, some other solution. Also, governance needs to be worked out for Intertwingler's underpinning RDF framework, as its principal maintainer has passed on. Thankfully there's a decent community around it, it just needs to be organized.
The actual packaging task: Intertwingler has an unambiguous core, a secondary ring of handlers—some of which are more stand-alone than others—and then a bunch of cruft. Pruning the dead code and then compartmentalizing the rest so you can gem install the whole thing in one shot—or deliberately leave some parts out—is going to take some work.

Some of these are hard requirements for a release, while others merely need a little forward momentum.

At the time of this writing, I'd say it needs probably no more than another hundred hours to get to shipped. Since Intertwingler is ultimately middleware, work on it is a demand-pulled affair. The demand currently pulling on it most is Sense Atlas, which is already using Intertwingler as-is. In other words, another project that uses Intertwingler directly will drag it into a shipped state sooner than later.

If you are interested in monitoring the project's progress, the best way to do that is probably the Method & Structure newsletter, and I'll be announcing the release on my main personal newsletter as well. If you're interested in getting involved, then kindly reach out.