Direct live links
Git is an excellent mailbox and a mediocre instant messenger. When both people are actually at the keyboard, Glitr tries to open a direct live link so the next message does not wait on a push and a poll.
Git as the broker
There is no Glitr STUN farm you must trust as the product (your browser will still use ordinary WebRTC ICE, which may involve public ICE servers — that is how browsers find a path, not how Glitr stores chat).
The introduction is yours:
- Each connected app publishes a signaling row for a contact on its own repository.
- The inner handshake (offer/answer, candidates) is encrypted to that contact.
- The other app’s poll decrypts rows addressed to it and completes the handshake.
- Status moves Connecting → Live.
Logout or disconnect deletes the signaling row. You are not leaving a permanent “call me” file after you close the door.
One row per contact; refreshing it updates the handshake, it does not pile a new file beside the old one forever.
What rides the link
Messages and receipts. Send skips outbound git for those live lines. Local sent/inbox still update so the UI does not forget what you just said.
If the channel dies, the next send is git again. You will see ticks follow the git table, not the live table.
QR and two-browser meet
A dedicated live experience lets two browsers meet with a compact invite (including a QR form). That is the same class of handshake: bundle the offer, let the other device answer, then talk over a data channel.
Use it to feel the “both online” path without standing up two git remotes first. The full product still uses git as the broker when you are in the messenger with a contact you already added.
Why it sometimes never goes Live
ICE has to find a path between two networks. Some networks will not. Glitr’s promise in that case is git delivery, not a VPN. See Live vs offline and Troubleshooting.