Kabo

DescriptionA spatial way to wander the connections you've built in Are.na — a channel rendered as a 3D graph you move through, growing one click at a time.

RoleDesign Engineer

Timeline2026

LiveKabo

Codearena-vis

Return to homepage

The problem

Are.na is built around connections. You save a block into a channel, connect that channel to another, and repeat — over months, over years — until something accumulates that's less like a folder and more like a way of thinking.

But you can't really see it. The connections are there; they're just invisible. You walk them one page at a time, in a line, like reading a book about a city instead of standing in it.

I wanted to see the shape of the thing.

The one decision

Kabo is a way of seeing, not a way of doing. That single constraint made most of the others obvious.

What it isn't

The easy version of this is an analytics dashboard: block counts, connection depth, most-linked channels. I ruled that out early.

The people who'd want this aren't optimizing anything. They're researchers and collectors who gather slowly, and what they want is a different way to meet what they've already made. Metrics would just be noise.

So: no stats, no import, no export. Every node links back to Are.na — Kabo borrows a view, it doesn't take your data. And the graph accumulates: each click adds to it instead of replacing it. You build context by wandering. That's the whole model.

How it works

Kabo fetches the channel and renders it as a force-directed 3D graph in a dark field. Channels become faintly glowing spheres, image blocks become floating planes with the real image on them, text blocks become small colored cubes. Connections are thin, quiet lines — present, never shouting.

Its blocks appear, tied to what you opened, and the graph grows outward. Click a block instead and you load the channels it belongs to — a photo you saved in one place might also live in three others you've never visited. Those links surface on their own.

Channel spheres wear small brackets — [ ] — a quiet sign that this is something you can open. Selecting one slides out a sidebar: the name, the contents, a preview, a link back to the original, and a trail of where you've been.

Technical decisions

The most important performance call in the whole thing. Moving a node means updating its transform, not making new geometry. It's easy to get wrong when you're working reactively — every state change tempts you to re-render from scratch.

Textures are keyed by block ID in a module-level map. The first visit uploads to the GPU; every visit after returns the cached one. Without it, revisiting any image visibly stutters.

A channel opens up to 20 random blocks and 5 sub-channels; a block opens up to 3 channels. Those aren't API limits — they're product limits. 200 nodes on the first click would break the exact thing the experience is built around.

Are.na's API is rate-limited, so independent fetches go out together and the proxy handles backoff. Expansion stays snappy even when it's pulling from several places at once.

What I'd build next

Right now the graph only lives in your session. A URL that serializes the expanded channel IDs would let you hand someone the shape of a research project — no database needed.

Past ~30 nodes, finding one specific thing gets hard. A light highlight-by-name would help — but it has to stay ambient. A modal search bar would break the spatial feeling, which is the point.

I haven't pushed past 100 nodes. Three.js should hold; the force layout is where I'd expect it to strain. Clustering on zoom-out is probably the answer.

Orbit, zoom, WASD — none of it maps to a phone. A touch version would have to be a genuinely different interface, probably 2D. I'd want to understand the real use case before drawing it.

What I learned

The hardest work here wasn't technical. It was saying no to noise — every default tooltip, every modal, every notification that wanted to exist. A calm space for thinking is something you have to actively defend; you don't get it for free.