UTC timestamps, animated GIFs, multi-file sends, and a 2-4x faster bridge

.github/workflows/ci.yml

@@ -14,7 +14,7 @@ jobs:
       - name: unit tests (collector, thread, tier2, ui invariants)
         run: bun test
       - name: Mac tools compile (python3 syntax, no macOS needed)
-        run: python3 -m py_compile bridge/mac/imsg bridge/mac/imsg-send bridge/mac/contacts bridge/mac/tcc-check bridge/mac/blip-check bridge/mac/blip-dispatch bridge/mac/imsg-read bridge/mac/calling_codes.py
+        run: python3 -m py_compile bridge/linux/blip-bridged bridge/mac/imsg bridge/mac/imsg-send bridge/mac/contacts bridge/mac/tcc-check bridge/mac/blip-check bridge/mac/blip-dispatch bridge/mac/imsg-read bridge/mac/calling_codes.py
       - name: group-photo lookup (no macOS needed)
         run: python3 bridge/mac/test_group_photo.py
       - name: phone matching, the way Contacts does it (no macOS needed)
@@ -25,6 +25,10 @@ jobs:
         run: python3 bridge/mac/test_unsent.py
       - name: conversation cluster pins (no macOS needed)
         run: python3 bridge/mac/test_cluster.py
+      - name: stamps cross the bridge as UTC (no macOS needed)
+        run: python3 bridge/mac/test_wire_time.py
+      - name: the serve channel exposes only read-only queries (no macOS needed)
+        run: python3 bridge/mac/test_serve.py
       - name: shell scripts (bash -n + shellcheck)
         run: |
           bash -n bridge/linux/blip-shim scripts/blip-setup scripts/sync-bridge.sh scripts/demo/blip-shots bridge/mac/install.sh

BarWidget.qml

@@ -509,6 +509,33 @@ BarWidget {
                               root.activeReadChat(), root.activeSeenTs())
   }
 
+  // ------------------------------------------------- the accelerator channel
+  // blip-bridged holds `imsg serve` channels open to the Mac, so a query costs
+  // the query instead of ~90 ms of ssh + two Python starts + opening a 218 MB
+  // chat.db. Measured end to end: opening a conversation 223 → 103 ms, a poll
+  // 160 → 38 ms. It rides here for the same reason the watcher does — the
+  // shell is the process that outlives every one-shot script, which is why
+  // Blip needs no daemon of its own — and only on the LEADER bar, or every
+  // monitor would hold its own pair of Mac processes.
+  //
+  // Nothing depends on it: collector.ts and thread.ts fall back to the plain
+  // one-shot ssh path whenever the socket is missing or a frame does not
+  // parse, so a failure here costs speed and nothing else.
+  Process {
+    id: bridgeProc
+    command: [root.home + "/bin/blip-bridged"]
+    running: root.leader
+    onExited: bridgeRestart.restart()
+  }
+  Timer {
+    id: bridgeRestart
+    // It exits on its own when idle; the poller keeps it busy in practice, so
+    // this is mostly the crash path. Slow enough not to spin if the binary is
+    // missing entirely (a setup that never installed it).
+    interval: 30000
+    onTriggered: if (root.leader) bridgeProc.running = true
+  }
+
   // ------------------------------------------------- real-time push
   // `imsg watch` blocks on the Mac and emits one line per chat.db change — an
   // INVALIDATION, no content (BlueFerry's design: session-visible push
@@ -552,7 +579,14 @@ BarWidget {
   }
   Timer {
     id: pingDebounce
-    interval: 250
+    // 60 ms, not 250: this delay is paid on EVERY received message and on
+    // every send (Messages writing the row is itself a chat.db change, so the
+    // ping is what resolves the "Sending…" bubble). A burst still costs one
+    // fetch — messages in a burst land milliseconds apart, far inside 60 ms —
+    // but a single message no longer waits a quarter second before anything
+    // starts. Measured: the fetch it triggers is ~116 ms, so the debounce was
+    // more than twice the cost of the work it was coalescing.
+    interval: 60
     onTriggered: {
       var panel = panelLoader.item
       // Carrying the open thread's chat means a message landing in the