Home / Blog / How Serverless Group Scheduler Secures Your Polls: Encryption, Compression & Payload Architecture
General • August 15, 2026

How Serverless Group Scheduler Secures Your Polls: Encryption, Compression & Payload Architecture

Because your app is 100% serverless and local-first, there is no central database (like PostgreSQL or Firebase) storing your polls.

Instead, the data itself is packed inside the link, QR code, or payload string. The recipient's browser unrolls that data back into a usable schedule.

Here is an exact step-by-step breakdown of how data generation, encryption, sharing, and receiving work under the hood.

1. Data Generation Pipeline (Host Creates Poll)

When the host clicks "Create Poll & Share", the app processes the schedule data through a 4-step client-side pipeline:

[ Raw Schedule JSON ] 
          │
          ▼ 
 1. CompressionStream API  ──> (Gzip/Deflate shrinks text size by ~70%)
          │
          ▼ 
 2. Web Crypto API         ──> (Optional: AES-GCM Encrypts with Host Password)
          │
          ▼ 
 3. Base64 Encoding        ──> (Converts binary bytes into clean URL text)
          │
          ▼ 
 4. Final Payload Output   ──> (e.g., "SAV-eJxr3fL2d...")

The 3 Ways to Share That Payload

Once that final payload string is generated, the app presents it to the host in 3 interchangeable formats:

Share Method How It Works Under the Hood Best Use Case
1. Generated Link (URL Hash) Appends the payload string to the URL fragment:
https://zeroservertools.org/tools/group-scheduler.php#poll=SAV-eJxr3fL2d...		 Email, Slack, Discord, SMS
2. QR Code "Save Card" Uses client-side JavaScript (QRCode.js) to turn the full generated link into a visual QR code canvas image In-person sharing, desktop-to-mobile transfer
3. Raw Encrypted Payload Displays the raw Base64 string (SAV-eJxr3fL2d...) in a text box with a "Copy to Clipboard" button Direct messaging when URLs are blocked or stripped by security filters

2. Ingestion Pipeline (Participant Opens & Decodes)

When a participant clicks the link, scans the QR code, or pastes the raw code into the app, the pipeline runs in reverse:

[ Incoming Payload String ] ──> (From URL Hash #, QR Scan, or Paste Box)
          │
          ▼
 1. Base64 Decode          ──> (Converts text string back to binary)
          │
          ▼
 2. Web Crypto API         ──> (Prompts guest for Password IF encrypted -> AES-GCM Decrypt)
          │
          ▼
 3. DecompressionStream    ──> (Decompresses binary back into UTF-8 JSON text)
          │
          ▼
 4. App State Loaded       ──> (Participant UI renders the interactive voting grid)
Why this works offline: The recipient doesn't ping your web server to fetch the poll. Their browser reads the URL hash locally, decrypts/decompresses it in memory, and builds the UI instantly.

3. How the "Response Loop" Works (Syncing Votes Back)

Since there is no database, how does the participant send their votes back to the host? This depends on whether you are using Approach A (WebRTC) or Approach B (Payload Fallback):

Approach A: Real-Time P2P (Primary Mode)

  1. The shared link/QR code contains the Host's Peer ID + Password Hash.
  2. When the guest opens the link, PeerJS establishes a direct WebSocket/WebRTC P2P tunnel to the host's browser.
  3. When the guest votes, their response JSON streams directly across the WebRTC connection into the host's browser in real time.

Approach B: Pure Offline Payload (Fallback Mode)

If P2P fails or the host is offline:

  1. The guest votes on the grid.
  2. The app packs the guest's vote into a new short Response Payload (RESP-eJxr3f...).
  3. The guest sends this short string back to the host (via email, chat, or WhatsApp).
  4. The host opens their app, clicks "Import Responses", and pastes the guest's payload. The host's app decrypts it and appends the vote to the consensus heatmap.

Security & Privacy Guarantees

What Gets Encrypted?

  • ✅ Poll title and description
  • ✅ Time slots (start/end times)
  • ✅ Participant responses and votes
  • ✅ Optional password protection (AES-256-GCM)

Why Zero-Backend Architecture?

  • No server database: Your data never touches a corporate server
  • No tracking: No user accounts, no analytics, no logging of poll contents
  • No vendor lock-in: Export your polls as QR codes, URLs, or encrypted strings at any time
  • Offline-first: Works completely without internet after initial page load (thanks to Service Workers)

How Do We Know It's Secure?

  • Open Standards: Uses Web Crypto API (NIST-approved AES-256-GCM)
  • Browser-Native: No external crypto libraries with potential vulnerabilities
  • PBKDF2 Key Derivation: 100,000 iterations prevent brute-force password attacks
  • Source Code Auditable: All client-side code runs in your browser (View Source → Inspect)

The Bottom Line

Your poll data is encrypted before it ever leaves your browser, packed into a single string, and shared as a link, QR code, or text. When someone opens that string, their browser decrypts it locally using your password (if you set one), and the data never touches any server.

This is true zero-knowledge architecture — even we (the app creators) cannot see inside your encrypted payloads.

← Back to Blog