kabo

a 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.

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.

A standard Are.na channel page.
a standard Are.na channel.
The same channel and block visualized as connected nodes in Kabo.
the same channel, as a graph you can move through.

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

  1. paste a channel url.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.
  2. click a channel to open it.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.
  3. hover to bring a node forward.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.
the first graph loading — sparse, then settling into place.
The Kabo sidebar open with an image block selected, linking back to Are.na.
select a node and the sidebar opens — always linking back to the original on Are.na.

technical decisions

  1. nodes are built once, never rebuilt.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.
  2. image textures are cached.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.
  3. the graph grows on purpose.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.
  4. fetches run in parallel, retries live on the proxy.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.
forty-odd nodes, still responsive.
a channel expanding after a click.

what i'd build next

  1. a shareable graph.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.
  2. search inside the graph.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.
  3. a real performance ceiling.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.
  4. touch.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.

A well-explored Kabo graph, built up one wander at a time.
a well-explored graph — built one wander at a time.