## Assertions
hexagons.world is a global addressing system
it covers the planet in nested hexagons
each deeper level adds one more word
so you can describe both:
broad landscapes
and precise points
example
banksia-coast-swan-gumnut-leaf-flow
feels like somewhere on the southwest coast of Australia
softly local, specific, and human
the words should feel right for the place
flora
fauna
landforms
cultural texture
not random syllables — actual things that live there or feel like there
a global addressing system is just useful
people can talk about the same place
even if they don’t share a language or map platform
it becomes a common layer that other tools can rest on
for Peaceful Foundation
hexagons.world is the shared backdrop
common local mapping system
common vocabulary between projects
way to show progress of campaigns
neutral reference point for “where”
integration
hexagons.world is woven into every Peaceful Foundation project
as a calm pattern in the background
showing place
showing change
statistics
hexagons become more than names
they carry numbers people can rally around
“how much this hurts here”
“what’s improving”
each project can read and write
quietly, in the background
### Geometry
the planet is covered in seamless hexagon layers
each layer subdivides into smaller hexagons within it
why hexagons?
they appear in nature (bees, basalt, bubbles)
they tessellate without gaps
they minimise distortion better than squares on a sphere
compared to squares
hexagons feel less “grid”
and more “landscape”
hierarchy
wide landscapes down to single points:
level 0 (macro) → ~1,000 km
level 1 (landscape) → ~100 km, 1 word
level 2 (region) → ~10 km, 2 words
level 3 (district) → ~1 km, 3 words
level 4 (neighbourhood) → ~100 m, 4 words
level 5 (spot) → ~10 m, 5 words
level 6 (point) → ~1 m, 6 words
we call these hex0 to hex6
shorter sequences
give a broad sense of place
longer sequences
give fine precision
UX
level 0 is rarely shown
it can appear on hover or when zoomed far out
search and suggestions
biased to the user’s current map view
so names feel anchored to where you are, not abstract
### Assigning words
we want names that feel like the place itself
not random words that “sound nice”
but things that match what’s actually there
so someone reading the sequence feels:
“yes, that fits here”
natural-first at broad levels
at level 0 (~1000 km)
use large-scale markers:
flagship animals
biome-wide plants
continental landforms
every region gets an anchor that feels unmistakably local
at level 1 (~100 km)
still mostly natural:
common tree families
regional animals
rivers, ranges, coasts
this is the level where people recognise home terrain:
coastal vs inland
forest vs plain
mountain vs basin
at levels 2–3 (~10 km, ~1 km)
begin blending natural + cultural:
local rivers, parks, ridges
familiar species
recognisable land textures
the vocabulary “zooms in” with the landscape
feels closer to neighbourhood than continent
levels 4–6 (~100 m → ~1 m)
here most places don’t have famous features
so we use calm, human-scale words:
brick, shade, frame, bench, dune, basalt, reef, fern
plus programmatic descriptors for uniform areas:
forest, road, slab, scrub, dune, harbour-edge
we still:
avoid homophones and tongue-twisters
keep it readable to a 12-year-old
keep tone neutral and kind
building the word lists
we need a global directory of real things that live in each place
not vibes
not marketing
but actual flora, fauna, landforms, textures, and features
sources
UNESCO biosphere reserves
WWF ecoregions + biome classifications
GBIF species occurrences
IUCN species ranges
OpenStreetMap natural + land-use data
climate + terrain sets (e.g. Copernicus, SRTM, HydroLAKES)
local open-data where available
process
merge all inputs into consistent JSON
for each hex at each level, list:
candidate flora
candidate fauna
landforms + water features
environmental textures
normalise names into short, simple, translatable words
avoid species names that are:
overly rare
overly technical
stay with recognisable, stable items where possible
deriving local dictionaries
for each continent
build a broad dictionary
for each region
narrow to biome-specific subsets
for each hex
keep a small place-specific list
the result is a “key” per hex:
flora: 3–12 items
fauna: 3–10 items
landforms: 2–8 items
textures: 2–6 items
entropy + uniqueness
combined lists provide millions of possible unique words
more than enough for Earth at all scales
most hexes need only a single word per level
the system has comfortable headroom
for uniqueness
for localisation
for future refinement
and it leaves room for community renaming later
filtering across levels
level 0 (1000 km)
use strongest biome-wide signals:
flagship species
iconic landforms
climate-wide textures (arid, boreal, monsoon)
words should be obvious to anyone familiar with the region:
“yes, that’s our coast / desert / range”
level 1 (100 km)
filter down to regional markers:
river systems, ranges, coasts
common tree families
widely recognisable animals
ensure the word fits:
“this slice of country, not that one”
level 2 (10 km)
narrow again using:
land elevation
vegetation clusters
hydrology (streams, wetlands, lakes)
terrain (basalt, dune, escarpment, valley)
names begin to match what people actually see in daily life
level 3 (1 km)
final natural tuning + light human context:
parks, ovals, ridges, coves
localised species lists
this is the first level that can feel neighbourhood-specific
level 4 (100 m)
most cells have few distinctive features
so names blend:
local texture (scrub, slab, pine, reed)
soft human-scale words (shade, bench, brick)
tight dedupe ensures contrast with neighbours
so adjacent cells feel different enough to orient with
level 5–6 (10 m → 1 m)
programmatic generation:
forest/road/ocean derived from parent tone + masks
benches, trees, hydrants, fixtures at 1 m where data exists
where real objects exist, we use them
where they don’t, we rely on calm fillers:
no moralising
no harsh connotations
just clear, small descriptors
rules for assignment
nature > judgement
prefer calm natural terms when possible
avoid loaded, evaluative words for normal places
one sensory word per hex
avoid hush–calm–quiet stacking
keep sequences varied and memorable
no near-homophones
avoid confusing pairs in spoken form
especially across common languages
translation-safe
simple stems, cross-language stability
avoid idioms that collapse in other languages
contrast with neighbours
deduplicate by population weight + adjacency
denser areas get extra care so names don’t blur together
readable by children
words should be understandable to a typical 12-year-old
portable
must work offline, on-device, deterministically
the same place always gets the same words
special cases
uninhabited or uniform areas
derive deterministic lists:
sea, desert, ice, deep forest, tundra
reduces noise in sparse regions
keeps naming cheap and predictable
urban density
if too many similar cells
blend in more human-scale descriptors:
brick, shade, bell, frame, bench, tile
so you don’t get endless “slab–slab–slab”
expect refinement
community renaming allowed
with reasoning and consensus
early land rush expected
people will perfect names for their place
descending versioning prevents churn later
names settle over time
but can still adapt when the world does
#### Computational assignment of hexagon names
goal
assign good, stable names to every relevant hexagon level
using a repeatable, open process
approx dictionary mix
Flora → 25%
Fauna → 25%
Landforms → 20%
Atmosphere & texture → 15%
Human & built → 10%
Emotional/abstract → 5% (sparingly)
for each broad region (e.g. Australia, Europe, Asia, Africa, Americas)
use locally familiar sets
so words feel native, not imported
deterministic design
words should be:
short, common, translatable
no suffix chains
no near-homophones
emotionally neutral (calm, natural)
recognisable to a 12-year-old
not overused filler words
practically
hex4–hex5–hex6 combinations are unique most of the time
given someone’s current view
and basic location hints
levels 0–3
populated 10 km → inhabited 1 km: ~15–25 million cells
process
combine JSON sources locally:
biome
terrain
species presence
human settlement
use light LLM passes to:
rank descriptors
reject bad fits
progressively dedupe by:
population
contrast with neighbours
regional diversity
CPU work
straightforward joins and scoring
runs fine on batches / spot instances
level 4 (100 m)
within populated 10 km cells only
~35–45% of area actually inhabited
≈ 500–900 million populated 100 m hexes
for each hex
attach sparse “what’s there”:
POIs
admin types
distances to known features
climate hints
most hexes have 0–1 strong items
compute
joins + aggregation + distances
~600–1,200 vCPU-hours (spot, cheap)
primarily CPU-only work
many simple mathematical operations
little generation
level 5 (10 m)
process only inhabited L4 parents (~700 million)
~100 L5 per L4 → ~70 billion potential cells
optimise
use on-device determinism for uniform areas
forest, road, ocean derived from parent tone + local mask
precompute only necessary 10–20%
~7–14 billion L5 cells
context inputs
roads/footpaths
carparks / slab
land-use
green edge
vectors/geometry
parcels/addresses where available
compute + storage
~6k–10k vCPU-hours (spot)
deriving dataset:
≈ 80–140 GB (binary)
(plus more if JSON)
names-only shards:
≈ 60–160 GB
level 6 (1 m)
object-driven, not area-driven
trees, hydrants, benches, fixtures
~100–300 million points globally
cheap to refresh
monthly deltas cost cents
storage
compressed JSON:
few to tens of GB
total (order of magnitude)
L0–L3: ~$50–$150
L4: ~$18–$60
L5: ~$180–$300
L6: ~$6–$48
total one-off build:
~$250–$550 on spot compute
ongoing lean storage:
~$17–$24/month
hexagons.world tiles the whole planet from Level 0 (~1000 km) down to Level 6 (~1 m). In theory that gives us hundreds of trillions of level-6 cells. In practice, we don’t store them.
Many hexagons can be generated on demand from a deterministic recipe: level, coordinates, parent theme, and a fixed set of wordlists. If nobody ever looks at a given metre, it never touches disk.
Storage is only needed when a hex stops being “purely deterministic”. If people debate an indicator, attach metadata, or give a local name that doesn’t come from the recipe, that hex gets a row. Everything else remains virtual.
The result is a very dense conceptual grid, but a very sparse dataset. Levels 0–3 hold most of the stored indicator values and metadata; Levels 4–5 only store a thin scattering of overrides; Level 6 is almost entirely deterministic, with overrides reserved for special or people naming metres.
#### Oceans, deserts and large ranges
scope
large uninhabited areas:
oceans, deep desert, tundra, ice sheets, high mountain belts
places where:
almost no-one lives
almost no-one navigates to metre precision
goal:
stable unique names
without consuming the place-specific vocabulary
needed for areas where people actually live
level 1–2 (biome-fitted)
use broad natural markers that genuinely belong here:
ocean:
currents, swell, shelf, fin, drift, krill
desert:
dune, mirage, wadi, thorn, sand, ridge
ranges:
ridge, spur, snow, granite, scree, pass
unique per band
lightly descriptive
not heavily curated the way inhabited areas are
level 3 (simple natural descriptors)
defined from deterministic lists above if inside size
still loosely tied to the biome:
ocean:
tide, foam, kelp, brine
desert:
silt, grit, dune, shale
range:
crag, ice, frost, stone
calm, monotone, neutral
these act as the last “biome-aware” words
level 4–6 (deterministic filler categories)
deep cells in empty regions use:
large filler dictionaries
separate from:
flora
fauna
human-scale pleasant vocabulary
unpleasant industrial vocabulary
words are:
neutral
calm
stable
not evocative of nature
not moralising
not tied to the place
purely deterministic:
hex-level + coordinates → pseudo-random index → word
unique enough, but repeats allowed in deep emptiness
filler categories
wide global lists (~thousands each)
deterministic but not “meaningful”
1. simple objects
handle
strap
latch
bolt
wrench
2. shapes + forms
pillar
ridge
prism
loop
taper
3. process words (calm, not industrial)
fold
wash
grow
turn
draw
4. tool/fixture fragments (neutral)
lever
panel
socket
clip
wire
5. many, many different words
traits of filler sets
short
translation-safe
neutral to mild in tone
no emotional charge
no connotations of harm or pollution
no nature words
no synonyms of harshness used in unpleasant places
why this approach
we preserve high-quality nature words
for inhabited and visited areas
we avoid burning good vocabulary
on trillions of empty hexes
people still get:
stable, unique-enough sequences
for navigation or referencing
but without cluttering:
cultural words
place-specific ecology words
neighbourhood textures
end result
level 1–2 → biome-aware
level 3 → simple natural texture
level 4–6 → neutral deterministic fillers
empty regions become:
light
stable
predictable
not over-described
and not competing with words meant for human places
#### Unpleasant places
Globally, unpleasant zones are tiny (<0.5% of Earth), but they cluster. In highly industrialised corridors — such as parts of eastern China — 20–40% of 1 km hexes may classify as unpleasant. At the country level this still collapses to ~2–5%, and globally it’s far below 1%.
tone
words are:
monosyllabic where possible
heavy and textural
they describe harshness
without overt moralising.
categories
unpleasant places sit in themes such as:
waste
extraction
sprawl
noise
industry
agri-overreach
disaster-damaged zones
assignment rules
classification leans on:
population + building density
to split pleasant vs unpleasant
road surface coverage
to pick up sprawl along road corridors areas
land-use gradient
residential → procedural
mega-retail / logistics → unpleasant
near sensitive spaces:
homes
schools
clinics
we fade or override harsh terms
so the map can report local hardness
without smearing people’s homes or care spaces.
ocean rubbish patches (special theme)
in ocean garbage-gyre areas,
levels follow a fixed pattern:
level 0 → endangered species (hidden from general UI)
level 1 → sea / ocean / brine / depth
level 2 → gyre / current / shelf / trench
level 3 → swirling / converging / tangled
level 4 → faded / cracked / brittle
level 5 → plastic / oil / silicone / polymer
level 6 → bottle / straw / net / cap / fragment
this produces calm but unsettling phrases, for example:
faded bottle cap
tangled net fragment
examples
example mappings stay simple and direct:
1 km landfill
→ dump
100 m carpark
→ cracked
1 m bitumen hot spot
→ boil
a lone tree at 1 m in an otherwise harsh area
→ shade
pleasant human / procedural
pleasant human-scale built areas (homes, civic, cultural, older cores, workplaces)
use the same gentle inventory as elsewhere:
brick, shade, bell, frame, bench, file
these are:
normal human places,
procedural but not hostile,
and sit on the “pleasant” side of the split.
infrastructural / mechanical (unpleasant)
infrastructural belts and harsh built fabric:
highways
shopping slabs
industrial belts
derelict or extractive zones
draw from a deliberately rougher set:
slab, slick, drum, vat, slag, rot
overall shape
unpleasant naming is:
localised,
used sparingly,
and tuned to report harshness
where it genuinely dominates the physical environment.
the aim is:
to notice and map strain,
without labelling whole neighbourhoods or communities
as unpleasant in themselves.
### Style and design language
the map should feel:
friendly
readable
and quietly close to the real world.
it is not a satellite viewer.
it is not a dense GIS client.
it should feel a little like:
a calm 'video game' map of your area,
one breath of “cartoon”,
but still clearly your streets, trees, and coastline.
base appearance
the base map is built from:
land and water
roads and paths
buildings and parcels where available
vegetation and shade
hexagon boundaries (subtle, optional)
these are drawn as:
flat, clean shapes
with light shading for depth,
not photo textures.
visual priorities:
streets and paths stay clear
text remains legible at all scales
overlays (heat, events, indicators) sit on top without fighting the base.
colour and tone
colour choices are:
soft
stable
and high-contrast enough to be used all day.
land and water:
land is warm-neutral
water is calm and distinct, not neon.
vegetation:
shown as steady greens,
with darker tones for denser cover.
built areas:
low-saturation greys and browns,
so statistics and routes can stand out.
people can choose themes:
high-contrast for work use
soft for evenings
dark-friendly options for night.
the defaults avoid:
aggressive colour schemes
visual noise
and sudden redesigns.
light, depth, and “feel”
to avoid a flat diagram look,
tiles include light depth cues:
subtle building footprints
soft outlines on major roads
light relief shading from terrain (where data allows)
shadows or darker strokes under tree clusters.
this gives:
a hint of three-dimensionality,
without going into full 3D rendering.
the result should feel:
recognisably like your town,
but cleaner and calmer than an aerial photo.
hexagons on the map
hexagon layers are:
drawn lightly above the base map,
never as a heavy grid.
at low zoom:
only coarse hex levels (hex0–hex2) appear,
and only when people ask to see them.
at neighbourhood and street level:
hex3–hex4 can appear as:
soft outlines
or tap/hover targets
showing names and statistics when needed.
at metre-level:
hex5–hex6 are mostly invisible,
except when people are doing precise work.
the visual rule:
place first, hexes second.
people should see their area,
not a board game.
raster tiles instead of constant recompute
most people do not need live-rendered vector tiles.
for base maps, we use:
pre-rendered raster tiles by zoom and region,
derived from a stable vector base.
advantages:
cheap to serve and cache
works well on older phones and e-ink devices
predictable performance in low-bandwidth settings.
when overlays or routes change,
they are drawn on top,
without having to regenerate the base.
multi-scale generalisation
as people zoom out:
small streets are removed
minor features are merged
labels thin out.
as they zoom in:
more detail appears,
but still with clear hierarchy.
this avoids:
the “everything at once” feeling common in GIS,
while keeping each zoom level readable on its own.
statistics and overlays
indicators and other overlays:
colour the hexes,
not the whole world.
design:
fill or outline at hex level
with strength mapped to indicator values.
opacity mapped to certainty
(as in the statistics section).
the base map stays:
consistent and calm underneath,
so people can still orient by real-world cues.
examples:
heat (warm overlays on hexes)
unsafety at night (subtle glows along routes)
trees and shade (green density above base greens).
satellite imagery (optional and slow)
by default:
people do not see satellite imagery.
they can choose a:
“photo” layer for inspection,
which:
loads more slowly,
is pulled only for the area they are viewing,
and is clearly marked as imagery.
this keeps normal use:
lightweight
offline-capable
and not dependent on heavy imagery services.
locality and caching
tiles are:
cached on-device where possible,
so commonly used areas load instantly.
in some environments,
tiles can also be served from:
local nodes
or regional mirrors,
reducing load on central servers.
this is an implementation detail,
not a user-facing feature,
but it keeps the map fast in the places people live.
special environments
low-bandwidth / older devices
use raster tiles with reduced detail,
limited animations,
simplified fonts.
e-ink devices
high-contrast themes only
strong outlines
pure greyscale, no shading that depends on colour.
night
optional dark palette
reduced glare
routes and overlays still clearly separated.
end point
the map looks:
like the place you live,
in a calmer, cleaner form.
it is easy to read,
does not change style unexpectedly,
and can run well on almost any device.
hexagons, statistics, and events layer on top,
without ever overwhelming the feeling of “this is my area on a map”.
### Communities
#### Ownership of word lists and hexagon names
purpose
most names are deterministic and derived from data.
but people on the ground often know places better than any model.
this layer lets communities:
add local detail,
fix mismatches,
and give places the names they actually use.
how local naming works
people can stand inside a hexagon
(open app, GPS lock)
and propose a name for that cell.
name can reflect:
a landmark,
a school,
a creek,
a building,
a patch of bush,
something widely recognised.
potentially an AR mode
point camera,
tag what you see,
propose a simple label.
names stay short, neutral, and translation-safe.
slider for “local vs deterministic”
each proposed name includes a slider:
how much this overrides the deterministic seed.
most cells:
keep deterministic name + small human note.
for culturally strong places:
local name can fully replace deterministic word.
this keeps the map mostly stable,
while letting important places speak for themselves.
land rush (epoch 0)
initial period when:
people can walk around,
claim cells,
suggest names,
and attach brief notes.
goal for people
populate early community names,
especially in inhabited areas.
larger hexes (hex2–hex3) require:
multiple people,
from different nearby points,
to propose or confirm names.
after the initial rush,
epoch closes,
and the naming slows into normal governance.
governance and review
all proposals are tied to a peaceful passport.
light skin in the game,
prevents drive-by vandalism.
reviewers (volunteers) check for:
off-purpose proposals,
duplicated content,
harmful or political language,
place names that break rules.
for larger hexes (hex2, hex1):
require multiple attestations,
ensuring the name fits the region,
and isn’t one person’s personal nickname.
community signals
other people can:
approve (“this fits”),
soft-disagree (“not quite right”),
or propose alternatives.
no ratings,
no leaderboards,
no public fights.
just calm signals to help people see what locals actually use.
preventing abuse
restrictions:
no nasty words
no political slogans,
no personal attacks,
no duplicates that cause confusion.
allow searching the global word list
if someone repeatedly proposes harmful names:
their privilege to propose names is paused.
most cells remain deterministic,
so only places people care about get human naming.
level-based trust
hex5–hex6 (very small)
single local name often enough,
as long as it’s factual:
bench,
birch,
school-gate,
court-entrance.
hex4 (100 m)
require at least one additional confirmation.
place-scale details:
corner store,
footpath bend,
playground.
hex3 (1 km)
require multiple locals
neighbourhood names,
parks,
cultural landmarks.
hex2–hex1
higher bar:
regional rivers,
long-standing areas,
coast segments.
must be stable,
uncontroversial,
and actually used by residents.
integration with deterministic names
deterministic backbone stays intact:
biome words,
flora/fauna,
territorial textures.
local additions layer on top,
replacing or modifying only where people care.
this prevents large-scale drift,
while allowing high-fidelity local detail.
after land rush → epoch 1
once the initial wave settles:
all accepted names freeze into versioned state.
new proposals come more slowly,
only for mismatches or genuine local needs.
versioning ensures:
names are stable over time,
but can still adjust when the world does.
end point
a global naming system that:
remains mostly deterministic,
is open to human correction,
and reflects what people actually call the places they live in.
names become a gentle collaboration:
between data,
landscape,
and the people who walk through it every day.
#### Community organisations and activities
what this is (and isn’t)
peaceful foundation does not run events
we build tools so people can find what’s already happening
local groups, councils, clubs, faith communities, co-ops run the activity
the map just makes it easier to see, join, and keep good things alive
things already happening nearby
local groups
church teas, knitting circles, youth groups
mens sheds, womens groups, language circles
community gardens, repair cafés, walking clubs
councils and services
free buses, community centres, libraries, pools
hall bookings, workshops, info sessions
most people never hear about these
most of them depend on word-of-mouth and paper posters
what the map shows
each hex has:
public events and recurring activities
public facilities from councils
quiet local things that volunteers have surfaced
anyone can:
see what’s on
see access notes (e.g. step-free, kid-friendly, cost if any)
see basic description and timing
signed-in people can:
add to their calendar
RVSP through peaceful passport
seeing details (gated softly)
peaceful passport needed to see:
— exact meeting point
— organiser contact details
— RSVP button
reasons:
— avoid mass scraping and spam
— give organisers a calm sense of how many might show up
— keep some friction between bad actors and vulnerable groups
vouching (organisations)
groups need local vouches to show full details
existing organisations vouch for new ones
quiet, factual: “this group is real and does what it says”
upstart groups:
explain what they’re doing
get at least one local vouch
vouching is:
per-organisation, not per-person
visible as simple counts, not as scores
reviewable if a group drifts from its purpose
history (events, not ratings)
no stars, no “good/bad” scores
event history shows:
— how many times it has run
— roughly how many people have attended before
optional neutral confirmations:
— “this event happened on this date”
names not shown
no comments, no reviews
keeps a factual record without turning it into a popularity game
safety and harm reduction
people are lightly trained (through guides and prompts) to:
notice controlling or outcome-focussed behaviour
leave if something feels wrong
flag concerns quietly to peaceful foundation community and staff
events that start to feel:
overly coercive,
predatory,
secretly recruiting,
heavily ideological,
can be:
reviewed,
de-listed,
or asked to clarify purpose
goal:
make it easy to find calm, low-pressure spaces
reduce room for predatory setups without drama
role of volunteers
volunteers don’t create their own brand of events “for PF”
they:
help offline groups get onto the map
find knitting circles, seniors groups, local clubs
offer to list events and keep info up to date
respect each group’s tone and autonomy
especially useful for:
elder-run activities with no web presence
mailing-list-only communities
“we’ve always done it this way” groups that still welcome newcomers
councils and facilities
map shows:
libraries, pools, community centres, BBQs, shaded parks
free buses and shuttle routes
public toilets, fountains, basic amenities
programmers and volunteers:
scrape council websites
import open data where possible
tag facilities into the right hexes
this lets:
people see what their area already offers
soft pressure build for better services where gaps are obvious
example: perth free beach bus
personal anecdote:
my girlfriend only found out late that Perth had a free beach bus
it ran up and down the coast to different beaches
anyone could hop on, no ticket
hardly anyone knew it existed
no clear map
no simple listing
ridership stayed low
the service was cancelled
why it matters:
the bus wasn’t a bad idea
it just wasn’t visible
hexagons.world exists so things like that:
are easy to find,
get used,
and have a fair chance to survive
overall flow
people open the map and see:
what’s happening in their hex
what facilities their council already provides
if they care, they:
sign in,
see details,
RSVP,
turn up,
and quietly confirm the event happened
organisations:
own their events,
get gentle feedback via attendance,
share hosting load over time
peaceful foundation:
stays in the background,
keeps the map honest,
and helps good local things stay visible
// pulling the data from physically close by
### Technical ethos and architecture
hexagons is the best example of our technical design methodology
it covers the whole Earth, from broad regions down to metre-scale places
but it doesn't need to store the whole Earth as if every metre needs its own permanent record
the whole thing should feel enormous from the outside, but remain pretty simple underneath
the core principle is:
compute what can be computed
store only what must be remembered
fetch only what is needed
cache what people actually use
this keeps the system:
cheap
fast
local
offline-capable
and difficult to centralise too tightly
#### "get the client to do it"
the default instinct should be:
get the client to do it
modern devices are powerful
a phone or laptop can already handle many things
that older systems would have pushed to a server
the client should compute:
hex geometry and hit-testing
applying styling
zoom-level generalisation rules
visibility rules for minor roads, paths, labels, and overlays
basic route rendering
basic routing where the graph for the current region is already on-device
deterministic interpretation of uniform areas like road, forest, ocean, slab, and similar local masks where that data has already been packaged efficiently.
the server should not be asked
to do work the device can do calmly by itself
Only store what cannot be cheaply recomputed.
If data is missing, the system should fall back to deterministic generation rather than fail.
it should still render something usable
not perfect
but coherent
good enough to navigate
a missing layer should not break the map
it should simply reduce confidence
or reduce detail
the map should degrade gracefully
if a feature requires:
constant global syncing
heavy central storage
fragile live coordination
or a server round-trip for ordinary use
it is probably wrong
not always wrong
but suspicious
the question should be:
can this be deterministic?
can this be cached?
can this be local-first?
can this be sharded?
can this be optional?
can this fail without breaking the whole system?
if the answer is no too often
the feature may not belong in the core architecture
we actively should prefer:
small pieces
clear rules
local computation
replaceable layers
slow coordination
and durable defaults
compared with
large services
hidden dependencies
global state
and constant server authority
// download the map like openstreetmaps does
If a feature requires global coordination, heavy storage, or constant syncing, it is probably wrong.
#### Shards and torrenting
the non-technical version is:
people torrent the map between themselves
not necessarily literally one protocol
and not necessarily pure peer-to-peer
but conceptually:
each piece can be
verified
cached
fetched from wherever is fastest
“a graph of small immutable pieces, continuously recomposed and fetched from wherever is fastest”
as a nested addressing system (whereby a larger hexagon has smaller hexagons tiling within it)
lends itself well to sharding
people already understand the geography
because the storage shape roughly follows the place shape
however, the delivery layer does not need to exactly match the public naming layer
the user-facing system should stay simple:
hex names
places
indicators
routes
local records
the distribution layer can be more pragmatic, with:
shards
blocks
manifests
regional bundles
epoch files
content hashes
the public map should feel human
the storage system can be boring and efficient
##### Types of Shards
the world is broken into many small immutable pieces, and each device or node keeps the pieces most relevant to its place, purpose, and recent use.
A shards tag should let you infer enough about it that you can decide whether it is relevant before downloading everything.
So the shard tag should encode or point to:
- where it is
- what scale it is for
- what sort of data it contains
- which version family it belongs to
It means the system should make it easy to know, from a compact descriptor or manifest, roughly what area, scale, and kind of data something pertains to. This aligns with your broader UX principle that names and suggestions should feel anchored to where the user is, not abstract.
###### Snapshots
coarse regional bundles
used to bootstrap devices and peers
they might include:
base map data
coarse geometry
regional wordlists
stable public layers
common routing graphs
low-resolution indicators
these help a device become useful quickly
###### Overrides
small records layered over the deterministic base
hexagons.world defines hex0–hex6 everywhere on Earth: from ~1,000 km down to ~1 m. In theory that’s on the order of 10¹⁵ cells. In practice, almost all of them are deterministic. Themes and wordlists are derived from open data (UNESCO, ecoregions, land-use, climate, species) plus a coordinate-based seed.
A hex only stops being “purely deterministic” when a group of people override something – a local name, a tag, an indicator edit, metadata, or a photo. Even if we gave every inhabited 1 km and 100 m cell special attention, that’s roughly a billion hexes out of hundreds of trillions – about one in a million. Everything else is maths, not storage.
they include:
community names
local metadata
factual traces
facilities
events
organisation records
indicator corrections
accepted edits
these should remain tiny relative to the full grid
###### Epochs
versioned descriptions of the current rules of the world
they describe:
active dictionaries
indicator methods
naming rules
style rules
shard versions
data source versions
model versions
they let peers know:
what they are serving
what version they are using
whether they are out of date
how to reproduce a result
###### Local Bundles
practical packages for a place people actually use
for example:
a campus
a suburb
a town
a city
a region
these are what devices and community nodes
will most naturally keep around
###### Indexes
small searchable layers
they support:
autocomplete
local search
place lookup
facility lookup
hex-name lookup
these should be independently replaceable so search can improve without repackaging the whole map
##### Shard Names and Manifests
a shard should be understandable before someone downloads it
a device should be able to ask:
is this near me?
is this at the scale I need?
does this contain the kind of data I want?
is this the current version?
is this compatible with my local cache?
a shard tag should encode or point clearly to:
where it is
what scale it covers
what kind of data it contains
which epoch it belongs to
which version family it uses
Any single shard or block must be small, simple, and independently usable
fast transfer, easy caching, composability into more relevant sharding
###### Good Enough Before Perfect
We must always render a usable approximation before complete.
a person opening the map should see:
a coarse map first
then local names
then useful roads and paths
then facilities
then photos and richer details
then heavier overlays
emergency or navigation-relevant data should arrive before decorative data
first useful render
then better detail
then richer local context
then historical completeness
(and historical archives can be on demand)
local search should work before historical archives
##### Transport
pure peer-to-peer is elegant in theory but messy in practice
people go offline
home networks are strange
mobile connections vary
NAT traversal is annoying
some regions have weak infrastructure
instead, we should fetch from three sources at once:
local-first
the user’s own cache
nearby peers
LAN devices
community nodes
regional nodes
universities
libraries
councils
community servers
soft infrastructure
fallback CDN / HTTP
ordinary servers
object storage
edge cache
simple reliable downloads
this is more about always fetching from the fastest trustworthy source
not always fetch from the most ideologically "pure" source
local-first is best when it works
regional mirrors are good when they exist
plain HTTP is fine when it is the most reliable option
the architecture should be decentralisable without making normal use fragile
A person’s device stores what it uses.
A local node stores what its community uses a lot.
A regional mirror stores what a broader region depends on.
And the deterministic backbone means nobody has to store everything. That fits your principle that deep hexes are mostly generated, lightly stored, and served through local mirrors or peer-to-peer methods only where needed.
This works because the technical architecture mirrors natural human behaviour and aims to be a map that behaves like a community does
people naturally pin what they use, so:
Perth users naturally cache Perth shards
universities cache their campus + city
NGOs cache regions they care about
Over time:
data becomes geographically local because usage is local
this gives us
near-zero storage explosion
strong locality
offline capability
graceful decentralisation
plus a simple mental model
A university, town, or neighbourhood node can keep the blocks for its own area pinned locally. Then nearby users tend to fetch nearby data from nearby providers. That does not happen because the data is “from their town” in a sentimental sense; it happens because peers in that area are more likely to cache and provide that shard, which improves resilience and often latency too.
#### Storage within communities
how much storage within each community?
how might we store it??
local storage should follow use
people naturally cache what they use
communities pin what they depend on
regional mirrors keep what larger areas need
the system should not try to store the whole world everywhere
instead:
a person’s phone stores:
1–10 GB
a local node stores:
50 GB–1 TB
a regional mirror stores:
1–20 TB
the global sharding system stores:
sparse accepted records
hashes
version history
public datasets
metadata
moderation state
content-addressed shards
##### What Takes Space?
For one local community, a sane storage breakdown might look like this:
| Layer | What it contains | Typical size |
| ----------------------------- | ------------------------------------------------------ | -----------: |
| POI records | name, category, location, opening hours, contact, tags | 10–200 MB |
| Events + recurring activities | community meals, clubs, free buses, workshops | 10–500 MB |
| Local notes / access info | step-free, quiet, kid-friendly, cost, seating | 10–200 MB |
| Menus / service lists | mostly text, and small images for menu items image | 100 MB–10 GB |
| Photos | listing images, local verification, shopfronts | 2 GB–2 TB |
| Map tiles | offline raster/vector tiles for the area | 1–100 GB |
| Routing graph | walking, cycling, driving, transit graph | 100 MB–20 GB |
| Historical changes | old listings, event history, accepted edits | 100 MB–50 GB |
| Search index | local place search, autocomplete | 100 MB–10 GB |
###### Stuctured Local Data
structured local data is small
a café listing with:
name
opening hours
category
accessibility notes
menu text
local tags
short descriptors
might only be:
5–50 KB
council facilities
stay durable
because they are public infrastructure
community organisations
require vouching
stay visible while active
can become archived if inactive
local notes
stay small and structured
avoid long comment threads
prefer simple access facts
tiles
cached aggressively
regenerated from stable source data where possible
###### Photos
The funny little storage consideration is photos. A café listing with name, opening hours, categories, accessibility notes, menu text, tags, and a few descriptive “vibes” might only be 5–50 KB as structured data. That is basically dust.
But add photos:
A compressed web photo might be 200 KB–1 MB.
Ten photos per place means 2–10 MB per place.
100,000 places with ten photos each becomes roughly 200 GB–1 TB just for images.
using menus as an example
Menus are smaller unless stored as PDFs or images. Text menus might be only 10–100 KB each. PDF/image menus can be 500 KB–5 MB each, which adds up but still usually loses the fistfight to photos.
so the rule is:
store text where possible
compress images aggressively
keep only useful photos
expire or downsample weak media over time
from my experience, it feels risky having the menu as data instead of being able to review the pdf
track:
last updated
how many people confirmed it
whether prices are stale
this is a core and important thing, so people can be prompted at a cafe to check the menu and look at a random item from the menu to see if it is correct
or can rescan the menu to import the data using OCR
But, photos are still useful!
just have a set number depending on the place
which is able to be determined via consensus
so less for a cafe, just enough to give the vibe
but more for different sections of a park
Photos expire or compress unless attached to verified durable places.
nice photos confirmed from other people
this also means that photographers (or hobbysts) can take the best local photos
not everyone needs to have *their* photos for everything, which would balloon into too many
nice photos slowly but surely depreciate over time, so people can be prompted to take new ones, so people can take more and replace older ones, so that everyone gets a turn to take some, if they want to
##### How Much Space Is Needed?
For a realistic “local community directory and map” with cafés, facilities, events, pictures, menus, community groups, local notes, and offline tiles, I’d use this planning estimate:
Small community / campus: 10–50 GB
Suburb or town: 25–150 GB
Small city: 100–500 GB
Large city: 500 GB–3 TB
Metro region: 2–10 TB
That is for a genuinely useful local layer, not a bare database. The bare structured records would be far smaller. The rich human layer is what requires storage.
The practical design rule should be:
A person’s phone stores 1–10 GB (or less; unless they have the space to share)
A local node stores 50 GB–1 TB.
A regional mirror stores 1–20 TB.
The global sharding system stores everything sparse, deduped, and content-addressed.
People naturally cache what they use, universities cache campus and city shards, NGOs cache regions they care about, and deterministic generation prevents the whole thing turning into a bloated planet-hoarding dragon. Your notes already describe this as “people naturally pin what they use,” with local nodes and regional mirrors storing what their communities depend on.
##### Storage Modes
1. Minimal local bundle
This is enough for the app to work locally and feel alive.
For a town, campus, or neighbourhood: 1–10 GB.
For a whole city: 20–100 GB.
This includes core listings, local facilities, simple events, compressed map tiles, and maybe one or two photos per important place.
2. Comfortable community node
This is what a university, library, council, community server, or local volunteer node might pin.
For a town or campus: 20–100 GB.
For a city: 100 GB–1 TB.
This stores richer photos, menus, event history, local routes, council facilities, cached tiles, and maybe some local indicator layers. This seems like the sweet spot. Big enough to be useful, small enough that normal hardware can host it.
3. Rich archive / local mirror
This is the “we keep nearly everything” version.
For a town: 100 GB–500 GB.
For a city: 1–5 TB.
For a metro region: 5–20 TB.
This includes lots of photos, historical snapshots, offline tiles across many zoom levels, routes, old menus, imported council datasets, and local imagery. This is less phone-friendly, but fine for a university server, NAS, library server, or regional mirror.
###### Responsibilites Within Different Storage Modalities
always local
basic map
local search
nearby POIs
local facilities
upcoming events
walking and cycling graph
user’s saved areas
cached when needed
photos
menus
richer place pages
old events
detailed overlays
satellite or photo layers
stored by community nodes
local full directory
offline region bundle
council imports
community organisations
verified event history
local imagery
global canonical store
accepted records
hashes
version history
public datasets
metadata
moderation state
sparse overrides
###### Retaining Data
As an architectural question: What gets stored forever, what gets cached, what expires, and what needs local human confirmation?
For hexagons.world, the default can be:
Photos expire or compress unless attached to verified durable places.
+ confirmed from other people
+ this also means that photographers can take the best local photos
+ not everyone needs to have photos for everything, which would balloon into too many
Events expire into light history.
Menus are stored as text where possible, not giant PDFs.
+ last updated
+ confirmations from other people
Council facilities stay durable.
Community organisations need vouching.
Local notes stay small and structured.
Tiles are cached aggressively but regenerated from stable source data.
That way, the local map can feel rich without becoming a planet-sized attic full of unlabeled boxes.
### Statistics
hexagons carry statistics that people can understand and act on
each hexagon
does not get a single composite score
it holds one value per core indicator
so every place has:
nine main numbers
plus uncertainty for each
this keeps the picture:
clear
honest
harder to game
all inputs, weights, and methods are open
anyone can:
check
criticise
suggest improvements
indicator definitions change slowly
with a clear public record
core 9 local indicators
1. homelessness
2. poverty
3. malnutrition
4. physical illness
5. mental distress
6. heat
7. pollution
8. unsafety
9. disengagement
negative wording is intentional
it’s easier to see where help is needed
each value shows:
“how much this hurts here”
for each indicator
we keep:
plain-language definition
clear units (%, rate, or index)
list of input sources
quality score + uncertainty band
so people can see both:
confidence
and gaps
every indicator is a living estimate, built from multiple kinds of evidence, with visible confidence, open methods, and community correction.
#### Data types
every indicator is a living estimate
built from multiple kinds of evidence
not one perfect source
the map should show:
what we think is true
how well we think we know it
what the estimate is based on
what would make it better
inputs can include:
open public datasets
census data
health data
environmental data
planning data
transport data
housing data
school and service data where available
remote and environmental signals
satellite imagery
tree cover
urban heat
green space
lighting at night
pollution
noise
water
shade
surface data
local organisation inputs
non-government organisations
councils
universities
community groups
food banks
clinics
shelters
libraries
faith groups
community surveys
small local surveys
micro-check-ins
student projects
volunteer observations
questions asked by local groups
factual traces
a garden was planted
a free bus was added
a shaded path was improved
a community meal started
a fountain was installed
a local organisation began serving an area
not all inputs are equal
some are precise
some are partial
some are old
some are local but hard to verify
some are broad and reliable
but too coarse to explain street-level reality
so each input carries metadata:
source
date collected
geographic resolution
method
update frequency
known limitations
privacy level
confidence score
which indicator it affects
the system should never simply ask:
is there data?
it should ask:
what kind of data is this?
how recent is it?
how local is it?
how reliable is it?
what does it miss?
what would improve it?
#### Confidence and uncertainty
confidence should be visible
not hidden inside the model
the goal is not:
to pretend every hexagon has perfect data
the goal is:
to show the best current estimate
and the strength of the evidence behind it
distinction
input confidence
how much we trust a particular source
indicator uncertainty
how sure we are about the final estimate for that hexagon
examples
heat
fresh satellite data
tree-cover data
surface temperature
local shade data
likely higher confidence
loneliness
national averages
weak proxy signals
limited local survey data
likely wider uncertainty
food access
supermarket distance
food prices
transport access
food bank data
community meal data
gets stronger when local organisations contribute current information
each indicator can be shown as:
estimate
the current value
range
the plausible band
confidence
how strong the evidence is
freshness
how recently it was updated
dispute state
whether locals, researchers, or organisations have questioned it
people should be able to tell the difference between:
a strong estimate
a weak estimate
a disputed estimate
an outdated estimate
a locally improved estimate
weak data becomes an invitation
if food access data is weak
a local group can survey:
supermarkets
community kitchens
food banks
staple prices
transport access
if green space data is weak
volunteers can verify:
parks
shade
trees
paths
public seating
usable open space
if loneliness data is weak
a university or local organisation can run:
careful surveys
privacy-preserving check-ins
small group studies
local service mapping
the point
people can see not only where things may be bad
but where the data itself is thin
#### Improving estimates
statistics are not fixed reports
they are shared local models
that improve over time
process
start with broad public data
add environmental and spatial signals
compare with local knowledge
invite corrections and better sources
update the estimate
update the confidence score
keep the old version in the record
example
a hexagon might begin with:
a rough poverty estimate
from national or regional data
later it may improve through:
local service data
food price data
transport access
school data
housing data
community surveys
organisation inputs
the value changes
but so does the confidence behind it
this means the system can improve
without pretending to be finished
old estimates remain visible
as part of the version history
people can ask:
what changed?
why did it change?
which source changed it?
did the real world change,
or did the data improve?
this matters because:
better data should not look like magic
and uncertainty should not look like failure
it should feel normal that:
early estimates are rough
local evidence improves them
methods get refined
confidence increases slowly
disagreement leaves a useful record
#### Collaborative statistics
local statistics become better
when different people improve different parts of the model
no single group owns the truth
roles
statisticians
test the model
debate weightings
check which variables actually predict the outcome
make uncertainty visible
remove variables that add noise
local organisers
check whether estimates miss obvious local realities
notice missing facilities, services, and local conditions
connect numbers to lived experience
institutions
contribute stable datasets
share aggregate programme data where appropriate
help maintain continuity over time
use the same grid in reports and planning
volunteers
find missing public data
verify local amenities
update facilities, events, and traces
help keep local records fresh
residents
point out mismatches
answer small surveys
notice when a number does not match local experience
suggest better local sources
data journalists and researchers
explain uncertainty
compare places carefully
make methods understandable
help the public see what the numbers do and do not mean
the estimate gets better because:
many people can inspect the same number
question the same evidence
and add better information over time
disagreement should be useful
not hidden
when people disagree
the system should capture:
what is disputed
who is disputing it
what evidence they point to
whether the dispute affects the estimate
or only the interpretation
the aim is not perfect certainty
the aim is:
a public system where uncertainty is legible
disagreement is useful
and better evidence can steadily replace weaker evidence
#### Indicator design
indicator design starts wide
for each indicator
collect all relevant variables
then slowly reduce them
into a smaller, more stable model
process
collect possible inputs
public data
environmental signals
local organisation data
survey data
factual traces
review which variables help
which ones predict the outcome
which ones are redundant
which ones add noise
which ones create bias
local sanity-checking
does the estimate miss obvious local realities?
are there known gaps?
are some groups invisible in the data?
are proxy signals misleading here?
statistical review
test weightings
check uncertainty
compare similar places
record assumptions
publish method changes
public revision
proposals stay open
changes are versioned
old methods remain visible
alternative models can be compared
the goal is:
a small, stable set of inputs
that most people can understand
question
and live with
even when they disagree on the details
#### Bayesian hexagons
priors + signals + neighbour pooling
outputs are distributions with uncertainty
not just single numbers
ingredients + signals
priors:
national or census baselines
local signals:
satellites
admin data
digital traces (carefully throttled)
NGO inputs
covariates:
density
travel time
education
neighbour pooling:
~6 adjacent hexes
model shape (plain English)
start with prior
update with signals
pool with neighbours
report, for each indicator:
mean
interval
uncertainty score
design choices + ethics
partial pooling
monotone priors (values from 0–100%)
missing-not-at-random adjustments
temporal smoothing
open priors, weights, intervals
aggregates only; digital signals rate-limited
data sources + scale
satellites
demographics
surveys
admin datasets
digital traces
shocks (fires, floods, etc.)
UI:
colour = estimate
opacity = certainty
roll-ups carry uncertainty upward
not just point estimates
improving over time
micro-surveys at local scales
lightweight NGO “crumbs”
simple, small inputs
community feedback loop
dispute values
suggest evidence
stats evolve with reality
not just with code
#### Measurable change
why this matters
statistics are only useful if people can see them move.
not as a scoreboard,
but as a quiet sense that things can improve.
neutral indicators
change must reflect the real world,
not activity inside any organisation,
not volunteer counts,
not participation metrics.
indicators stay independent and grounded in:
satellites
admin data
local reports
environmental signals
clearly defined inputs
so improvement comes from conditions changing,
not from who shows up.
how change is detected
each indicator updates as:
new signals arrive,
models rerun,
local conditions shift.
some indicators move quickly (heat, shade),
others slowly (poverty, distress).
every update includes:
the estimate,
the uncertainty,
and the confidence behind it.
traces (light, factual)
hexagons keep simple notes when something verifiable happens:
a fountain installed
a garden expanded
a free bus reinstated
these are not ratings,
not endorsements,
not tied to groups.
they’re just quiet context
for why a number might have shifted.
avoiding skew
no indicator uses:
organisation size,
community activity,
or platform engagement.
those signals stay separate.
the statistics themselves stay neutral
so confidence isn’t confused with enthusiasm.
reading change
people can compare:
before → after,
one hex → nearby hexes,
similar places elsewhere.
this helps them see:
where things are improving,
where strain remains,
and what patterns might be forming.
precision and scale
some inputs exist at metre resolution
(heat, shade, noise, tree cover)
and are then averaged upward.
this lets people:
notice small improvements,
understand where gaps are,
and act at a scale that feels human.
picture over time
each hex shows:
the current indicator,
its trend,
its uncertainty,
and a few factual traces.
no scoring,
no gamification,
no pressure.
just a calm, honest sense of direction.
### Distributed volunteer compute
the core hexagons.world stack does not need much compute
that is the point of the architecture
most hexes are deterministic
deep layers are generated when needed
clients do as much as they reasonably can
local data is cached close to where it is used
shards are small and independently fetchable
the shared compute layer exists for something else
not ordinary map rendering
not every route
not every tile
not constant server-side processing
it exists for heavier public-interest work:
refining global statistics
rebuilding indicators when methods improve
processing large open datasets
running public What if scenarios
modelling heat, shade, pollution, food access, and similar local conditions
creating calm, predictable ways to pool spare computing power
the useful framing is:
we do not need enormous compute
to keep the map alive
but if people can safely donate compute
then the public layers can become much better over time
the shared compute layer exists for something else:
refining global statistics
running heavy analyses that help local communities
create a calm, predictable way to pool power worldwide
shape of the system
small operating system (trimmed MINIX)
why MINIX?
free and open-source
small
heavily documented
microkernel-based
designed around reliability, flexibility, and security
MINIX 3 is built around a tiny microkernel
with much of the operating system running as isolated user-mode processes
keeps the kernel small and services separate
this contains failure
avoid unnecessary system power
make each piece easier to reason about
MINIX also has unusual educational value
it's been used for teaching operating system design and has been documented in detail
large parts of the source have historically been explained alongside the design
it has papers, notes, books, and examples around it
that makes it useful for a project where:
people may want to understand the system
volunteers may want to audit it
developers may want to trim it
AI tools may help explain and modify parts of it
the operating system should remain legible rather than mysterious
this is why a trimmed MINIX-like system is appealing
smaller than a general Linux distribution
more inspectable than a normal desktop OS
more purpose-built than asking volunteers to run random services
more aligned with embedded and appliance-style use
but, the first implementation does not need to be 'pure'
it just needs to work
use POSIX and small utilities
allow shell scripting
let people contribute from any ordinary terminal
keep the core jobs portable across systems
it can be a little messy at first
as long as the interfaces stay boring and stable
eventually become portable
boots anywhere: spare machine, VM, old laptop, gaming rig, phone (light)
log in with peaceful passport → node joins the pool
data, storage, and jobs
large public dataset repository
sharded across nodes via torrent-style sharing
triple redundancy per region
tasks written in a small functional language
clear inputs, clear outputs, no surprises
nodes run tiny slices of global jobs
#### What Is the Compute Pool For?
shared compute is best suited to jobs that are:
batchable
parallel
public
reproducible
slow-tolerant
useful to many people
example global jobs
white roofs and urban heat modelling
tree cover and planting potential
heat island maps
integrations of many datasets to refine indicators
full re-runs of all indicators when methods improve
it's definitely not trying to be:
a real-time cloud provider
a replacement for all servers
a marketplace for compute
a crypto-style mining network
a way for hardware owners to gain power
it behaves more like:
slow but enormous
resilient
best-effort
geographically distributed
aligned with the people using the system
#### Shape of the Compute Pool
a person or organisation can donate spare compute
that might come from anywhere, such as:
spare machines
laptops
desktops
gaming rigs
university servers
donated datacentre machines
or a phone doing light work
the node runs a small, constrained environment
trimmed operating system
minimal dependencies
clear job runner
no unnecessary services
the person logs in with Peaceful Passport
not to gain status
not to earn credits
not to control the network
but to make contribution accountable
##### Processing Distributed Data
the node joins the shared pool
it receives small slices of public jobs
it downloads only the datasets needed for the task
it computes the result
then returns:
output
job version
input hashes
method version
node identity
runtime metadata
this way, we can always know:
what was computed
from which inputs
using which method
under which version
by which accountable node
##### Designing Distributed Compute Jobs
job code must be small, declarative, reviewable
no arbitrary network access
nodes see only what they need to compute
prevents harmful or off-purpose workloads
jobs should have:
clear inputs
clear outputs
no hidden network access
no arbitrary side effects
no surprise dependencies
no private data unless explicitly authorised
if a job cannot be explained clearly
it probably should not run on the public pool
##### Deterministic Verification
determinism is what makes the trust model work
the same inputs
with the same method
under the same version
should produce the same result
that means work can be checked
not by trusting the node
but by recomputing the job
this changes the meaning of duplicated work
duplication is not always waste
sometimes duplication is verification
if they agree
confidence increases
if they disagree
the system flags the result
telling the network that something needs checking here
the question becomes:
did someone compute dishonestly?
did a node fail?
did the method contain ambiguity?
did the input dataset differ?
did the job need stricter reproducibility?
##### Redundant Work
some work should be deliberately doubled up
especially:
indicator refreshes
statistical rebuilds
public What if outputs
high-impact environmental layers
results that may affect public interpretation
results used by institutions or local organisers
possible verification pattern:
ordinary job
one node computes
random spot checks happen later
important job
two or three nodes compute independently
results must match within defined tolerance
disputed job
more nodes recompute
method and inputs are reviewed
result stays marked as disputed until resolved
the system does not need to duplicate everything
it only needs enough overlap
to make cheating unattractive
and errors visible
because anyone can theoretically recompute the work
fraud becomes fragile
a false result has to survive:
open inputs
versioned methods
random recomputation
other nodes
public inspection
and future reruns
that is a hard environment for funny business
##### Peaceful Passport and Accountability
Additionally, peaceful passport gives identity to contributing compute
Peaceful Passport gives nodes accountable identity
it does not make their outputs automatically trusted
the output is trusted because:
the job is reproducible
the inputs are known
the method is versioned
other nodes can recompute it
mismatches are visible
Passport helps with:
rate-limiting
abuse prevention
reputation for reliability
pausing bad nodes
contacting operators when something breaks
but Passport should not create:
compute aristocracy
leaderboards
voting power
governance weight
public status games
a reliable node can be quietly trusted more
for scheduling purposes
but that trust should remain operational, not political, nor for clout or power
##### Local-first Usefulness
shared compute should help the contributor’s own area first where possible
if someone donates compute in Perth
their node may naturally help process:
Perth map shards
local heat indicators
local routing layers
nearby public scenarios
Western Australia datasets
not exclusively
but preferentially where it makes sense
this gives contribution a local feeling
the person is not just helping an abstract global machine
their computer becomes a small anchor for the place they live
this also improves the network
because local compute often pairs naturally with local storage
the same node might:
cache local tiles
pin local datasets
serve nearby users
process nearby indicators
help keep local tools fast
benefits for normal people
runs calmly in the background
helps their own hex first
shards local map tiles so neighbours see results faster
their phone and computer become small anchors for their local area
##### Scale and Resiliency
aim for a million nodes:
people’s computers
gaming rigs
phones (light compute + sharding)
donated datacentre nodes
jobs are asynchronous
cluster remains stable even as nodes join/leave
###### Paid and Donated Compute
volunteer compute should handle what it can
but some work needs guarantees
for example:
institutional deadlines
private What if jobs
large urgent rebuilds
service-level commitments
sensitive datasets
commercial or council work
those should use:
dedicated compute
paid compute
private compute
or mixed compute
the clean distinction is:
public best-effort work
can use the shared pool
private or guaranteed work
uses dedicated resources
this prevents volunteer compute
from becoming an invisible subsidy
for private institutional needs
public contribution should improve the commons
not quietly run someone else’s paid workload
##### Feedback for Contributors
people who donate compute should be able to see that their contribution was useful
but it should be private and calm
for example:
your node helped refresh heat indicators in this region
your node helped complete public scenarios this month
your node helped verify a statistical rebuild
your node helped serve local shards to nearby users
this should not become:
a leaderboard
a public ranking
a status badge based on quantity
a competition
theme underneath
people realise:
a shared compute layer is powerful in its own right
they are part of something large without effort
minix-based OS is also personally useful:
they can run their own small tasks on it
local workloads can stay local
phone can connect and treat their machine as a tiny personal cloud
nothing complex:
the same OS that powers hexagons.world
also becomes a calm, private space for people to run things they care about
without ads, tracking, or noise
end state
a shared global compute layer focussed on hexagons.world
plus a calm personal computer for people themselves
fast, local, minimal, human
built on the same microkernel that keeps the whole ecosystem simple
#### Beeswax
what beeswax is (and isn’t)
“Beeswax” is a quiet metaphor for shared giving.
it is a way to talk about:
donated compute
donated storage
donated datasets
it is not:
a currency
a credit system
a way to earn status or power
people and organisations give what they can
because they want to support the commons
not because anything is owed in return
shared compute commons
people and organisations can donate:
spare CPU
spare GPU
spare storage
public or shareable datasets
this powers:
public What if scenarios
global indicator refreshes
data preprocessing and cleaning
heavier background simulations
the pool is:
elastic
best-effort
built from many small contributions
it is similar in spirit to:
Folding@home
BOINC
volunteer mirrors
community-run infrastructure
no one “gets” anything special for donating
the work just happens,
and everyone benefits from better public tools.
no credits, no scores
we do not:
track “how much” each person donated as a score
show leaderboards
rank contributors
tie contribution to voting, influence, or control
this avoids:
virtue signalling
competition and “top donor” games
wealth or hardware turning into power
the culture is about "helping if you can"
not:
“prove you helped more than others”.
how contribution is shown
on a person or organisation profile
we may show small, optional badges such as:
🌱 contributes compute
📦 contributes storage
📊 contributes data
also available on people's passports for people contributing
(organisations shouldn't use passports, they're for people)
we do not show:
numbers
historical totals
public counters
the signal is:
“this person helps keep the lights on”
not:
“this person is more important than others”.
global view
at the system level
we may show aggregate figures only, such as:
“X organisations and Y people donated compute this month”
“the commons processed N public scenarios this week”
these are about:
the overall health of the commons
the scale of shared work being done
they are not:
tables of individual contributions
or any form of ranking.
private feedback (optional)
people who donate compute may see quiet, private notes such as:
“your node helped complete N public scenarios this month”
“your donated compute helped refresh heat indicators in these regions”
these are:
only visible to them
not shareable widgets
not intended as social proof
the purpose is:
to show that their contribution was actually used
without turning it into something to perform or optimise.
governance stays separate
governance is tied to:
peaceful passports
and whatever voting rules sit above them
we do not:
weight votes by any kind of donation
give extra say to donors
create proxy or delegated power via contributions
people who donate compute, storage, or data:
have the same formal voice
as everyone else with a passport.
scheduling and fairness
public What if jobs:
run on the shared pool
on a best-effort basis
and wait in the queue when the pool is busy
there are no:
priority lanes
paid “fast tracks”
hidden weighting by donor identity
if an organisation needs guaranteed
How else might compute be useful?
// excess volunteer compute
purpose
the core hexagons.world map and public indicators stay free.
paid layers exist for work that:
needs heavier computation,
involves private data,
or requires dedicated support and uptime.
summary
Maps
calm navigation and local planning.
base map, simple routing, and local tiles are free.
a small subscription covers:
deep custom routing,
full offline regions,
and heavier comfort/safety workloads.
API
small, boring place-and-statistics + tiles API.
generous free tier for students, open-source, and small apps.
usage-based pricing close to raw cost at scale.
What if – Public
scenario builder over public indicators and datasets.
runs on the shared volunteer compute pool.
flat personal / organisational subscriptions,
no per-job billing.
What if – Private
the same recipes and diagrams,
but with your own datasets and private compute.
organisational subscription + neutral compute top-ups,
for councils, NGOs, and teams with sensitive data.
principles
paid tools:
exist to cover running costs and create donations
do not control governance,
and do not lock in data.
people can:
start on the free layers,
move into paid offerings when their work demands it,
and step back out without losing their maps, recipes, or results.
### Maps
we will build the best maps app
useful
local
yours
it sits on the same hexagons.world grid and statistics
but feels like a calm, personal tool
for navigating a more local world
most maps applications are not really yours
you use them every day
but you do not control how they look
how they behave
or what they optimise for
the problem is not only features
it is incentives
the map provider decides what matters
the user adapts afterwards
when a large map changes its colours, routing, or interface
people often hate it
but they have almost no recourse
they can complain
or leave
but leaving usually means giving up things they have come to rely on
open alternatives help
but they usually do not yet feel complete enough
they may be admirable
and more ethical
but still miss the polish, speed, or practical layers people expect
so most people remain inside tools they did not choose in full
the result is a strange relationship
maps are among the most intimate tools people use
where they walk
where they meet
how they get home
what they notice around them
but the experience is centrally decided
not locally shaped
not personally owned
not meaningfully adaptable
we want to build the best maps application
not just a good one
not just a private one
but one that is genuinely better to use
#### What a Better Map Should Be
a better map should not just be:
open
private
or well-intentioned
it has to work well enough that people actually keep using it
it should be:
clear
fast
private
customisable
locally useful
reliable offline
and pleasant enough to open every day
the map should feel like a tool you control
compared to a service that keeps changing around you
##### Why Current Maps Feel Frustrating
most people rely on maps constantly
they use them to:
get home
meet friends
find shops
check transport
walk at night
travel somewhere unfamiliar
plan errands
avoid getting lost
but the experience is mostly decided elsewhere
users usually cannot control:
major interface changes
colour changes
routing assumptions
which places are emphasised
how much visual clutter appears
what data is collected
or how local information is ranked
when a big maps app changes something
people may dislike it
but often keep using it anyway
because switching maps usually means losing:
search quality
routing quality
saved places
place data
transit information
and general reliability
open-source alternatives are important
but often still feel incomplete for everyday use
so the aim is not:
“an ethical map that people tolerate”
the aim is:
a map people prefer using
##### Customisable by Default
people use maps in different ways
so there shouldn't be one fixed default for everyone
a person should be able to choose:
how much detail appears
which colours are easiest to read
which layers are shown first
what kinds of routes they prefer
how much movement or animation the app uses
examples:
e-ink mode
high contrast
low detail
clear outlines
no colour-dependent information
night mode
lower glare
clearer route lines
lighting and safety layers easier to see
field-work mode
terrain
access tracks
land use
boundaries
facilities
cycling mode
incline
surface quality
protected lanes
traffic stress
shade
low-bandwidth mode
cached tiles
simpler graphics
less live data
still usable offline
there is no single best map view
there are many good ones
and people should be able to shape the one they live with
customisation shouldn't mean endless settings
but instead,
a few clear presets
with simple controls
that let the map fit the person’s life
and then they can tailor them to how they see fit
##### Deterministic Routing
the fastest route is not always the best route
hexagons.world already provides a rich local layer
common addressing
local indicators
place-based statistics
and a shared reference for what is happening where
that gives us a base most maps do not have
a map is not just roads and search
it can also understand context
texture
local conditions
and what people nearby actually care about
with volunteer compute and open data
we can support useful routing layers that are normally ignored
for example
shade on the way home
lighting at night
daytime heat retention
local quietness
or comfort by time of day
some of this can come from
satellite imagery
thermal readings
lighting data
land cover
footpath and tree data
local contributions
some can run on-device
where privacy or responsiveness matters
some can run through distributed compute
where heavier shared processing is useful
this is in opposition to one hidden system deciding the “best” route
people should be able to combine clear building blocks
more shade
more lighting
less traffic stress
more hills
flatter paths
quieter streets
better footpaths
this is especially useful for:
women walking at night
children and teenagers
older people
people with a disability
cyclists
people walking in hot weather
people carrying groceries
people who are tyred or stressed
people in unfamiliar areas
this matters because preferences are highly personal
one cyclist may want more hills in the morning
to push harder and wake up properly
the same person may want a flatter route home in the evening
another person may prioritise benches
water
or smooth surfaces
deterministic here does not mean rigid
it means understandable
composable
and stable
people should know why a route appeared
what tradeoffs produced it
and how to change it
a route should explain its tradeoffs
for example:
“3 minutes longer, but more lighting”
“slightly longer, but more shade”
“avoids steep hills”
“uses quieter streets”
“fewer road crossings”
this makes routing feel understandable instead of mysterious
this lets the map answer questions that are quietly important
not “what is the fastest route?”
but:
what feels safest tonight?
what keeps me coolest in summer?
what route is nicest when I am tyred?
how do I get home in a way that feels good?
therefore, a person should be able to adjust the route without fighting the app
##### For Local Communities
a better map should show what is useful nearby
not only:
major businesses
highly ranked places
paid listings
or globally popular results
it should make local things easier to find:
libraries
public toilets
water fountains
community centres
parks
shaded areas
free buses
food banks
community meals
repair cafés
local clubs
quiet study spaces
safe meeting places
cheap local food options
many useful things already exist
but are hard to discover
they may be on:
council websites
paper posters
Facebook pages
church newsletters
student noticeboards
old PDFs
or word-of-mouth
you can begin to ask
would people in this area support better lighting here?
do people repeatedly choose this shaded corridor?
where are the quiet routes people already trust?
this makes maps more than navigation
they become a way of noticing what local life needs
not in an abstract way
but directly through movement
preference
and everyday use
##### Private by Design
maps reveal sensitive parts of life
they can show:
where someone lives
where they work
where they worship
where they get help
where they recover
who they visit
what routines they follow
so the default should be:
minimise tracking
process locally where possible
store less
sync only what is needed
make sharing deliberate
personal route preferences should be private
saved places should be exportable
local caches should work without needing an account
Peaceful Passport can be used where identity is useful
such as RSVPs
vouching
or contributing edits
but ordinary map use should not require
constant identity
##### Calm Vibe
the app should be easy to read quickly
it should avoid:
visual clutter
constant popups
ads
engagement tricks
unnecessary notifications
dark patterns
sudden redesigns
the map should prioritise:
streets
paths
labels
route clarity
local facilities
and whatever layer the user has chosen
if someone opens the app while stressed
it should help them decide what to do next
not add more noise
##### Works Offline
a useful map should keep working when the internet is bad
people should be able to download their neighbourhood, campus, town, or a travel area
in fact, our app makes you download the map to their device
local nodes can help with this
a campus, library, council, or community server
can keep local map data available nearby
this makes the map more reliable
in places where mobile data is expensive
or inconsistent
##### Optional Paid-tier Using Distributed Volunteer Compute
pretty much everything that can run on someone's device, should run on their device
and is completely and entirely free
deterministic routing
local information
we will charge one dollar per month
and make it feel like one dollar a month everywhere
adjusted into local currency
(i.e - 1 ringit, one euro, one australian dollar)
for features that could use the global compute pool to create donations for useful features
for example:
deeper route personalisation
shade-first routing
multi-stop errands
comfort-aware routing
advanced personal layers
heavier recomputation
(these would feed into the undercurrent, expanded in the peaceful foundation people section)
##### The Aim
the aim is to build a map that is:
good enough to replace normal maps for everyday use
private enough to trust
customisable enough to fit different lives
local enough to show what people usually miss
calm enough to use when stressed
and open enough that people are not trapped
it should help people:
get around
find useful local things
move more safely
avoid unnecessary stress
and understand their area better
not by asking them to join a platform, but just by being a better map
#### As an app
the app should already do almost everything most people need
and do it privately
and do it calmly
for most everyday use
that means a clear base map
directions for walking, cycling, driving, and transit
offline tiles for your local area
and local layers such as events and council facilities
none of this should feel special
it should just feel like a competent map
that works properly
without ads, tracking, or engagement tricks
a lot of the value is in the small touches
not because they are flashy
but because maps are habitual tools
if the colours are slightly harder to read
you feel that every day
if the map keeps foregrounding the wrong things
you feel that every day too
so a good map should let people set a few simple preferences
and then mostly forget about them
what matters is not endless tweaking
but the feeling that the map quietly fits you
##### Customisable
maps should not be stock-standard
people move through the world differently
so they should not all inherit the same defaults
someone should be able to set:
how the map looks
how routes are preferred
what layers appear first
and what kinds of places or conditions matter more to them
this begins with appearance
map appearance is not fixed
because legibility is not fixed either
some people need high contrast for work
quick reading
stable colours
clear visual hierarchy
others want softer palettes in the evening
or warmer tones for walking days
the point is simple
a map should be easy to read in the conditions people actually use it in
not only in the designer’s preferred view
it also extends to overlays
because different people are looking for different things in the same place
one person may care about tree cover and shade
especially in summer
another may care about heat, noise, or event density
another may want council facilities surfaced clearly
libraries
pools
community centres
BBQs
free buses
shuttles
these layers should be easy to toggle
easy to combine
and easy to ignore when they are not useful
customisation should also shape routing
not just appearance
people should be able to express practical preferences
avoid hills over a chosen gradient
avoid carparks after dark
show local co-ops and repair cafés before big chains
these are not exotic requests
they are ordinary differences in how people live
a map becomes much more useful
when it can reflect those differences directly
###### Who It Really Helps
this matters most for people who rely on maps heavily
not just people checking directions occasionally
for some people
a map is a constant background tool
and small improvements compound quickly
people whose work depends on maps
drivers
couriers
mobile technicians
benefit from stability first
high-contrast colours
clear hierarchy
and routes that respect time, fuel, and stress
they do not need novelty
they need something readable
predictable
and fast to parse
people on foot or bike often want something different
comfort matters at least as much as speed
quiet streets
shade
gardens
footpaths
protected bike lanes
can matter more than shaving off a minute
for them
the best route is often the one that feels nicest
or safest
or least draining
people running errands and ordinary life
groceries
chemist
post office
library
need the map to support sequences of movement
not just isolated trips
they are often planning within walking distance
or around what they can carry
or around a day that does not assume a car
a better app helps life fit together
not merely travel happen
people who want calmer and safer movement
especially at night
need something else again
routes that reflect how places actually feel
not only how roads are classified
the route people are willing to take after dark
is often not the nominally shortest one
a better app should understand that
and make it easy to act on it
#### Useful features
a better maps app should not only help people get somewhere
it should help them move through a place well
that means:
showing paths that make local movement easier
understanding transit as part of ordinary life
and describing places in ways that are actually useful
the goal is not feature accumulation
it is a calmer and more truthful experience of place
##### Walking and Cycling Paths
walking and cycling are where many maps still feel thin
especially compared with what people actually need in daily life
the obvious road route
is often not the best route on foot
or by bike
small connectors matter
footpaths
laneways
cut-throughs
trails
quiet side streets
protected bike links
these are often the parts of a city
that make local life feel possible without a car
this is one of the quiet strengths of openstreetmap-derived systems
they are often better at the fine-grained texture of movement
not because they are magical
but because people on the ground add the paths they actually use
that means the map can become closer to lived reality
especially for:
walking
cycling
campuses
inner suburbs
town centres
parks
and everyday local travel
a better maps app should take these paths seriously
not treat them as secondary to roads
for many people
the useful question is not:
what is the fastest route a car could take nearby?
but:
what is the nicest route on foot?
what is the safest route on a bike?
where is the shaded path?
where is the quiet way through?
this is where maps start to feel like they understand human movement
rather than just transport infrastructure
##### Public Transit
public transit should not feel bolted on
or like a fallback for people who do not drive
for many people
transit is the structure of everyday movement
but the useful journey is rarely just:
stop
line
stop
it is usually:
walk there
wait there
change there
finish the last stretch somehow
a better maps app should understand the whole trip
not only the formal transit segment
that means helping someone see:
how far the walk really is
where the awkward transfer is
where there is shade or shelter
where the last stretch becomes unpleasant
where several errands fit naturally into the same trip
the best transit integration feels like the map understands the network
not just the timetable
it helps people think with transit
rather than merely receive transit directions
that is especially important in local life
where people are not only commuting
but combining:
work
groceries
libraries
post office
childcare
and meeting others
a map becomes much more useful
when transit is treated as part of everyday life
rather than a separate mode pasted onto the side
##### Vibes Instead of Reviews
most review systems flatten places too harshly
a single number collapses too much reality
restaurants are not one-dimensional
food
price
service
cleanliness
speed
atmosphere
noise
portion size
dietary options
a rating of "4.2”
hides all of these trade-offs
it tells you very little
except where something sits inside a ranking culture
###### Criticisms of Star-based Restaurant Reviews
a single number collapses everything
different experiences become indistinguishable
good food and bad service
and average food with friendly staff
end up flattened into comparable scores
even though they are different kinds of place
ratings punish the wrong things
people rate from mood
expectation
price sensitivity
or one bad incident
not from any stable standard
cheap places are often dragged down
when compared unfairly with expensive ones
and serious issues get misclassified
a hygiene or safety problem
is not the same thing as “bad restaurant”
but the system pushes everything into one bucket
averages create harsh cliffs
people think in thresholds
not gradients
4.5 feels good
4.0 feels uncertain
3.5 feels bad
small differences start to feel socially enormous
and dropping below a visible threshold can damage a place badly
this creates fear for owners
and a harsh comparison culture around ordinary local businesses
reviews become something to manage
rather than something to learn from
places start chasing ratings
requesting positive reviews
filtering unhappy customers
smoothing perception
fake or inflated reviews emerge
and the focus shifts
from improving the place
to protecting the score
early reviews lock perception
the first 20 to 50 reviews
can shape long-term reputation
it becomes hard to recover from early negatives
even when the place improves
the rating looks stable
but the reality underneath may have changed completely
outliers distort meaning
1-star outrage
5-star hype
enter the same average
even when they refer to totally different kinds of experience
the system cannot distinguish severity
or type
a safety issue
and a moment of enthusiasm
should not be treated as equivalent inputs
stars also discourage nuance
people stop describing what a place is like
and start reducing it to symbols
rich detail gets lost
price
portion
atmosphere
context
which is exactly the information other people actually need
the deeper problem is that stars do not match real decision-making
people choose based on situation
cheap meal
date night
quick lunch
dietary needs
somewhere open late
a single rating does not answer these questions
so the format is misaligned with actual use
###### Better System: Describing Instead of Ranking
the map should help people understand places
not rank them globally
that means characteristics should replace scores
or at least come first
a place can be described by:
price level
portion size
food style
speed
vibe
dietary options
noise
whether it suits groups or quick stops
this makes trade-offs visible
which is what people actually need in practice
critical flags should stand apart clearly
not disappear into an average
hygiene problems
safety issues
accessibility problems
misleading behaviour
should be shown directly
and unambiguously
these are not “part of the vibe”
they are important facts
short situational summaries are often more useful than scores
cheap and filling
slow but high quality
busy at lunch
student spot
open late
these phrases help someone understand a place quickly
in a way that is much closer to real choice
local context should also be visible
surfaces everyday places
family-run places
student spots
late-night options
quiet local favourites
without ranking them against abstract global standards
the point is not:
is this one of the best restaurants in the world?
but:
is this the kind of place I want right now?
written reviews can still exist
but as optional depth
stories
edge cases
specific experiences
should be preserved
not collapsed into a single number
that keeps nuance available
without making it the whole interface
###### Simple but Honest Trade-off
stars succeed because they are simple
fast to scan
low effort to understand
but they are simple by flattening reality
which is exactly the problem
characteristics are richer
and more truthful
but they must still remain legible
at a glance
so the design challenge is:
keep clarity
without collapsing everything into one ladder
that probably means small visual language
little logos
short descriptors
clear flags
so someone can see quickly
what a place is like
and choose based on what matters to them
end point
the goal is not to rank places
but to understand them
show what a place is like
not how it compares globally
highlight what matters
not what averages out
and let people choose based on their situation
not a number
#### Local directories and fulfillment
joke reference cool thing: fulfillment isn't something you buy, and it's not centreed on one place
a good local map should help people find what already exists
not only route them between places they already know
a lot of local life is technically visible
but practically hidden
it sits across:
old council pages
scattered websites
group chats
noticeboards
Google results
and people’s memory
the problem is often not that a place lacks useful things
but that they are hard to discover
hard to compare
and hard to fit together
this matters because local life is not one destination at a time
it is usually a chain of small needs
groceries
post office
chemist
library
somewhere to sit
somewhere to eat
somewhere to fix something
these things already form a pattern in people’s day
but most maps still treat them as separate searches
a better map should help them cohere
so the area around someone starts to feel usable
rather than merely searchable
##### Errand Planner
an errand planner is one of the simplest ways a map can become more helpful
not by being dramatic
but by reducing friction in ordinary life
it should group errands in a way that respects:
time
stress
transport method
and what someone will actually be carrying
the best route for a person on foot with groceries
is not the same as the best route for a cyclist
or a parent with a pram
or someone ducking out between other obligations
this also creates room for local preference
the planner can favour nearby places
co-ops
repair cafés
or small local businesses
not because the system is moralising
but because many people would prefer to support what is near them
if the map made it easy enough
a map becomes much more useful
when it helps daily life fit together in one legible plan
rather than leaving people to improvise from four tabs and three apps
##### Local Guidance
the map should also help explain what “local” means in practice
because local life looks different in different places
in one region
local may mean a walkable strip of shops
in another
it may mean a town centre plus a weekly market
in another
it may mean a few recurring places spread across driving distance
the point is not to impose one idea of local
but to make each local pattern more visible
this is especially useful for recurring things
markets
repair days
community meals
pop-up services
seasonal events
these often matter more to daily life
than permanent listings alone
but they are also easier to miss
because they sit in weak local channels
Facebook pages
posters
group chats
council calendars
a better map should help people notice what is already happening
before adding more noise to the place
##### Council and Facility Integration
council and civic facilities are often more useful than they seem
but also more hidden than they should be
libraries
pools
community centres
shaded parks
public toilets
fountains
BBQs
free buses
shuttle routes
are not glamourous features
but they shape whether a place feels liveable
especially for:
children
older people
students
people without cars
and anyone trying to spend less money
these kinds of facilities should sit naturally inside the map
not buried in PDFs
or fragmented across bad council interfaces
when a person can actually see:
where the fountain is
where the toilets are
where the library is
where there is shade
where the free bus runs
the area starts to feel more supportive
and more human
that is part of what a local map should do
not just represent a place abstractly
but make it easier to live there
##### Businesses
local businesses should also be represented in a more useful way
not merely as names on a commercial layer
for many people
the useful question is not just:
is there a café here?
but:
what kind of café is it?
is it open?
is it cheap?
is there seating?
does it have the kind of food I want?
even simple things like café menus
can make a map much more practical
because they turn a place from a pin
into an actual option
this matters more in local life than in destination travel
people making everyday decisions
often do not want generic prominence
they want:
what fits
what is open
what is nearby
what makes sense right now
a better local business layer should help with that
without turning the map into an advertising marketplace
##### Programmers and Volunteers
a lot of this layer can be built gradually
through open data
small parsers
local tagging
and practical contributions
programmers and volunteers do not need to solve everything at once
they can create minimal ways of pulling useful data from places
where allowed
import open data
and tag facilities into hexes
this work is not glamourous
but it is exactly the kind of work
that makes a map feel grounded and alive
it also suits the structure of hexagons.world
because the work can accumulate locally
one area gets better library data
another gets markets and repair days
another gets better walking links
another gets café menus and local notes
the result is not one giant central database arriving complete
but a map that gradually becomes more useful
as people add the kinds of detail that actually matter where they live
##### End Point
this lets people see what their area already offers
before assuming nothing is there
and where gaps are obvious
quiet pressure can build for better local life
the point is not only information
it is legibility
a better local map makes a place easier to understand
easier to use
and easier to care about
#### Rocky
similarly to Clippy in the context of reasonable.diet, Rocky is a small programmable helper
Rocky wants to help you sniff out your local community
and, for you to go on an adventure with your dog
as dogs collectively cannot believe that we're not exploring more of the world around us
Rocky exists to make the map more personal
not by becoming a personality
and not by pretending to be intelligent in a vague way
the point is much simpler
people should be able to define what “better” means for them
in a clear
local
and understandable form
for one person
better may mean:
avoid stairs on weekday mornings
prefer shade between 10am and 3pm
avoid school zones at pickup time
for another
it may mean:
prefer routes with trees and back streets
avoid carparks after dark
bias toward quieter streets
these are small preferences
but they shape whether a route actually feels good
the important thing is that Rocky does not guess
it does not invent a hidden profile of the user
and it does not quietly optimise on their behalf
people tell Rocky what matters
and Rocky applies those preferences openly
that makes the relationship much calmer
because the map is not pretending to know better
it is simply helping someone express what they already know about themselves
this uses the same tiny shared functional language
as Reasonable.Diet
that matters because the preferences stay:
declarative
safe
local to the user unless shared
and stored on-device
the user is not managing a maze of settings
or training a mysterious assistant
they are just writing down
in a small and inspectable way
what kind of movement feels better to them
Rocky then turns those preferences into scoring functions for routes
not AI drama
not chatbot theatre
not a black box
just a clear layer
that rewrites how routes are ranked
and lets people understand why a route appeared
if a route is favoured because it has more shade
or fewer stairs
or quieter streets
that should be legible
not hidden inside a system that only outputs answers
this also means Rocky can stay modest
it does not need to speak constantly
or interrupt
or perform friendliness
it can simply sit there as a tool
helping someone gradually shape the map
until it fits their life better
in that sense
Rocky is less like an assistant with agency
and more like a small layer of programmable preference
with a friendly face
some of these preferences are cheap to apply
others require real computation
especially when they interact with:
shade
heat
lighting
time of day
or more complex route trade-offs
but that is a compute question
not a product philosophy question
the product philosophy stays the same
the user defines what better means
the system applies it clearly
and the route becomes something closer to their own judgement
than a generic verdict from above
#### Serendipity
a good map should leave room for small pleasant surprises
not because surprise is a product feature
but because local life is often richer than the shortest route suggests
most maps are built to remove uncertainty
which is often useful
but in doing so
they can also flatten the experience of moving through a place
every route becomes a corridor
and everything nearby becomes background
Serendipity is a small corrective to that
not by interrupting people
and not by trying to maximise engagement
just by occasionally noticing:
there is a quiet garden if you detour two minutes
you are walking past something happening nearby
this route is shaded for most of your walk
these are not recommendations in the aggressive sense
they are gentle observations
the map is not trying to capture attention
it is just helping the world feel a little more present
this matters because local life is often already there
people just do not notice it
a hidden garden
a small event
a nicer side street
a patch of shade
a public bench
a quiet place to pause
these things can make a place feel much more alive
but only if they surface at the right moment
not as content
but as possibility
the tone matters a lot
Serendipity should not feel gamified
or persuasive
or needy
no streaks
no points
no pressure
no “people also visited”
no manipulative framing
just simple, human-scale suggestions
that can be turned off entirely
if someone wants a pure routing tool
they should have one
if they want a map that occasionally helps them notice something nice
they should have that too
in this sense
Serendipity is not really about novelty
it is about helping people recover a slightly more local way of moving
where the world is not only a set of destinations
but also a field of small possibilities
the map does not need to make life exciting
it only needs to make it a little less flat
#### $1 per month
most of the map is free
because most of what people need can already run on-device, privately and often offline
but some kinds of routing do create real compute cost
deep personalised routing
well-lit paths at night
shade-first maps at high resolution
multi-stop errands with many constraints
and regular recomputation as new data comes in
all require more than a quick local calculation
especially when they incorporate:
time of day
heat
lighting
surface quality
errand sequencing
or shared environmental modelling
these sit in a paid layer:
$1 per month
or whatever feels like $1 where people live
the same price everywhere in emotional terms, not currency terms
##### Compute Integration
the global volunteer compute pool can run:
shade modelling at high resolution
urban heat and cool islands
incorporating global satellite data
beautiful route selection
heavy errand-sequencing tasks
these deeper jobs do not need to run from scratch for every person
they can run asynchronously on shared compute
results flow back into everyone’s maps
and are cached for reuse
that keeps the system efficient
and makes the heavier work collectively useful
rather than wastefully duplicated
on-device
short and medium routes can usually run fully offline
with privacy preserved by default
longer or more complex routes
can be sketched locally
with shared compute refining the heavier edges
this keeps the whole thing:
fast
private where possible
and deeper where useful
###### Routing and Comfort
free routing
short and medium trips
computed entirely on-device where possible
basic comfort rules still applied
the free layer should already feel complete
for ordinary daily use
the paid layer is where routing becomes deeper
not merely more
complex multi-stop errands
heat-aware and shade-first paths
night-safe walking routes
cycling with fewer cars and better surfaces
this is where the map does heavier reflective work
based on richer and more demanding prefences and environmental inputs
that also allows more detailed programmable preferences
avoid elevation above a chosen threshold
avoid steep downward slopes when raining
prefer gardens or river paths when time allows
avoid areas flagged as unsafe at night
avoid industrial shortcuts and carparks
prefer local shops instead of chains within a chosen detour
these are not different in kind
from the simpler preferences elsewhere in the app
they are just more computationally expensive
when combined with changing conditions
and the full route graph
the important thing is that the pricing stays honest
people are not paying for artificial scarcity
or for a deliberately weakened free product
they are helping cover the genuinely heavier layer
while keeping the broader map:
free
calm
privacy-safe
and widely usable
#### An Amount as a Frictionless-agree
≈ 0.5%–1% of a typical daily wage
rounded to a common small denomination.
plus market clustering
- one euro
- one pound
- one *(five halalas as the feeling)* riyal
- 10k rupiah
- 50k peso
- 10 lira
the point is not precision
it is that the amount should feel negligible
and ordinary
in the place where someone lives
this matters because one dollar a month
does not feel like ordinary software pricing
it feels more like:
a contribution
a tip
a membership
a quiet way of keeping something useful alive
that changes the relationship completely
especially when the map is already useful
and the operator is clearly non-extractive
people are not being cornered into paying
they are opting into the heavier shared layer
while the core map remains free for everyone
end state is that Maps becomes
a calm, modular, human-centred navigation system
tuned to each person,
deeply local and quietly supportive,
refined by shared compute,
offline-first and privacy-safe,
and optionally, costing about a single dollar a month, everywhere.
### Application Programming Interface
an application programming interface (commonly referred to as an API) is ...
although anyone can run the deterministic and manual datasets themselves,
most developers just want a small, boring API:
a place-and-statistics endpoint
and a map-tiles endpoint.
hexagons.world offers both.
the main aim is getting more people using hexagons
building different things
#### First use and developer experience
the first request does not require an account or key.
people can paste a curl example from the docs
and immediately see:
a hex name,
its level and location,
and a small statistics sample.
this open first request is intentional:
it shows what the system is for
without any sign-up wall,
and keeps the first-time developer experience calm and quick.
#### Free tier
each key includes a generous free allowance
on the order of 100k data requests per month.
this is enough for:
student projects,
open-source tools,
small production sites,
and modest apps.
per-request cost
a typical data request costs roughly:
about 0.000002 cents in infrastructure
(ten-millionths of a cent per call).
at that rate:
100k free requests ≈ 0.2 cents of raw cost,
and 1,000 developers each using their full free tier
≈ a couple of dollars of raw API work,
before we add any safety margin.
this means:
we can comfortably offer the free tier
to hundreds or thousands of developers,
so people can try ideas, build small tools,
and teach with the API
without the project being under financial strain.
#### hexagons/data
First, a data API. Its job is to turn coordinates, hex IDs, and place references into stable identifiers, names, geometry, and per-hex indicators. The notes already define the rough shape: point to hex, hex to point or bounding box, hex to neighbours, and hex to core indicators plus uncertainty. It should be deterministic, low-latency, human-readable JSON, and avoid hidden composite scores. It should only return place data and aggregated per-hex statistics, not broad regional modelling or heavy “what if” workloads.
hexagon to coordinates
coordinates to hexagon
statistics and uncertainty
purpose
turn “where” into:
hex IDs
human-readable names
per-hex statistics.
endpoints (shape, not syntax)
point → hex
hex → point / bbox
hex → neighbours
hex → core indicators + uncertainty.
behaviour
deterministic and cacheable
low-latency
small, human-readable JSON
no hidden composite scores.
scope
place data and aggregated per-hex statistics only.
large-area aggregations and “what if” workloads
live in the What if section,
not the core data API.
#### hexagons/tiles
purpose
serve tiles that make hexagons and indicators visible on a map.
The “best” way is not to send images, but to send instructions + data and let the client draw the map.
behaviour
pre-rendered raster tiles for most use
optional vector tiles where needed
designed to work on:
low-bandwidth links,
older phones,
e-ink devices.
scope
tiles expose:
hex boundaries,
indicator buckets,
basic labels.
precise values still come from the data API,
not from reading tiles back.
server sends:
hex IDs
styles
rules
client generates the map
Pros
extremely lightweight
aligns with your deterministic system
almost zero bandwidth for large areas
perfect for e-ink / low-power
Cons
requires custom renderer
harder to standardise
more work upfront
#### Static hexagons as a service
// apis usually having to compute live data
// hexagons is entirely static
##### Running Costs
per-request cost
individual calls are extremely cheap,
on the order of 0.000002 cents per data request.
platform cost
the real expense is the platform around them:
warm datasets and caches,
global edge access,
monitoring,
backups,
and some headroom for bursts.
we assume:
roughly a few hundred USD per month
to keep the API healthy at global scale,
budgeting around $400/month
as a comfortable target that covers:
core infrastructure,
thousands of free-tier projects,
and room for growth.
##### Authentication
anonymous access
small per-IP limits:
enough for exploration, demos, teaching, and tests.
soft rate limiting protects the API from obvious scraping and loops.
keys
one key per project.
higher, predictable limits.
clear usage graphs and email alerts when use spikes.
protections
rate limits and simple behavioural checks
to catch automated sweeps and abuse.
no invasive device fingerprinting,
just enough to keep the service healthy
while respecting privacy.
##### Pricing
usage-based
billing is metered on actual requests,
with separate meters for:
data calls,
tile requests.
calculation
each billable unit is priced as:
the measured per-request cost
plus a small markup (around 6-10%),
with that percentage decreasing at higher volumes.
result
small projects pay little or nothing.
mid-scale projects pay a few dollars a month.
heavy users pay close to raw cost at scale,
without surprises or complex tiers.
intent
the API should feel:
simple to try once,
safe to build real software on,
and boringly predictable if you're paying.
running the API is treated as:
shared infrastructure for hexagons.world itself,
for other Peaceful Foundation projects,
### What if? - Private
a general-purpose scenario tool
built on a pool of compute, standardised inputs, and deterministic hexagon layers
anyone can use it to run simulations, forecasts, or what-if scenarios
across environmental, social, economic, and operational domains
from local organisers to small businesses to universities
to explore how changes might affect real-world outcomes
an extremely adaptable resource that continues to get better
what it is
the same calm infrastructure as public What if
same hexagons, recipes, flow diagrams, and versioned methods
but inside a private workspace
where you bring your own data,
run on dedicated compute,
and keep everything compliant and explainable
why it exists
public What if is enough for many people
students, researchers, non-profits, local organisers
but some organisations:
handle private data,
need predictable turnaround,
or must show clear audit trails to funders and regulators
these groups are usually caught between:
heavy GIS stacks,
custom consultant tools,
and nothing at all
this is the middle ground:
the same calm interface,
but with your own data,
isolated compute,
and clear compliance
data and permutations
the system can import many kinds of data
geospatial, geothermal, statistical, physical, environmental, operational
much of it is sharded globally
computers that hold certain data types can run computations on what they have
this creates endless useful permutations:
satellite imagery + heat + well-being indicators,
census + local surveys + transport access,
physics simulations + land-use + building stock,
sensor networks + vacancy rates + social outcomes
we define the operations through the same small functional language
so the environment stays controlled and inspectable
we cannot predict every use
the tool becomes more versatile as more datasets intersect
if an organisation wants to contribute data to the pool
it can be made public where relevant
improving estimates for everyone
or kept private inside their workspace
this also creates another way to support the project:
useful private sequences and recipes
eventually help refine what the public layers can do
#### Elastic compute pool
all compute sources form a single shared resource layer
public compute,
private infrastructure,
volunteer nodes
workloads are scheduled across them
based on data sensitivity, job size, runtime needs, and availability
this turns globally distributed machines into a calm, elastic fabric
global datacentre capacity
high-reliability machines in managed infrastructure
used for private workloads, larger simulations, and predictable scheduled jobs
volunteer compute pool
idle machines donate capacity:
spare GPUs, gaming PCs, home servers, unused workstations
these run non-sensitive workloads, public-data simulations, and low-priority background jobs
organisations donating resources
a systems administrator runs a provisioning script or installs a small worker service
the worker reports available CPU, GPU, memory, storage, reliability, and utilisation
integrates with Xen, ESXi, Hyper-V, KVM, and container clusters
the node joins the pool
another quiet way to donate to the commons
#### Who is this for
local councils
staff who need a live map of their area,
basic indicators already prepared,
and a way to test ideas without learning full GIS
community organisations and researchers
people who collect surveys, service data, or case notes,
have a sense of "what might help",
but struggle to pull data into one place, run scenarios, and show funders clear before/after views
smaller companies and services
for example:
a plumbing company that wants to see where jobs cluster,
optimise routes,
and spot streets with repeated failures
they do not want geospatial tooling
they want a map, a few sliders, and clear outputs they can act on
##### What Organisations Get
private workspace
the same hexagons, indicator layers, recipes, and flow diagrams as the public system
but with your own datasets attached
own data
upload:
surveys and research datasets,
service usage logs,
sensor readings,
internal spreadsheets and reports,
address or point data
address and point data is automatically aggregated to hexes
with masking where needed
private datasets:
stay inside your workspace,
are never written back into the shared public indicators,
and never leave the environments you choose
shared recipes
people inside your organisation can:
share recipes and templates,
reuse standard flows,
and keep a common understanding of "how we estimate this"
flow diagrams and logic trees
every scenario still shows a simple flow diagram and logic tree
staff can see step by step:
which datasets were used,
how they were combined,
and which assumptions drove the outputs
without opening code or reading a technical specification
#### How jobs run
compute modes
for each job you choose:
run purely on your own machines,
run on a small private cluster in your cloud account,
or run on datacentre capacity we manage
private data
jobs that touch your datasets:
run only in the environments you select,
with no raw internal data ever leaving those boundaries
public-only jobs
if a scenario uses only public indicators and open datasets:
you can run it on the shared volunteer pool,
or keep it in your private environment for consistency
job sising and scheduling
each job declares:
which hexes it will touch,
which datasets it will hit,
which transforms it will apply
the system estimates:
runtime band,
compute weight,
and cost class
before you press "run"
so there are no surprises
#### Compliance and audit trail
for regulated and grant-heavy work,
What if – Private offers a clear audit trail for every scenario
you can export:
input summary
which datasets were used, what time-window or version
flow diagram + logic tree
every step from raw inputs to outputs
assumptions
parameters, thresholds, and any manual overrides
results
per-hex outputs, aggregates, and simple charts or tables
this matters when you need to:
explain results to a regulator,
show a funder what changed,
or revisit a scenario years later and re-run it under updated assumptions
to someone frustrated with ArcGIS or consultant tools,
this feels different:
you never fight the UI,
you never wonder "what did I turn on?",
you can explain results to another person,
you can say "this is what we assumed" without embarrassment,
the tool respects your intelligence
the goal is to feel like thinking with the system
not through it
#### Pricing
Workspace
$20 per month for a private workspace
plus $5 per active contributor
viewers are free
for researchers, civic hackers, NGO staff, and consultants using public and light private data
includes:
larger scenario scopes,
more active jobs,
better exports,
collaboration features
still on public or shared compute by default
unless you move into dedicated private capacity
Honey
heavy compute top-ups for private or guaranteed work
priced flat and transparently
never expire
price equals raw compute + storage + transfer + systems administration
no hidden margin
you pay for isolated, reliable compute
not for priority over public work
#### Reaching interested people
the hexagons map already has meaningful public data layers
as organisations begin exploring their own areas,
local dashboards emerge naturally
councils, research teams, and community organisations
can discover the system simply by examining their region
in many cases the first interaction is not "What if – Private"
it is just a hexagon map of their area with indicators already visible
once people begin asking "what happens if we change this?"
the What if engine becomes the natural next step