Stayd

Een cross-platform app gebouwd met Expo en React Native, met daarnaast een Progressive Web App-variant via PWA-technologie voor distributie via Outpost-nodes zelf.

Waarom deze keuze nu: één codebase voor iOS, Android en web. Geen App Store nodig voor de PWA-variant (cruciaal in een crisis als App Stores ontoegankelijk zijn). De PWA kan via Outpost-WiFi verspreid worden zonder internet.

• Native apps per platform (Swift voor iOS, Kotlin voor Android): meer ontwikkel-tijd, betere prestaties, maar voor een sociale app met vooral tekstberichten geen meetbaar voordeel.
• Flutter: vergelijkbare cross-platform aanpak, maar de community en het PWA-pad zijn in React Native sterker uitgebouwd.
• Alleen PWA, geen native: simpeler, maar in normale tijden voelen App Store-installaties voor veel gebruikers vertrouwder.

Bij installatie en eerste opzet van Stayd genereert de app een paar dingen die later belangrijk worden:

• Een cryptografische identiteit (een sleutelpaar onder de motorkap). De gebruiker hoeft daar niets technisch van te weten; het is wat hem in het netwerk uniek maakt.
• Een herstel-passphrase of twaalf-woorden herstelzin (zoals Bitcoin-wallets gebruiken). Te bewaren op een veilige plek, bijvoorbeeld geprint en in een lade. Nodig om in te loggen op een ander apparaat als de oorspronkelijke telefoon kapot is.
• Een papieren Stayd-kaart ter grootte van een pinpas, bedoeld voor de portemonnee. Voorkant: naam, eventueel levensreddende info (bloedgroep, ernstige allergie), QR-code met de publieke sleutel. Achterkant: ruimte voor handgeschreven noodtokens (zie verderop) en de herstel-passphrase als noodgeheugensteun. De kaart wordt aan het eind van de eerste opzet automatisch gegenereerd als PDF die de gebruiker kan printen of laten printen bij de gemeente of een wijkpost.

Deze drie samen vormen het minimum dat een gebruiker buiten zijn telefoon bij zich heeft, voor het geval dat telefoon onbruikbaar wordt.

Voor de eerste pilot lijken boards met een LoRa-radio en geïntegreerde WiFi/Bluetooth een natuurlijke startkeuze. Voorbeelden: RAK Wireless WisGate Connect of vergelijkbaar, Heltec-boards, of een Raspberry Pi-gebaseerde build voor de krachtigere primaire nodes.

Twee niveaus van nodes:

• Primaire nodes (1-2 per wijk): op gebouwen met bestaande noodstroom. Grotere accu (200-300 Ah), signaallamp, geluidsmelder, USB-laadpunten voor bewoners.
• Secundaire nodes (3-5 per wijk): op gewone publieke locaties. Kleinere accu plus zonnepaneel (richting 7 dagen autonomie in cyclische modus).

• Eigen hardware-ontwerp vanaf nul: meer flexibiliteit, maar hoge engineering-kosten en lange doorlooptijd. Voor een pilot niet nodig.
• Bestaande Meshtastic-knooppunten gebruiken zonder modificatie: snelste start, maar zonder de lokale WiFi-toegang die voor gewone burgers nodig is.
• Alleen WiFi-mesh tussen verzamelpunten (geen LoRa): goedkoper, maar WiFi-bereik is te kort voor wijken zonder line-of-sight.

Een satelliet-terminal op elke Outpost zou technisch werken: ook bij volledige uitval van internet en mobiel via reguliere paden kan zo'n terminal verbinding maken met een satelliet-netwerk. Toch is het bewust niet de hoofdroute van Stayd. Vier redenen:

