Citizen vision
The project imagines a private blockchain network of mayors, launched for the Central African Republic and portable to France. It starts from a simple conviction: the mayor, and even more the body of mayors, is the closest voice to the citizen. The ambition is to give them a modern, secure, resilient tool that extends the local “palabre” spirit to national scale.
The political heart comes before the tech: give the mayors’ body a structuring role in the law cycle, keep an immutable trace of exchanges, and organize continuity of public service in crisis. Tech bricks come after to keep the promise even when everything else falls apart.
What the network offers
- a mayors’ forum to debate and vote;
- signed votes, timestamped and verifiable;
- an immutable register of local decisions;
- a free messaging channel open to citizens.
Each brick is meant to be understandable to non-technical elected officials while staying usable by developers and network operators.
To hold during total outages, the network relies on local relays, opportunistic Wi‑Fi bubbles, and mobile “ferries” (buses, motorbikes, NGOs, volunteers) carrying encrypted packets between isolated zones. This resilience is a support, not an end: it serves governance first.
Roles, priorities and capacity
The network respects a natural priority: local elected officials and essential agents go first on the fast lane, without excluding citizens who can still speak and stay informed.
Elected officials
A few hundred responsible people (mayors, deputies, prefects, schools, health, safety) on the priority lane. Volume stays manageable even in long outages while keeping room for support teams and local technicians.
Citizens
Several hundred thousand citizens may have a phone or access point. A significant fraction can use services (messaging, local info, requests to mayors) without saturating reserved lanes thanks to opportunistic vectors and P0→P3 priorities.
This split drives design: fast lane for public decisions, wide lane for civil society, automatic arbitration (priorities, TTL, quotas) to avoid congestion.
Vectors: from most rugged to most ambitious
Each vector is a different entry point. Choose per context: total blackout, mobility, local mesh, or long-range backbone. Mayors/officials get a priority channel; citizens get a space to relay and participate.
Global naming (OBB)
- Blockchain:
OBB_MANET_Blockchain(sector 0 launched by mayors). - Vector 1 – USB/SD (air-gap): bundles on key/SD, useful in total outage. Roadmap V1
- Vector 2 – MANET geo (OBBM): opportunistic Wi‑Fi bubbles, geo-scoped manifest. Presentation · Roadmap V2
- Vector 3 – OBBHFL: K/H/S/B stations, moderate backhaul, local services. Roadmap V3
- Vector 4 – OBBHFH + OBBDW: 5 GHz long-range backbone + FPV “Dotted Way” corridors. Presentation · Roadmap V4 · Roadmap V4 bis
Quick pick: V1 (total outage), V2 (opportunistic mobility), V3 (local mesh), V4 (long range / relief / river).
What each vector offers to mayors and citizens
- Vector 1 – Mayors exchange blocks/decisions via USB/SD during councils or secure couriers; citizens drop/pick encrypted messages at town hall to inject on next trip.
- Vector 2 – Mayors/agents use phones/boxes to form temporary Wi‑Fi bubbles in markets, stations, villages; citizens keep the app running to carry “LuckyBlocks” and receive local info.
- Vector 3 – Town halls, schools, health centers are fixed hubs (K/H/S/B); citizens connect locally for news, requests, messaging even without national Internet.
- Vector 4 – Long-range antennas link capitals or cross rivers; mayors get a fast lane to sync the chain; citizens get quicker public content diffusion.
Vectors reinforce each other: a USB ferry brings blocks to a V3 station that then diffuses via V2 mobile; a V4 backbone shortens waits but V1 remains the ultimate fallback.
Resilience, opportunistic transport and priorities
To make mayoral priority real without blocking citizens, exchanges are organized by service class and geography. Traffic keeps flowing in pieces via human ferries and fixed stations.
Bundles & priorities (P0→P3)
- P0: alerts (TTL 7 days, max hops 10).
- P1: important discussions (TTL 30 days, max hops 6).
- P2: chatter/history (TTL 90 days, max hops 4).
- P3: local archives (TTL 180 days, max hops 2).
During a connection: exchange link capacity, summaries (blocks/forum), build the bundle list to push by priority + scope + quotas.
To do Define bundle manifest format (hash, size, scope, TTL, class).
Geo-scoped packets (“Lucky Blocks”) / Opportunistic ferry
Opportunistic bundle transport via fixed hubs and mobile carriers (bus, train, car, phones/S boxes) to cross no-network zones.
- Gzip+base64 bundles with enriched manifest (destinations, priorities P0..P3, hashes, TTL).
- Export/import via API and admin UI (Bundles section) + carrier script (Termux/laptop) as “USB on legs”.
- ACK for purge, TTL time + hops to avoid saturation.
- Citizen participation: local Wi‑Fi sharing, encrypted ephemeral storage, declared destination under ephemeral pseudonym.
- Privacy-first carrier mode: a carrier opens nothing, only pushes from its encrypted outbox, shares no personal data; validity = ID accepted by the chain (verifiable on a mayor’s request). Personal send/receive and carrying can be separate (carry without reading).
- Opportunistic routing: if final destination isn’t on the path, pick a nearby K hub (station/bus) or a friendly proxy; the manifest can be enriched manually to force a geo regroup before next hop.
- To do Detailed map UI:
- OSM/offline map, toggles: S bubbles (mobile), K bubbles (fixed), H cones (directional), M3/M5 backhaul links.
- Radio view: bubbles with opacity = SNR/confidence, directional cones (10–30°), range 10–15 km, backhaul thin lines.
- Routes/transport: colored polylines bus/train/road, thickness = estimated traffic, average ETA per segment, favorite paths imposed by operator.
- Bundles (public): clear manifest (scope, priority, TTL, hash/size), non-confidential tracking of hubs crossed, option “force route via Kx”.
- Hub sheet: approx coords, range, known backhauls, inbox/outbox stock, Internet link status if present.
- Visuals: current palette, light animations (bubble pulse, cone gradient), fixed legend.
- Data needed: approx positions K/H, antenna angle/power, S/K/H ranges, backhaul inventory, estimated road traffic, outbox/inbox stats.
This closes the loop: decisions on the blockchain go down to villages via V2/V3, while citizen feedback slowly climbs back to town halls even without national network.
Local blockchain (mayors’ network)
The local chain is the spine of exchanges. It stays simple to maintain while ensuring legitimacy and traceability of decisions.
What the chain does
- Append-only ledger: identities (mayors, communes, boxes), official events, citizen acts, revocations.
- Signed transactions (ed25519), grouped in blocks, USB-transportable.
- Proof-of-Authority consensus (a few dozen validators).
What the chain does not do
- No token/cryptocurrency, no complex smart contracts.
- No chat stored on-chain (hash/meta only if needed).
Roles
- Validators: town halls/K relays, produce blocks and keep full copy.
- Observers: read-only, redundancy.
- Light clients: S/H boxes, phones/tablets.
Genesis / sector 0 (IDs & quorum)
- Legitimate start: at least ~50% of mayors identified and co-signing genesis to launch.
- Initial list: first blocks reserve IDs for mayors (and optionally prefects/essentials); IDs activated by vote of present mayors.
- Uniqueness: 1 citizen ID per person (aliases possible but tied to the same validated identity). No double registration.
- Intronization rite: at the initial assembly, a “DEVICE-4” (system maintenance) displays a unique temporary token (short phrase, 10 s) for each mayor → immediate login + national intro message (ID, country/region/commune, name, function).
- ID ≠ box: the ID is carried by the key/tokens; you can use an S box, mobile, RPi or simple device (LCD + joystick) as long as it signs and exchanges bundles.
- Responsible traceability: confidentiality outward, but each ID can be verified/revoked by a mayor; no full anonymity inside the network for ID existence, but content remains untraceable.
- Citizen onboarding: after mayors’ intronization, citizens request an ID at town hall (with ID doc); aliases allowed for non-voting use but always tied to the real ID.
- Volunteer carriers: mobile carriers help transport but don’t create IDs; they only relay encrypted bundles.
- Periodic roundtable: distributed checkpoints/archives to verify chain integrity and avoid wild forks.
Identities & keys
- ed25519 (secure private key, public key on-chain).
- ID_MAYOR, ID_COMMUNE/ID_VILLAGE, ID_BOX generated at install.
- To do Specify private key storage (light HSM / encrypted file).
Formats
- Signed JSON transactions (COSE/CBOR possible), compressed.
- Blocks
{id, prev_hash, ts, txs[], signatures}, append-only. - To do Define metadata TTL for off-chain purge.
Lab prototypes and code to structure
Before large deployment, a simple bench can validate block flow, bundles, and resilience under simulated cuts.
Lab prototypes (3 laptops + 2 ESP32 + mobile phone)
- Laptop 1: central node (admin, chain collection).
- Laptop 2: Relay K – Commune A (API, connects ESP32_A).
- Laptop 3: Relay K – Commune B (API, inter-commune sync).
- ESP32_A/B: S boxes for each commune.
To do Firewall scripts to simulate backhaul cut A↔Central / B↔Central.
To do USB copy script simulation (export/import blocks between laptops).
Code tree / repos by station
devices/station-S/– ESP32 S firmware (captive portal, API, µSD).devices/station-H/– S + directional antenna mgmt + chain sync.devices/station-K/– OpenWRT scripts + sync agent + storage.devices/backhaul-C/– point-to-point configs, link quality, quotas.devices/maire-terminal/– tablet app (signatures, forum, votes).backend/obambu_node/– FastAPI + chain + sync API.docs/– diagrams, procedures, BOM.
To do Create these folders and drop READMEs per station.