For Developers: Architecture, Security & Open-Access Policy
Comprehensive technical documentation explaining our open disaster data governance, real-time edit/delete rationale, offline-first sync engine, and enterprise security framework.
Why Are Content Editing & Deletion Openly Accessible?
Disaster Response Open Data Protocol & The Right to Erasure1. Zero-Friction Emergency Response
In active disaster zones (Rasuwa, Nuwakot, Melamchi), cell towers are intermittent and field personnel change every few hours. Requiring rigid bureaucratic authentication or administrative approval to correct a child's misspelled name or hospital ward number causes fatal search delays.
2. Rapid Decentralized Data Hygiene
Crowdsourced missing reports submitted during panic often contain initial errors (wrong clothing description, outdated landmark). Allowing immediate inline updates empowers ground volunteers to refine records in real-time as search dogs and drone operators uncover fresh coordinates.
3. The Humanitarian Right to Erasure
In compliance with humanitarian data conventions, once a missing individual is safely reunited, families have the unconditional legal and ethical right to permanently erase their contact numbers, photos, and medical notes from public view without waiting for system administrators.
4. Post-Disaster Factory Wipe Protocol
Once flood waters recede and government relief operations conclude, the Admin Mission Control possesses master purge tools to execute an irrevocable database wipe and disk vacuum, preventing vulnerable citizen data from lingering on servers indefinitely.
Enterprise Security & Resilient Architecture
Defense-in-depth, zero injection vectors, and strict headers🔒 1. Parameterized SQL Defense
Every database interaction uses prepared statements with strictly typed bind parameters (`@caseId`, `@fullName`, etc.) via `better-sqlite3`. SQL injection attack surfaces are mathematically zero.
db.prepare('SELECT * FROM cases WHERE caseId = ?').get(caseId);🛡️ 2. Production Security Headers
Configured with strict Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options `nosniff`, and Referrer-Policy `strict-origin-when-cross-origin`.
Strict-Transport-Security: max-age=63072000; preload⚡ 3. Offline-First IndexedDB Sync
When users report a missing person with zero internet connectivity, records are encrypted and stored in client-side IndexedDB queues, auto-flushing to `/api/sync` immediately upon connection restoration.
POST /api/sync → processOfflineBatch() → 200 OK☁️ 4. Serverless & Vercel Storage
The storage engine adapts automatically to serverless runtime environments (using `/tmp` writable cache fallback on Vercel Edge/Lambdas) with pluggable support for distributed LibSQL / Turso databases.
const DB_DIR = isVercel ? '/tmp/data' : './data';REST API Endpoints Reference
| Method | Endpoint | Description | Payload / Parameters |
|---|---|---|---|
| GET | /api/cases | Fetch public published missing & found cases | `?status=...&district=...&q=...` |
| POST | /api/cases | Create a missing or found report | `{ fullName, districtId, ... }` |
| GET | /api/community | Retrieve community discussions and citizen replies | None |
| DELETE | /api/community | Permanently delete a post or comment | `?postId=...` or `?commentId=...` |
| GET | /api/gallery | Retrieve verified disaster field photos | None |
| DELETE | /api/gallery | Permanently remove photo from archive | `?id=...` |
| POST | /api/admin/cases | Bulk delete or Hard Purge All Data | `{ action: "hard_purge_all" }` |