• Afhankelijkheid van een commercieel bedrijf in een ander land. Starlink wordt beheerd door SpaceX, een Amerikaans bedrijf. De dienst kan vanuit één centrale plek worden gestopt, gefilterd of opnieuw geprijsd. In Oekraïne is dit in 2022 en daarna in praktijk gebleken. Voor Nederlandse crisis-infrastructuur is afhankelijkheid van een externe commerciële partij een ontwerpfout, geen detail.
• Geen open spec, geen onafhankelijke audit mogelijk. Het protocol, de versleuteling tussen terminal en satelliet, en de software op de terminal zijn dichte broncode. Niet te controleren, niet te repareren door derden, niet te vervangen.
• Kosten en onderhoud per Outpost. Een terminal kost enkele honderden euro's plus een maandelijks abonnement. Schaalbaar naar tientallen wijken in een regio betekent serieuze structurele lasten die per locatie betaald moeten worden.
• Eén punt van mogelijke uitval voor het hele netwerk. Een LoRa-mesh tussen Outpost-nodes blijft lokaal werken zolang er ergens nodes draaien: zelfs afgezonderde "eilandjes" in de mesh blijven onderling berichten uitwisselen als een deel van het netwerk uitvalt of de verbinding tussen wijken verstoord raakt. Een uniforme afhankelijkheid van Starlink draait dat principe om: valt Starlink ergens uit, dan valt het overal tegelijk uit.

Dat betekent niet dat satelliet-verbinding geen rol kan spelen. In een hybride opstelling kan één Outpost in een wijk via een satelliet-uplink fungeren als brug naar buiten de regio, naast LoRa-mesh op wijk-niveau. Optioneel, niet structureel.

Reticulum is een transport-agnostische crypto-stack die over verschillende media kan draaien (LoRa, internet, serieel). Voordelen: end-to-end versleuteling is ingebouwd, routing is decentraal via announces, en de stack is ontworpen voor lage-bandbreedte en hoge-latency-netwerken.

Het Outpost-netwerk zou Reticulum gebruiken als bovenliggende crypto-laag, met een LoRa-mesh-protocol als transport eronder. Implementaties zoals MeshCore en Meshtastic zijn bruikbaar als technische basis, maar het Outpost-netwerk draait op een eigen, voor crisis-doeleinden gereserveerde frequentieband, gescheiden van het bestaande MeshCore- of Meshtastic-netwerk. Dat voorkomt interferentie en houdt de capaciteit beschikbaar voor noodverkeer.

DARES onderzoekt LoRa-mesh officieel voor noodcommunicatie en is daarmee een waardevolle inhoudelijke partner, ook al draait Outpost op een eigen band. Internationaal vergelijkbaar werk gebeurt rond LXMF en RFC 9171 (Bundle Protocol) voor delay-tolerant networking.

• Alleen Meshtastic: een grote internationale gemeenschap (meshtastic.org), goed gedocumenteerd. Nadeel: minder verfijnde cryptografie en routing dan Reticulum, en geen ingebouwde delay-tolerant aanpak voor offline ontvangers.
• LoRaWAN (LoRa Alliance): een industriestandaard, maar ontworpen voor sensor-data naar een centrale gateway, niet voor peer-to-peer mesh tussen burgers.
• Eigen protocol vanaf nul: vermijdt vendor-keuzes, maar verspilt jaren werk voor iets dat al bestaat.
• Bluetooth Mesh of WiFi-Direct: te kort bereik voor wijk-niveau.

Elke gebruiker heeft een home_station: het verzamelpunt in zijn eigen wijk. Dat dient als hint voor de eerste route. Tegelijk leert het mesh-protocol decentraal waar gebruikers recent gezien zijn (via "announces"). Daardoor kan iemand ook bereikt worden via een andere Outpost dan zijn home_station, bijvoorbeeld als hij op werk is in een andere wijk. Vergelijkbaar met hoe GSM met "home" en "visitor" registraties werkt.

Announces hebben een korte levensduur (6-24 uur). Daarmee onthoudt het netwerk recente bewegingen kort, en vergeet oude vanzelf. Geen privacy-archief, geen geheugen-stapeling.

