Sender layer
Banks, government, utilities, and courts sign and send certified documents
- Institution signing keys (KMS/HSM)
- eMbox Certified Send API
- Sender verification & enrollment
- Webhook receipts on secured/retrieved
← Back to home
Engineering
How eMbox is built
System architecture, phased roadmap, and buildability assessment — for investors, partners, and engineers evaluating the platform.
System architecture
Four layers: senders sign and send, cloud routes and logs, home vault secures at the address, phone retrieves and reads privately.
Cloud platform
Routes deliveries, maintains chain-of-custody, binds payloads to addresses
- Delivery router & address registry
- Append-only chain-of-custody ledger
- Encrypted blob storage (R2/S3)
- Device registration & pairing
Home vault device
Secures payloads at the physical address with glance-only outdoor UI
- Encrypted vault (secure element)
- Glance-only e-ink/status display
- Retrieve gate (NFC / BLE / biometric)
- Tamper detection & key zeroization
Phone app
Retrieve, read privately, export delivery proof
- Device pairing & retrieve handshake
- Decrypted document viewer
- Affidavit / delivery receipt export
- Household profiles & notifications
Core protocol (P0)
Digital address token
Signed struct binding device ID, street address hash, geo bounds, payload hash, and sender certificate — rejected if any link in the chain fails.
Payload encryption
AES-256-GCM content encryption with key wrapped to device public key (X25519). Document body never available to outdoor display layer.
Chain-of-custody
Append-only ledger: SENT → ROUTED → SECURED → RETRIEVED → READ. Each hop signed and timestamped.
Glance-only rule
Outdoor UI receives metadata only: sender glyph, category, urgency, count. Firmware-enforced — no document titles, amounts, or account numbers.
Retrieve handshake
Phone presents signed challenge at the delivery anchor. Device verifies pairing and releases wrapped decryption key. Retrieve = legally meaningful delivery event.
Sender allowlist
Cloud and device reject payloads without valid institution signature. Unknown senders never get outdoor display priority.
Phased build plan
Software MVP first (device simulator), then sender API, then hardware port.
| Phase | Scope | Timeline | Exit criteria |
|---|---|---|---|
| 0 Foundation | Monorepo, protocol schemas, crypto packages (address token, encrypt/sign, ledger) | Week 1 | Offline payload generation and verification passes all unit tests |
| 1 Cloud API | Cloudflare Workers + D1: device registration, delivery routing, ledger events | Weeks 2–3 | Register device, inject delivery, see full ledger trail via API |
| 2 Device simulator | Node.js vault simulator + glance-only web dashboard + retrieve mock | Weeks 3–4 | End-to-end: send → secure → glance update → retrieve |
| 3 Phone app | Expo PWA: pair, retrieve, read documents, export affidavit | Weeks 4–6 | User reads document on phone with delivery receipt timestamps |
| 4 Sender API | Certified Send API, TypeScript SDK, sender portal, webhooks | Weeks 6–8 | Third party sends via SDK; webhooks fire on secured + retrieved |
| 5 Household & security | Multi-tenant vaults, capability tokens, statutory classifier, duress PIN | Weeks 8–10 | Two household members with isolated vaults; delegated retrieve works |
| 6 Hardware | ESP32/Pi firmware, e-ink display, NFC/BLE, secure element, enclosure | Future | Production prototype with same protocol as software simulator |
Tech stack
| Layer | Choice | Why |
|---|---|---|
| Monorepo | Turborepo + pnpm | Shared TypeScript types across device, cloud, and phone |
| Cloud | Cloudflare Workers + D1 + R2 | Edge latency; matches existing Pages deployment |
| Device sim | Node.js 20 | Same language as cloud; fast iteration before hardware |
| Phone | Expo (React Native) | One codebase for web PWA and iOS/Android |
| Crypto | @noble/curves, @noble/ciphers | Auditable, Workers-compatible Ed25519/X25519 + AES-GCM |
| Schemas | Zod | Runtime validation with TypeScript inference |
| Sender SDK | OpenAPI + TypeScript SDK | Standard B2B onboarding for institutions |
Buildability assessment
Yes — the core technology is buildable.
All P0 patent claims (address-bound vault, encrypted delivery, glance-only UI, retrieve protocol, sender trust) are implementable with known software patterns and existing hardware components. Nothing requires breakthrough science.
- Legal delivery equivalence is a legal outcome supported by technology — get legal review before production marketing claims.
- Hardware adds 6–12 months after a software MVP proves the protocol.
- Sender adoption (banks, IRS) is primarily a partnership challenge, not an engineering blocker.
- External security audit required before production — architecture is sound; implementation must be verified.
We can demo the full delivery flow in software within 8–10 weeks. Hardware prototype follows. Legal and sender partnerships run in parallel.
Cloud delivery API & routing
Standard REST/Workers patterns — same family as DocuSign webhooks or package tracking APIs
End-to-end encryption
AES-GCM + X25519 with mature audited libraries
Address-bound tokens & chain-of-custody
Signed structs + append-only event log — well-understood patterns
Glance-only outdoor UI logic
Enforceable rule: outdoor layer gets metadata only, never decryptable body
Phone retrieve app
Standard mobile development with Expo/React Native
Device simulator (pre-hardware)
Node.js vault + web dashboard proves full protocol before custom hardware
Sender SDK & webhooks
Standard B2B API design
Secure element integration
ATECC608 / TPM chips available; needs embedded firmware expertise
NFC / BLE retrieve at door
Phone hardware is standard; custom pairing/proximity protocol is the work
E-ink outdoor display
Off-the-shelf modules exist; driver + glance UI integration required
Custom IP65 enclosure
Mechanical and electrical engineering — not pure software
Statutory notice classifier
Rules engine is software; jurisdiction rules need legal input
ESIGN / UETA legal equivalence
Technical receipts are buildable; legal acceptance requires counsel per jurisdiction
USPS / carrier integration
Requires partnership — not buildable unilaterally
How to present eMbox
Tips for investor meetings, partner conversations, and demos.
Lead with the problem
Do: Start with mail theft, porch piracy, and sensitive documents visible on doors.
Avoid: Opening with patent numbers or technical jargon.
Show the flow, not the code
Do: Walk through send → secure → glance → retrieve → read using the /demo page.
Avoid: Claiming the product is fully built today.
Be honest about stage
Do: Say 'patent pending, software MVP in development, hardware prototype next.'
Avoid: Saying 'FCC certified' or 'legally equivalent everywhere' without qualification.
Separate tech from legal
Do: Explain that retrieve-at-door creates a cryptographic delivery receipt; legal acceptance is pursued with counsel.
Avoid: Promising court acceptance in all jurisdictions.
Hardware path
Do: Explain software simulator proves protocol first; ESP32 + e-ink + secure element is the production path.
Avoid: Showing only mockup images without explaining the engineering plan.
Engineering FAQs
Yes. A Node.js device simulator can run the full vault, glance-only UI, and retrieve protocol on a laptop. This proves the system before investing in enclosure, e-ink, and FCC certification.