Your mailbox is a git repository

Popular messengers hide a data center in the middle. You send; their server holds the line until the other phone wakes. Instant is easy when someone else is always online on your behalf.

Glitr refuses that shape. The always-online party is your git host, and git hosts are not chat servers. They accept a push when you make one. They do not ring a peer.

History can stay on the device. When you connect or attach remotes, each person brings a git repository. The app treats that repository as a structured, mostly encrypted mailbox. Remotes are optional; extra remotes are backups of the same local HEAD.

Use this mental model: email, if email were a git push.

Who writes where

You fetch their mailbox. They fetch yours. Nobody writes into the other person’s repo.

• Outbound lives on the sender’s repository. The payload is cascaded for the recipient (AES → Signal → PQXDH, then RSA hybrid → ML-KEM). Sending does not wait for their laptop. A background worker commits and pushes.
• Inbox lives on the recipient’s repository, encrypted at rest, after their app has ingested outbound addressed to them.
• Sent history lives on the sender’s repository, encrypted at rest.
• Read receipts live on the recipient’s repository as coordination files (git path). Live receipts skip git and travel on the direct link.
• Signaling lives on each person’s repository: one row per contact, refreshed while you are connected, deleted on logout. The SDP is cascaded to the recipient; the file is there so git can broker a live link.

Peers are not queried live over a special API. Glitr keeps a local clone of each git contact’s repo (fetch only) and polls that clone. Pair-now contacts use a live address only — no peer clone.

The clock you are on

1. You encrypt the line and push it to your repo.
2. They may be offline. Nothing waits on them.
3. They later fetch your repo and decrypt what is addressed to them.
4. They write inbox plus a read receipt on their repo.
5. Your next poll fetches that receipt and turns ticks blue.

Each step is a network round trip you already understand from git. Polling (about every ten seconds, plus Poll now) is how the app notices new tips. That is why a quiet contact is seconds, not the blink of a typing indicator from a socket in a data center.

A single tick means “on this device.” Double gray means “on the mailbox” (or acked live). Blue means “they opened it.” If a product showed a single check and called it delivered to a person who is camping, it would be guessing. Glitr waits for git (or the live ack).

Why git

• You already know how to own it, clone it, and delete it.
• Any host that speaks git-over-HTTPS can hold the bytes.
• History is an audit log you can copy off-host.
• Offline send is naturally “write a note, push when you can.”
• Extra remotes keep the same tip on more than one host after a successful origin push.

The cost is the same as any git remote: latency, tokens, host policy, and the fact that a replica is a replica. GitHub, GitLab, and Codeberg may treat this mailbox use as against their terms. They may throttle, block, or close the repo. A first-party git server as part of the service is a later possibility, not something to wait on. See Using GitHub, GitLab, and Codeberg.

Structured records, not a pile of blobs

Under the files, Glitr stores structured documents — profiles, contacts, messages — so the app can query them like a small database. db-core is a small GraphQL store over those files. Types marked for sealing are password-wrapped on flush. git-core talks to the workdir: on a desktop it uses a native git library; in the browser it uses isomorphic-git and origin-private storage.

Some fields are marked to be encrypted; others are left readable because the other person’s client must act on them without your password. You do not have to edit those files by hand. If you do, you can break the layout. Prefer the app.

Empty repositories are fine. The first connect or attach writes the schema and a version stamp. If two clients disagree on shape, migrations exist; as a user you mostly notice “please update the app.”

Two devices editing the same document (same contact row, same message id) can conflict. Conflicts are per document, not “the whole repo is on fire.” Profile and schema stamps are blocking if they diverge — finish one device’s sync before inventing a second identity in the same mailbox.

What git is not doing

Git is not encrypting for you. Encryption is a layer Glitr applies before write. Git is not the live path. Git is the store and (for git contacts) the bulletin board for handshakes. The live link is a separate connection that Pair now or git signaling helps you find.

Live 1:1 files stay on the data channel (plus a resume row under file-transfers/). Offline git DMs and group attachments write the file inside the outbound ciphertext envelope instead.

You gain a mailbox you can clone. You lose the feeling that a corporation is holding your unread line in RAM. If you need the feeling more than the mailbox, you will prefer a conventional messenger — and you will be renting their uptime again.

The product story is Git as your mailbox. Persistence mechanics are on Persistence. Delivery ticks and latency live on Why not always instant.