Most of what we write here is about something new you can see. This one isn’t. It’s about a deliberate stretch of work we did with no user-facing payoff at all — going back over the locks, one at a time, and tightening the ones that were merely fine into ones we’re actually happy with. We promised on day one to write about the engineering and the threat model, not just the nice bits, so here we are.

What we tightened

A run of changes, none individually dramatic, that add up to a sturdier app:

  • Rate limits, everywhere that matters. The public sign-in and token endpoints, and then the authenticated routes too — sending, uploading, the destructive actions. The point is that no single device, friendly or otherwise, can hammer a door for free.
  • Every request body checked at the edge. Incoming data is validated against a strict shape before any of our code trusts it, with hard size limits, so malformed or oversized input is turned away early rather than deep inside.
  • A vetted token library instead of our own. We’d hand-rolled part of our sign-in token handling. Cryptography you wrote yourself is cryptography you get to debug yourself, so we replaced it with a well-reviewed implementation and shortened how long tokens stay valid.
  • Revocation that actually revokes. Signing out, or having access pulled, now closes the door immediately — including force-closing any live connection a device still has open, rather than letting it linger until it next reconnects.
  • The quieter internals. Stricter key derivation, tighter authentication on the real-time components, and a baseline set of security headers across the board.

A friendlier front door, too

One change you can see came out of this work: alongside the magic link, you can now sign in with a six-digit one-time code. The link is lovely on the device you’re already holding; the code is far easier when the email landed on your phone and you’re trying to sign in on the laptop. Same security model, one less moment of friction.

On error monitoring, since you’ll ask

We also wired up error monitoring so that when something breaks, we find out from a diagnostic rather than from a confused parent. It’s worth being precise about what that is and isn’t: it reports crashes and faults, it doesn’t track you, and it sets no cookies. There are no analytics SDKs in Shoal and there won’t be — the footer’s “no tracking” isn’t a slogan we quietly walk back the moment it’s inconvenient.

Honest about the ceiling

None of this changes the architectural limit at the heart of our model, which we describe in full on the privacy page: our encryption is operationally enforced, not a cryptographic wall between you and us. Tightening the locks makes the house we’ve described harder to break into. It doesn’t turn it into a different house, and we’d rather you knew exactly which one you’re living in.

How this fits with everything else

This sits under everything: the same hardening protects your messages, your media, your calls, and your account itself. The security page is the living description of where we are, and it changes as we do.

Try Shoal — and if you’re the sort who likes to poke at locks, we’d like to hear from you at [email protected].