Vier statussen worden zichtbaar gemaakt:

• Verzonden: de eigen Outpost-node heeft het bericht geaccepteerd.
• Klaar voor afhalen: het bericht is bij de Outpost in de wijk van de ontvanger aangekomen en wacht daar.
• Afgeleverd: het apparaat van de ontvanger heeft het opgehaald.
• Gelezen: optioneel, default uit.

Bij een druk netwerk worden de bevestigingen geleidelijk teruggeschroefd om bandbreedte te besparen. Bij heel drukke momenten alleen nog "verzonden".

Een contact toevoegen gaat via een fysieke handeling: een QR-code scannen van een apparaat dat je in handen hebt. Daarmee is het contact "in persoon bevestigd". Hulpverleners (huisarts, EHBO) worden geverifieerd via een institutionele certificate authority (CA): een overheidsinstantie (lokaal of landelijk) ondertekent hun sleutels op basis van een BIG-register-check, zodat de app weet dat het echt de huisarts is.

Voor officiële berichten van gemeente of veiligheidsregio bestaat een hiërarchie: een landelijke CA tekent regionale CA's, regionale CA's tekenen gemeentelijke. Daarmee kan een burger zien dat een waarschuwing echt van zijn eigen gemeente komt.

Vier mechanismen samen beschermen de "sociale grafiek" (wie kent wie):

• Sealed sender (zoals Signal dat heeft): een tussenliggende server ziet alleen aan wie een bericht gaat, niet wie het stuurt.
• Encrypted backups als ondoorzichtige blokken, met vaste grootte. Geen wijzigings-deltas die het systeem zou kunnen analyseren.
• Geen account-gekoppelde gegevens: geen e-mail, geen telefoonnummer, geen naam in de Stayd-backend. Alleen de cryptografische sleutels.
• Status zoals "online" of "laatst actief" wordt niet door de Stayd-backend bijgehouden. Apparaten signaleren dat alleen direct in hun lokale mesh-netwerk, voor de korte duur dat het nuttig is.

In een crisis-context ziet een Outpost-node natuurlijk wel routing-metadata: welke pubkey heeft een bericht gestuurd naar welke andere pubkey, op welk tijdstip. Dat is onvermijdelijk om berichten af te kunnen leveren. Pubkeys zijn echter pseudoniem en niet direct gekoppeld aan persoonsgegevens.

Voorlopige richting (cijfers zijn schattingen):

• Op netstroom of accu boven 80%: alles altijd aan.
• Accu 50-80%: WiFi cyclisch (bv. 10 min aan per half uur), of via knop voor on-demand activatie.
• Accu 20-50%: WiFi minder vaak aan, signaallamp toont wanneer een bewoner WiFi kan activeren.
• Onder 20%: WiFi alleen via knop, LoRa-radio blijft luisteren.
• Onder 5%: alleen LoRa, geen WiFi meer.

Een externe knop met een gekleurde lamp (rood/groen) maakt voor de bewoner zichtbaar of er een venster is om de WiFi te gebruiken. Past bij hoe verzamelpunten in een crisis ook fysiek voelbaar moeten zijn.

Een Outpost-node hangt op een buurthuis, een school, een kerk. Het moet er passend uitzien (niet als een rare techniek-kast), bestand zijn tegen weer en vandalisme, en eenvoudig te onderhouden. Industrieel ontwerp en antenne-keuze zijn open vraagstukken voor de pilot.

Een Outpost kan een of meerdere USB-laadpoorten hebben. Vijf tot tien minuten laden geeft een gemiddelde telefoon weer genoeg accu om de Stayd-app rustig te gebruiken: een paar berichten lezen, beantwoorden, statusje sturen. De gebruiker doet alles op zijn eigen apparaat. Geen externe sleutels, geen tijdelijke proxy, privacy blijft volledig intact.

Voor de meeste mensen lost dit het hele probleem op. De Outpost wordt daardoor ook een natuurlijk samenkomstpunt in een crisis, wat past bij de sociale laag waar Stayd op leunt.

