One map, many lenses. Not a new renderer and not a new app — a front door to a pattern that already generalizes: point a lens at the same graph of nodes and you get a map. Change the lens, get a different map. The three below are all the same move.
Each is already an instance of the same iViews data-source pattern — one normalized node contract, a lens that projects it, a surface that draws it. Pick a lens. These cards point out at each canonical surface; they don't rebuild them.
Places nodes that carry a location onto a tile-less vector base — cooperators, projects and nodes as points on the map. Designed, not built: a thin d3-geo / TopoJSON surface (optional 3D globe), reusing the same node contract, never a forked map product.
system/namespace/blueprints/imap-design-note.iorg · future home
maps.net.labs.ooo (deMap geo index)
Reads the graph by its part-of / type edges — the shape of things, not their place or their tension. The iViews gallery renders it a dozen ways (tree, fractal-zoom, markmap, graph); the ONE-Tree is its fixed, air-gap-marked skeleton.
Scores each node by resistance (0 = rooted consensus … 10 = wilting) and colours it by garden state — the lowest-resistance rooted item is the emerging consensus. Generalized from the Konsens-Garten model to any nested tree of questions and tasks. Live + verified.
file://, no server).
There is one contract underneath all three. An iView is one normalized node list + a lens + a per-surface renderer — the same shape the iViews gallery, the iDay brief band, iTasks and iGroups all inject. A map is just that contract with a spatial, structural or resistance lens chosen. Because the nodes are shared, the maps compose: you pick a lens, then stack overlays on top — exactly the iState / iViews visibility mechanic (paint each node by health, by privacy tier, by whatever layer you switch on).
One data contract, three lenses, N stacked overlays — the map is data, not a bespoke app.
A map = nodes + a lens. The map of maps is not an exception to that rule — it is the rule looking at itself.
Subdomain grammar — to be decided
How should the map faces be addressed? Either
<face>.maps.labs.ooo (so geo.,
mind., consense. hang under one maps root), or
maps.<plane>.labs.ooo (so each plane —
maps.net.labs.ooo already names the deMap geo index — carries
its own maps surface). Left open on purpose: a good
inaugural consenseMap question.