The Keys to the House: When Your Mailbox Becomes Your Identity
On identity, access, and the infrastructure you already own
The Master Key Problem
There's a moment in every self-hosted project where you want to let someone else in. A collaborator, a contributor, someone who has something to offer. The instinct is generous — share the repository, give them push access, let the work begin.
With GitHub, this is trivial. You add a collaborator, they clone, they push. GitHub handles authentication, authorization, branch protection. You don't think about it because someone else already solved it.
But we don't host our code on GitHub. The repository lives on our VPS — the same machine that runs our workflows, our mailserver, our documentation, our civic AI platform. When someone asks to contribute, the standard answer is SSH access.
SSH access to a VPS is a master key. You can restrict it, chroot it, configure it into something barely usable — but at its core, you're giving someone a shell on the machine where everything runs. It's like handing over your house keys because someone wants to borrow a book from the shelf.
The Contradiction
We want two things that seem incompatible:
Collaborators must be able to push code to their own branches.
Collaborators must not be able to touch anything else on the machine.
This is what TRIZ calls a physical contradiction — the same resource (VPS access) must be simultaneously open and closed. The SSH approach tries to solve this through restriction: give access, then take most of it away. That's fighting the architecture.
The TRIZ resolution is Principle #28 — Mechanics Substitution: don't restrict the mechanism, replace it entirely. Instead of SSH (which is fundamentally shell access), use HTTP (which is fundamentally protocol access). The collaborator never touches the machine. They speak git protocol over HTTPS, and something in the middle decides what they can see and do.
The Answer Was Already Running
Here's what surprised us: the identity provider we needed was already running. It had been running for months.
The mailserver.
Every collaborator already has a @lockilabs.com email address. That address is their identity — it's how they authenticate to webmail, how they receive project communications, how they're known within the project. The mailserver speaks IMAP, and IMAP is an authentication protocol. You send credentials, the server says yes or no.
So instead of building an identity system — no LDAP, no OAuth provider, no external auth service — we ask the mailserver a question it already knows how to answer: is this person who they say they are?
This is TRIZ Principle #2 — Taking Out. Identity doesn't belong in git. It doesn't belong in a new system. It belongs where it already lives. We just had to ask.
Five Layers, Five Concerns
The architecture that emerged has five layers, and each one does exactly one thing:
Traefik terminates TLS and routes git.lockilabs.com to the proxy. It already does this for every other service. One more routing rule.
The proxy authenticates the request against the mailserver via IMAP. If the credentials check out, it knows who you are. Then it checks what you're allowed to see — which branches, which refs. It filters the response so you only see what's yours.
git-http-backend serves the repository over HTTP. It doesn't know about users or permissions. It's stateless, mechanical, reliable.
The pre-receive hook is the last line of defense. Even if something bypasses the proxy, the hook checks: is this person allowed to push to this branch? If not, the push is rejected before it lands. Defense in depth — the cheap gate that prevents the expensive damage.
The ACL file is a plain text mapping of identities to branches. Version-controlled, reviewable, auditable. No database, no admin panel. A file that says who can touch what.
Each layer can fail without taking the others down. Each can be tested independently. No layer solves another layer's problem.
Identity and Communication
There's a distinction that became clear as we designed this: identity and communication are not the same thing.
[email protected] is identity. It's the account that authenticates to git, to webmail, to any service that needs to know who you are. It's not public. It's not shared. It's the key.
[email protected] is communication. It's the address on the website, the one people write to, the one that forwards. It's public by design.
Most systems conflate these. Your email is your login is your contact address is your display name. But they serve different functions, and collapsing them means you can't change one without affecting the other.
Separation of concerns, applied to identity itself.
One Command to Welcome
The whole system converges on a single script: add-collaborator.sh. One command that creates the email account, creates the branch, updates the ACL. Everything a new collaborator needs to start contributing, without anyone touching SSH configuration or Docker containers or server internals.
This is what sovereignty looks like in practice — not a wall, but a door with a clear protocol. You know who's inside. You know what they can reach. And the mechanism for granting access is as simple as running one command.
What the Mailbox Knew
We spent months building infrastructure — Traefik for routing, docker-mailserver for communications, n8n for orchestration. Each piece was built for its own purpose. None of them were designed to solve the access control problem.
But infrastructure doesn't know what it's for until someone asks the right question. The mailserver wasn't waiting to become an identity provider. It just turned out that it already was one — we'd been authenticating against it every time we checked email. The question wasn't "what do we need to build?" It was "what have we already built that we haven't fully understood?"
The best architecture isn't the one with the most components. It's the one that discovers capability in what already exists.
Related: Knowledge Unguarded Is Knowledge Stolen | What the Well Remembers | The Day the Lighthouse Dimmed