Power-management is hier kritiek: de Outpost mag nooit zijn kerntaak verliezen door teveel telefoons te laden. Drie mechanismen samen: een harde sessielimiet (bijvoorbeeld vijf minuten, daarna gaat de poort uit tot de kabel wordt losgekoppeld en opnieuw aangesloten), een automatische cutoff zodra de Outpost-accu onder bijvoorbeeld dertig procent zakt, en een zichtbare countdown-LED bij elke poort zodat iedereen ziet hoeveel tijd er nog is. De LED geeft tegelijk een sociaal signaal aan wachtenden: er komt zo plek vrij.

De Stayd-app ondersteunt meerdere accounts op één toestel. Voor de noodsituatie betekent dat: als het apparaat van iemand totaal onbruikbaar is (gevallen, gestolen, oplaadpoort kapot), kan diegene een gast-sessie openen op de telefoon van een naaste contact in de buurt, een familielid bij de Outpost, of een wijkbewoner die ook Stayd gebruikt.

Inloggen gebeurt met de herstel-passphrase of twaalf-woorden herstelzin die bij eerste opzet zijn aangemaakt (zie "Wat de gebruiker krijgt bij eerste opzet" hierboven). De app downloadt de versleutelde sleutel-backup uit de Stayd-backend en ontsleutelt die lokaal voor de duur van de sessie. Na uitloggen wordt alle ontsleutelde materiaal weer gewist. De host-telefoon ziet niets na afloop.

Deze laag vereist niet per se dat de versleutelde sleutel-backup bereikbaar is. Zelfs zonder toegang tot de backup blijft de gast-sessie nuttig: uit de herstelzin kan de app lokaal de cryptografische identiteit reconstrueren, dus de gast is direct bereikbaar voor nieuwe berichten. Alleen zijn eerder ontvangen berichten die in de backup zaten blijven ontoegankelijk tot de backup weer beschikbaar is. Voor de backup zelf is een werkend pad nodig: internet via mobiel, een ongekoppelde WiFi, of een Outpost met satelliet-uplink, of een eerder gecachte versie op de host-telefoon.

Trade-off: de gebruiker moet zijn herstel-passphrase of woordenzin paraat hebben. Wie die nooit heeft opgeslagen of vergeten is, kan deze laag niet gebruiken en valt terug op laag 3. Daarnaast is er een afhankelijkheid van vertrouwen in de host-telefoon. Voor uitzonderlijke situaties acceptabel, voor structureel gebruik niet bedoeld.

Bij de eerste opzet van Stayd genereert de app een paar kleine noodtokens, bedoeld om op de fysieke Stayd-kaart in de portemonnee geschreven te worden. Elk token is een kort, alfanumeriek codewoord in vier groepen van vier tekens, vooraf ondertekend door de private sleutel:

STAY-A3B7-9KMD-2NQX

Door de teken-set zonder verwarrende karakters (geen 0/O of 1/I) en een ingebouwde checksum kan de Stayd-app van een ander aanwezig persoon verkeerd overgeschreven codes meteen herkennen en aangeven welk teken niet klopt.

Elk token autoriseert één specifieke beperkte actie: "ik ben hier", "alles in orde", of "ik heb hulp nodig". Eenmaal gebruikt is het token op. Vervaldatum van bijvoorbeeld twee jaar, met een herinnering in de app om ze bij een wijk-oefening te vernieuwen.

Een noodtoken wordt niet rechtstreeks bij een Outpost ingevoerd (Outposts hebben geen scherm of toetsenbord). De gebruiker geeft de code op aan iemand anders bij het verzamelpunt met een werkende Stayd-app: een buurman, een familielid of een andere medeburger die ook gekomen is. Die persoon typt de code in zijn eigen Stayd-app; de app verifieert de handtekening, stuurt de actie via het mesh-netwerk, en markeert het token als gebruikt. De ander ziet niet welke actie aan het token gekoppeld is dan wat hij invoert.

