Send, receive, and read receipts

Sending in Glitr always feels local: you type, you hit send, a bubble appears. What the ticks mean depends on whether the contact is on git or live.

Before you can type

The composer is enabled when the contact is Active, Connecting, or Live.

Open the thread from Chats once the contact can receive.

It stays disabled while they are Pending or Unreachable — Glitr does not yet have a profile to encrypt to. Finish setup on their side, or retry verify.

Connecting is not a gate. You can send while the live handshake is still running; those sends use git.

What happens when you send (git)

1. Glitr writes the message locally. You see the bubble and a single tick.
2. A background worker commits and pushes your repository. The payload for them lives in outbound on your mailbox, encrypted to them.
3. When the push matches what was written, ticks become double gray — delivered to git, not yet read.
4. Their app, on its next poll, fetches your repo (from a local clone it already keeps), decrypts outbound addressed to them, and inserts it into their inbox (encrypted at rest on their repo).
5. When they open the thread, a read receipt is written on their repo (plaintext coordination). Your next poll turns ticks blue.

You do not wait on their device being online for steps 1–3. You wait on your push, then on their fetch.

Single tick: written locally.

Double gray: your mailbox accepted the push.

What happens when you send (live)

If the header shows Live:

• The message goes over the direct link.
• There is no outbound row in git for that send.
• Double gray ticks mean they acknowledged on the link.
• Blue ticks mean they sent a read frame on the link.

If the link drops, the next send uses git again. You do not flip a switch.

Ticks

What you see	Name	Git path	Live path
✓	Sent	Written locally; own repo has not pushed that commit yet	(rarely stays here)
✓✓ gray	Delivered	Push of your mailbox succeeded	Peer ack on the link
✓✓ blue	Read	Their read receipt has been processed	Read frame on the link

The header also shows a sync indicator for the whole mailbox (poll, push). Ticks are per message; the indicator is global. If ticks disagree with the indicator, trust the ticks for that bubble and read the poll toast for the mailbox.

Receiving

You do not “check email” by hand unless you want to.

• Auto-poll runs on a short timer (on the order of ten seconds) and is local-first: it ingests from clones already fetched, then notes whether your own push has caught up.
• Poll now runs a pass immediately. If a poll is already running on the web, it cancels in-flight git HTTP and starts again. The label shows a countdown to the next automatic pass.

Open Chats to see new threads. Opening a thread is what creates the read receipt on the git path.

The other side sees the thread after poll, not after your send.

Blue ticks: they opened the chat.

Sent history

A copy of what you sent is stored on your side (encrypted at rest). When a git message is fully read, outbound is cleaned up and the sent copy records that it was read. You can inspect a contact’s outbound from their details if you are debugging “did it leave my laptop?” — that view reads the last local clone, not a fresh network round-trip by itself.

Notifications

Poll toasts are on by default and can look technical (timings for fetch, ingest, push). They are there so a stuck mailbox is diagnosable. You can ignore them until something fails; then they tell you whether the delay was your push or their fetch. See Troubleshooting.