Projects / Cal.diy

Cal.diy + minidauth bookings that open only for the right person

Every booking carries someone's name, phone number and the reason they're meeting. In this fork of Cal.com's scheduling platform, those fields are sealed before they reach Postgres, and each request can only open them as its own signed-in user.

Open the fork Upstream Cal.diy

Run end to end

What gets sealed

Cal.diy is Cal.com's open source scheduling platform. These fields are stored as ciphertext, and nothing on the server can decrypt them.

Attendees
Name and phone number.
Bookings
Title and description.

How it's wired

  1. Sealed on write

    A Prisma client extension seals the chosen fields before they reach Postgres and handles them again on the way out.

  2. Opened per user

    Each authenticated request runs as its signed-in user, so a sealed field opens only for that verified user.

  3. Gated by a quorum role

    The field opens only if minidauth's quorum grant says that user holds the reading role.

The key that seals these fields exists only as shares across the Tide network, and 14 of 20 nodes have to cooperate to use it. It is never on the Cal.diy server.

Details that matter

  • The sealing sidecar holds no reading identity of its own. Opening is delegated per user.
  • With no reader in the request, a field simply stays sealed, so there's never an open decryption service to abuse.
  • Every inbound value is sealed, so plaintext never reaches a sealed column.

Status and running it

A proof of concept, off unless MINIDAUTH_SEAL_URL is set, so an unconfigured checkout behaves exactly like upstream Cal.diy. The fork's README covers setup against a running minidauth.

Want to do the same for another app, or stuck running this one? Join the Discord and I'll help you out.

Other projects: Formbricks · Twenty · Integrations