Lees-toegang is niet mogelijk via noodtokens. Een token kan ondertekenen maar niet ontsleutelen, en de private sleutel is precies wat ontbreekt. Voor de meeste situaties is dat acceptabel: status sturen lost al heel veel op (familie weet dat je veilig bent), lezen kan wachten tot de telefoon weer werkt of er een gast-sessie via laag 2 mogelijk is.

Niet iedereen kan in een crisis naar het verzamelpunt lopen: kwetsbare ouderen, mensen die slecht ter been zijn, bewoners aan de rand van het bereik. Voor hen biedt Stayd twee aanvullende routes.

Meerdere accounts op één telefoon. Wie zelf niet kan komen, kan zijn account tijdelijk laten toevoegen aan de Stayd-app van een buurman of mantelzorger die wel naar de Outpost kan lopen. De Stayd-app ondersteunt meerdere accounts naast elkaar, elk afgeschermd met een eigen PIN of biometrie. Wanneer de drager bij de Outpost komt, haalt de app berichten op voor álle accounts die op die telefoon staan, niet alleen het eigen. Bij thuiskomst logt de oorspronkelijke eigenaar in op zijn eigen account op die telefoon en leest zijn eigen berichten. De drager heeft geen inzage in de inhoud van andermans account.

Berichten meedragen naar het eigen apparaat van de ander. Een variant waarbij de helpende persoon de versleutelde berichten van de Outpost ophaalt en thuis bij de ontvanger via een korte lokale verbinding (Stayd-app naar Stayd-app over hetzelfde WiFi) overzet naar diens eigen telefoon. De berichten blijven onderweg versleuteld voor de uiteindelijke ontvanger, dus de helpende persoon ziet de inhoud niet. De controle blijft bij de eigenaar van het account.

Walking Outpost via QR-codes. Voor mensen in een erg afgelegen dorp of bij een groep huizen in het buitengebied, ver van enige Outpost, kan een vrijwilliger bij de dichtstbijzijnde Outpost een kopie ophalen van alle versleutelde berichten die daar tijdelijk zijn opgeslagen, en die kopie in zijn Stayd-app meedragen naar zijn dorp. Hij kan zelf alleen de berichten lezen die aan hem zijn geadresseerd; de rest blijft versleuteld. Komt hij iemand tegen die ook iets verwacht, dan toont die persoon een QR-code met zijn pubkey, en de app van de vrijwilliger levert in één of enkele QR-codes precies de berichten voor die persoon. Geen extra hardware, geen extra netwerk, alleen het scherm en de camera van twee telefoons.

Een derde aanpak, telefoons die via Bluetooth of WiFi-Direct automatisch berichten aan elkaar doorgeven (zoals Briar doet), is niet gekozen wegens hoge batterij-belasting en restricties die iOS en Android op achtergrondprocessen zetten.

Als internet en de mobiele netwerken langere tijd uitvallen, is ook de Google Play Store en de Apple App Store niet meer bereikbaar. Mensen die op dat moment de Stayd-app nog niet hebben, kunnen die dan niet meer langs de gebruikelijke route downloaden. Stayd zet daarom in op één primaire route, met één aanvulling voor wie meer OS-integratie wil.

Primaire route: Stayd als Progressive Web App (PWA). De Stayd-app is ook beschikbaar als webpagina die werkt zoals een geïnstalleerde app: te openen in een browser, op te slaan op het startscherm, en daarna offline werkbaar. De PWA wordt gehost op elke Outpost zelf en is bereikbaar via de Outpost-WiFi. Wie binnen bereik komt kan de pagina ophalen en meteen gebruiken, zonder ooit langs een app store te gaan. Sleutels en berichten worden lokaal opgeslagen (Web Crypto API plus persistente browser-opslag), dezelfde privacy-eigenschappen als de native versie.

