Documentation
Everlock's mail server is deliberately boring at the edges. It receives mail over SMTP. Mail clients submit outgoing messages over SMTP submission. Apple Mail, Thunderbird, K-9 Mail, and Outlook read
Everlock is built around a simple promise: > History is part of the storage. A write does not silently replace the previous value. It creates another commit. That makes it possible to inspect how some
Everlock stores its state in Git repositories. That is a useful constraint. Files are versioned. Changes have history. Replication can use Git. Backups can use Git. A repository can be inspected witho
Authorization systems often become complicated one convenience at a time. Everlock ran into a good example of this while working on repository permissions. The original rule sounded harmless:
Most self-hosting decisions are decisions about convenience. You move a service onto your own hardware, accept that you are now the person who patches it, and the worst realistic outcome is some downt
Pull requests look simple when a forge is doing the work for you. A contributor creates an account, forks a repository, pushes a branch, and clicks a button. The forge connects all of those pieces and
"Everything is Git" describes the architectural rule behind Everlock. This article is the more mechanical version of that idea. What does it actually mean to build application storage on top of bare G
On most Git forges, a pull request is not really a Git object. It is an application object that happens to point at Git commits. There is usually a database row with an integer id, an author, a state,
Everlock starts with a fairly unreasonable constraint: > Everything that matters should live in Git. Not just the source code for Everlock. The data managed by Everlock. Photos. Calendars. Configurati
