I made Chatwoot store only ciphertext for contact PII and message text

[sashyo]

Short version: in this fork, a contact's name and phone, and the body of every message, are sealed before they reach Postgres. The database holds ms1: ciphertext, the encryption key is never assembled anywhere (not in the server, not on disk, not in one admin's hands), and a field opens back to plaintext only for an agent a quorum granted a reading role. Turn it off and Chatwoot behaves exactly like upstream.

There is a separate Ideas post proposing the small extension point that would let this ship as a plugin instead of a fork: https://github.com/orgs/chatwoot/discussions/15868 . This post is the why and the does-it-work.

The problem

A support tool holds a lot of what a breach is actually about: who your customers are (names, phone numbers, emails) and everything they told your team in a conversation. In Chatwoot today that all sits in Postgres as readable text. TLS and disk encryption help in transit and at the volume level, but a stolen database, a leaked backup, or anyone with a psql connection reads every contact and every message. Chatwoot has no field-level encryption to change that.

What it does

The key is held by nobody. It lives as threshold shares across the Tide network and is never reassembled, not even to decrypt. The server asks the network to open a field on behalf of a named agent, and the network only agrees if a quorum-granted role says that agent may read.

• Your database holds only ciphertext. A dumped contacts or messages table, or a leaked backup, reveals nothing.
• There is no standing key to steal. Compromising the app server does not hand over a key, because the key is never whole there.
• Reads are governed, not assumed. A quorum grants the reading role. Revoke it and reads stop everywhere, at once, with no re-encryption.
• Agents and compliance still work. An authorized agent reads normally; an auditor with the role can read without anyone sharing keys.
• Nobody juggles keys. Agents keep their normal Chatwoot login. The gate is a role, not a keyfile they can lose.

How it works

It is a small ActiveRecord concern plus a sidecar client, no changes to how Chatwoot runs:

• Seal on write in a before_save on the model, so the configured fields are sealed before they hit Postgres. Contact seals name and phone_number (email and identifier stay clear, they are the lookup keys Chatwoot dedupes and routes on); Message seals content.
• Open on read in an after_find, as Current.user, the agent Chatwoot already sets per request. Gated by that agent's role, so an ungranted agent just gets ciphertext.
• The reader identity is nothing new. Chatwoot already tracks the signed-in agent in Current.user; the concern mints a short-lived signed token for that agent and hands it to the sidecar.

The crypto runs in a small language-agnostic sidecar; the Ruby side just calls it over HTTP. The same sidecar backs integrations in other stacks, which is the point: this is not tied to Node or to any one framework.

Does it actually work

Yes, end to end:

• Stored in Postgres: contacts.name, contacts.phone_number, and messages.content are ms1:... ciphertext.
• A granted agent reads a conversation: "My card ending 4417 was double charged, ref 8842." and the contact as Jordan Blake / +14155550132.
• An ungranted agent in the same account reads the same rows as ms1:... ciphertext.
• Revoke the role, and the granted agent's reads go dark too, with no change to Chatwoot.

The honest tradeoff

This trusts the app server to say which agent is calling, and gates the read on a quorum-granted role. That is the right trade for a team tool where the server is already trusted to run your support desk, and what you gain is that the database and backups are worthless to a thief and that access is governed and revocable rather than implicit in whoever holds the disk. If your threat model is that the server operator themselves must never read, that is a different and stronger tool.

Disclaimer: this is the lightweight form

What I have shown is the lightweight, self-hostable form: minidauth, running "tideless", where the app vouches for the agent and a quorum-granted role gates the read. It is a proof of concept, not production hardened, and per-field round trips are the demo shape rather than the envelope-encryption shape a real deployment would use.

The enterprise-grade version is TideCloak, Tide's identity and access product, where who is calling is proven per request with threshold cryptography inside the network rather than asserted by the app server. minidauth is the small on-ramp to that model, meant to show the shape and let you try it without adopting the full stack. Treat this fork as a demonstration, and TideCloak as the path if you want to run field-level, quorum-governed sealing for real.

Try it / the code

• Fork: https://github.com/sashyo/chatwoot
• It is off unless MINIDAUTH_SEAL_URL is set; every path is upstream-identical when it is unset.
• More on minidauth: github.com/sashyo/minidauth and dauth.me.

Feedback welcome, especially on the extension-point proposal in the Ideas post. If that lands, this stops being a fork and becomes a plugin.