Verbinden met het Outpost-WiFi gaat via een fysiek bordje bij de Outpost met een QR-code in het standaard WiFi-formaat. De gewone camera-app van iOS of Android herkent die en stelt vanzelf voor om te verbinden. Daarna onthoudt de telefoon het netwerk en verbindt in het vervolg automatisch zodra die binnen bereik is. Geen extra installatie nodig voor deze stap.

Native apps in de app stores als opt-in. Voor wie meer OS-integratie wil (achtergrond-notificaties, ruimere offline werking, vlottere prestaties) is er ook een Android- en iOS-versie via de reguliere stores. Vereist installatie vooraf, werkt in normale tijden net wat soepeler.

Hoe goed dit in praktijk werkt voor verschillende Android- en iOS-versies, en welke OS-restricties hier in de weg gaan zitten, is een open vraag die zich uitstekend leent voor verder onderzoek: hoe verspreid en gebruik je in een crisis-situatie een Stayd-achtige app op beide platforms? Een denkbare uitbreiding daarbinnen: kan de native versie van Stayd via een eigen WiFi-hotspot de PWA serveren aan andere telefoons in de buurt, zodat lokale distributie ook werkt zonder Outpost?

De app draait niet permanent op de achtergrond. Wie bericht wil, opent de app actief. Dat scheelt batterij, vermijdt de complexiteit van push-notificaties (die in een crisis sowieso niet werken), en past bij de bewuste-schaarste-cultuur die het systeem nodig heeft. In normale tijden kunnen wel Web Push-meldingen worden ontvangen, gemaximeerd op 1-2 per maand.

Stel de eerste veldproef wijst uit: het LoRa-bereik door bebouwing is te beperkt of de doorvoer is te laag voor zinvolle wijk-communicatie. Wat blijft over?

De combinatie van app plus lokale infrastructuur blijft het ontwerp. Alleen de radio-technologie verandert. Er zijn alternatieve routes beschikbaar (andere frequentiebanden, samenwerking met radioamateurs, of hybride opstellingen waar één Outpost via een ander pad nog wel internet heeft) die werken waar LoRa tekortschiet. Welke radio-laag de Outposts vullen is een ontwerpkeuze, niet een principe. Wat niet verandert: er staat hardware in de buurt die los van het reguliere internet kan werken.

Stel Reticulum blijkt te veel overhead te hebben voor de beperkte LoRa-doorvoer, of de announces schalen niet naar wijk-niveau. Wat blijft over?

• De cryptografische laag (end-to-end versleuteling, sealed sender, lokaal-first ontwerp) staat los van de mesh-onderlaag en blijft intact. Wat verandert is de routing-laag.
• Voor de routing kan gekozen worden voor een eenvoudiger protocol zoals een aangepaste Meshtastic-variant, of voor een minimaal eigen protocol dat specifiek voor de Outpost-band is ontworpen. Beide draaien nog steeds op de eigen crisis-band, gescheiden van bestaande netwerken.

Verlies: minder verfijnde routing en identiteits-beheer dan Reticulum biedt. Winst: minder afhankelijkheid van één specifieke stack.

Stel een Outpost komt na 2 of 3 dagen zonder zon stil te liggen. Wat blijft over?

• Een dichter netwerk van Outposts (minder afstand per hop, dus minder vermogen per zending) compenseert deels.
• Outposts kunnen geplaatst worden op gebouwen die zelf al noodstroom hebben (verpleeghuizen, ziekenhuizen, sommige buurthuizen met aggregaat). Dat verkleint de eis op de Outpost-accu.
• De claim wordt opgegeven van "werkt 7 dagen door" naar "werkt 2 tot 3 dagen door, daarna afhankelijk van noodstroom-infrastructuur". Nog steeds nuttiger dan nul, en past bij hoe veel publieke gebouwen al gefaseerd zijn opgezet: enkele uren via interne accu, langer via aggregaat of via een externe stroomvoorziening.