Push by subscription, and a latency fix for the compressor #292

New Issue

Closed

opened 2026-09-06 20:25:47 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-06 20:25:47 +00:00

Owner

Two commits, review separately.

1. Skip the compressor for clients that offer no encoding

Listing p50 at one user was 3.25 ms on main against 1.95 on the previous
release; a bisect put all of it on #288. Not gzip — the harness never sent
Accept-Encoding. Hono's middleware inspects every compressible response it
declines and sets Vary, which rebuilds a streamed passthrough off its fast
path: ~1.2 ms per JMAP call for a request that asked for nothing.

one user	`Accept-Encoding`	list p50
compressor touches but declines (before)	none	3.25 ms
skipped entirely (fix)	none	2.02 ms
compressor applied	gzip	2.27 ms
previous release	either	1.95 ms

Applying gzip to a JMAP response costs about a quarter of a millisecond for
3–5× fewer bytes, so JMAP stays compressed by default; COMPRESS_JMAP=0
turns it off.

2. Push by subscription: hold no upstream connection per tab

RFC 8620 §7.2 PushSubscription, one per account, registered at sign-in;
Stalwart POSTs StateChange to /api/push/<token> and ihasmail fans it out
to that account's tabs over the browser streams it already holds. A tab opens
on the relay and migrates to fan-out when its account verifies — upstream
request ended, browser stream untouched, nothing retained. Clean-room from
the RFC.

Measured at 256 MiB over a private route, 6,144 accounts verified during the
ramp, zero failures, zero errors:

	tabs	client	Stalwart	system KiB/tab
raw relay (before)	5,000	48.2	46.4	94.6
push by subscription	6,144	33.3	4.8	38.0
Bulwark 1.9.2, same bench	12,389	4.8	53.8	58.6

One descriptor per tab. Stalwart holds no connection for ihasmail's users, so
its per-listener limit no longer applies to ihasmail. System-wide, 35% less
per tab than Bulwark, with the mail server still private.

Deployment requirement: PUSH_URL is the https origin Stalwart reaches
ihasmail at; the RFC requires https and Stalwart enforces it, so Stalwart
must trust that certificate (a public TLS front already does; a private
segment needs an internal CA in Stalwart's trust store). An account that
cannot verify stays on the relay — nothing breaks, only the saving needs the
cert. PUSH_MODE=relay disables the path. /api/health reports the split.

Proven on the committed HEAD: verified ≤10 s after sign-in, tab opened
directly onto fan-out, StateChange delivered. 159 tests. No user-visible
strings, so no catalogue work.

Merged 2026-09-06 as coffey-labs/ihasmail@db7b103a08

_{Rebuilt from: GH Archive, git history, session transcript.}

Two commits, review separately. ### 1. Skip the compressor for clients that offer no encoding Listing p50 at one user was 3.25 ms on `main` against 1.95 on the previous release; a bisect put all of it on #288. Not gzip — the harness never sent `Accept-Encoding`. Hono's middleware inspects every compressible response it declines and sets `Vary`, which rebuilds a streamed passthrough off its fast path: ~1.2 ms per JMAP call for a request that asked for nothing. | one user | `Accept-Encoding` | list p50 | | --- | --- | --- | | compressor touches but declines (before) | none | 3.25 ms | | **skipped entirely (fix)** | none | **2.02 ms** | | compressor applied | gzip | 2.27 ms | | previous release | either | 1.95 ms | Applying gzip to a JMAP response costs about a quarter of a millisecond for 3–5× fewer bytes, so JMAP stays compressed by default; `COMPRESS_JMAP=0` turns it off. ### 2. Push by subscription: hold no upstream connection per tab RFC 8620 §7.2 `PushSubscription`, one per account, registered at sign-in; Stalwart POSTs `StateChange` to `/api/push/<token>` and ihasmail fans it out to that account's tabs over the browser streams it already holds. A tab opens on the relay and migrates to fan-out when its account verifies — upstream request ended, browser stream untouched, nothing retained. Clean-room from the RFC. Measured at 256 MiB over a private route, 6,144 accounts verified during the ramp, zero failures, zero errors: | | tabs | client | **Stalwart** | **system** KiB/tab | | --- | --- | --- | --- | --- | | raw relay (before) | 5,000 | 48.2 | 46.4 | 94.6 | | **push by subscription** | **6,144** | 33.3 | **4.8** | **38.0** | | Bulwark 1.9.2, same bench | 12,389 | 4.8 | 53.8 | 58.6 | One descriptor per tab. Stalwart holds no connection for ihasmail's users, so its per-listener limit no longer applies to ihasmail. System-wide, 35% less per tab than Bulwark, with the mail server still private. **Deployment requirement:** `PUSH_URL` is the https origin Stalwart reaches ihasmail at; the RFC requires https and Stalwart enforces it, so Stalwart must trust that certificate (a public TLS front already does; a private segment needs an internal CA in Stalwart's trust store). An account that cannot verify stays on the relay — nothing breaks, only the saving needs the cert. `PUSH_MODE=relay` disables the path. `/api/health` reports the split. Proven on the committed HEAD: verified ≤10 s after sign-in, tab opened directly onto fan-out, `StateChange` delivered. 159 tests. No user-visible strings, so no catalogue work. **Merged** 2026-09-06 as coffey-labs/ihasmail@db7b103a08d5 <sub>Rebuilt from: GH Archive, git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#292