monal-rebuild/UX-MEDIA-RESULTS.md

Encrypted attachments — 2026-10-08

The operator approved package 9 "design first", then implementation, then the release. Sol High is retained; no delegation. Existing blunix handoff edits remain unstaged there. Baseline release was generation 556, client 8ea43b9.

Format decision

XEP-0454 aesgcm://, not XEP-0447. The full write-up with its source evidence is in OMEMO-PLAN.md, "Encrypted attachments: format decided"; the short version is that Monal's MLMessageProcessor.m recognises an encrypted file transfer only from a decrypted body that is a single whitespace-free aesgcm:// token, its xmpp.m adds the jabber:x:oob child only on the unencrypted branch, and it implements no urn:xmpp:sfs:0 at all. So: the URL alone, no caption, no thumbnail line, no OOB child, AES-256-GCM with a 12-byte IV first and the tag appended, fragment hex(iv)||hex(key) = 88 characters. Receive additionally accepts the 96-character and key-only layouts Conversations' TransportSecurity documents.

No blunix change was needed, verified rather than assumed: upload.0ff.space's file route already answers access-control-allow-origin: https://chat.0ff.space from mod_http_file_share's own cors block, the chat CSP already permits that fetch and blob: media, no upload type restriction is configured, and the 10 MiB http_file_share_size_limit only needed the client to count the 16-byte tag.

Implementation

Client 031766c. New src/crypto/aesgcm.ts on plain WebCrypto, so an attachment never depends on omemoSupported(). sendFile encrypts for a capable 1:1 contact and uploads the ciphertext as application/octet-stream under a <uuid>.<ext> name; mediaCapability reports encrypt instead of the old limitation text; isAttachment became attachmentUrl(body, oob, encrypted) so neither the chat-list preview nor a notification can print a URL carrying a file key; Chat.svelte fetches, decrypts and renders one object URL per message, released when the message leaves the loaded window or the view closes.

Two defects found while building, both written up in OMEMO-PLAN.md, "Encrypted attachments implemented": url.protocol = "aesgcm:" silently does nothing because WHATWG URL refuses a non-special scheme over a special one, and — more seriously — the design's own send path would have put the aesgcm:// body, which is the file key, on the wire in cleartext if the peer's device list emptied between the upload and the send. The authorize callback now rejects a changed encryption decision rather than only a withdrawn one, and send() refuses an aesgcm:// body without an envelope outright, and in a room at all.

Local checks: npm run check clean, npm test 86 passing (9 new in test/aesgcm.test.ts, including a vector decrypted from an independent node:crypto AES-256-GCM ciphertext), npm run build succeeds.

Release and live evidence

Client 031766c pushed to main, pinned by the isolated blunix d23cb82 lock commit. The operator ran the switch; it succeeded as generation 557, system /nix/store/bivnm359j1a1h9awvbbh8nw6h32ch0s6-nixos-system-blunix-26.11.20260910.8ce4ef6, nginx root /nix/store/cjk60a637slh8h2kdb25dmjb860s2839-0ff-chat-0.1.0. The Nix-built bundle, the local dist build and the bundle served over HTTPS are byte-identical (b8e62d8e…), and sw.js is unchanged (e28aaebf…). HTTPS 200, the strict CSP unchanged, and the iPhone black-translucent status metadata retained. Ten checked platform services active, zero failed units. Rollback: 556.

Live acceptance: ux-media-runner.cjs against the deployed bundle with two Linux browser profiles (Chromium 152) and the dedicated audit accounts — all ten checks pass, zero page errors, zero network failures (media-chromium-1791471031068).

• The encrypted chat offers attachments at all, and the old "aren't supported yet" text is gone.
• Image, generic file and voice round trips: every outgoing stanza is OMEMO encrypted, carries no jabber:x:oob child and contains no aesgcm string in cleartext XML; the receiving profile decrypts independently. The 1×1 PNG decodes to 1×1 on the other side, and the generic file is saved through a real browser download as the exact plaintext bytes.
• Metadata: slot requests declare application/octet-stream and a <uuid>.<ext> filename, never the user's name, and the chat-list preview reads "📷 Photo" rather than a URL.
• Upload sizes prove the payload: plaintext 70 and 296 bytes became 86 and 312 — plaintext + the 16-byte tag, exactly — and the only plaintext PUT in the whole run was the group upload, which is plaintext by design.
• Cancellation sent no message; in this run it also made no PUT at all, because the abort landed during the slot request.
• A 404 reads "No longer available on the server." and an integrity failure reads "This file could not be decrypted."; the two are distinct, and the retry recovers the same file once the bytes are intact.
• An aesgcm:// URL on a foreign host is explained without issuing any request to it, and no request left the app's own origin and upload host for the entire run.
• The group path is untouched: jabber:x:oob present, no aesgcm, the real media type and the real file name kept, bytes unaltered.

Three of those checks first failed on the runner's own mistakes, not the app's, and the causes are worth recording because they would mislead the next run: Prosody serves uploads with cache-control: max-age=31556952, immutable, so re-reading an already-fetched attachment never reaches the network and a reload-based check asserts nothing — each failure check now sends a fresh attachment; the profiles are persistent, so a bare waitFor on a blob image matches an earlier run's attachment and passes without anything being sent — the round trips now count; and connect-src does not list blob:, so an in-page fetch of the app's own object URL is blocked by CSP, which is why the saved-file check uses a real download instead. The app never fetches its own blob, so this is not a product gap.

The group fixture ux-media-chromium-1791471061479@muc.0ff.space was destroyed at the end of the run (confirmed in the report), the seeded foreign-host message row was deleted, no browsers remained, and the host finished with all services active and zero failed units. Reports, profiles and credentials stay under /tmp/chat-ux-runner, never in Git.

Still open, and only the operator can close it

• The round trip against real Monal in both directions: send an encrypted photo, file and voice note from the PWA and open them in Monal, and the reverse. Two copies of this web client cannot substitute for it.
• iPhone media hardware: actual recording permission, recording and playback, plus playback of a Monal-sent voice note.
• A known pre-existing limitation worth watching there: a WebM voice note recorded on desktop will not play in Monal on iOS. The recorder prefers audio/mp4 where the browser offers it, which is the iOS case.
• A federated contact's encrypted attachment stays unopenable by design, because connect-src names only our own upload host. Not to be "fixed" by widening the CSP.

Monal interop, 2026-10-08 (partly confirmed, partly my own fault)

Monal → PWA, encrypted attachments: confirmed (corrected 2026-10-08, later the same day; the first version of this section misattributed a text message and is wrong). From lukas@0ff.space/Monal-iOS.5a842ecc at 15:30:48 and 15:31:07 UTC: a PDF and a JPG, both stored encrypted: true with an aesgcm:// body, no oob and undecryptable: false, both fetched HTTP 200 and rendered from blob URLs — the image as an image, the PDF as a file link. A second JPG was fetched as well. The "Jo works" text came from lukas@0ff.space/web.97d38d50, the operator's own web client, not from Monal, so Monal has confirmed the attachment direction, not a text.

The voice note from Monal: resolved on the second attempt, and it works. The first one, reported missing, never reached the archive at all; nothing on this side could have shown it. The operator recorded another one and it arrived at 16:14:00 UTC from lukas@0ff.space/Monal-iOS.5a842ecc: stored encrypted: true, aesgcm:// body, no oob, undecryptable: false, file name C8331F4B-266E-4634-9DE1-E288BD30E54B.m4a — so Monal anonymises its audio path as well as its photo path. It decrypted (AES-GCM verified the tag, which is what a successful decrypt means), rendered as an <audio> element from a blob URL, and no .media-problem branch appeared. That completes the receive direction: photo, document and voice note from real Monal. Checked read-only against the untouched interop profile; what became of the first voice note was never established and I will not guess.

A Monal-side observation, not a defect here: the PDF reached the upload service under its real file name, while the photos carried Monal's anonymised uppercase-UUID names. So Monal 6.4.21 anonymises its photo path but not its document path, and the document name is visible to the server even though the file is encrypted. This client always anonymises.

Two earlier Monal messages are permanently unreadable here, and that is a test-sequencing mistake, not a defect. They arrived at 14:48:32 and 14:50:38 UTC, encrypted to the devices the audit account published at the time. Between acceptance runs the browser profiles were deleted twice (rm -rf media-profiles) to clear stale state — which destroyed the OMEMO identities those messages were encrypted to. The client rendered exactly the right thing, "Encrypted message sent before this device was added." Lesson for the next round: never wipe an audit profile while the operator is testing from their phone against it, and keep the interop profile separate from the runner's.

That separate profile now exists: /tmp/chat-ux-runner/monal-profile/a, not touched by any runner. While setting it up, the 17 orphaned devices left by the wiped profiles were retracted through Settings' own "Your devices" cleanup; ux-audit-20261007-a now publishes exactly one device, 119135999, fingerprint 1F26855F 880CD830 C159E24C 95951685 FD376B60 BE22A594 5BA09200 64DED562. Worth knowing for future automation: each removal goes through a confirm(), and Playwright dismisses dialogs by default, so without page.on('dialog', d => d.accept()) every click is a silent no-op.

PWA → Monal, attachments: sent and verifiably encrypted; display in Monal is the operator's step. From that profile a text, a photo (0ff-chat-test.png, the client's own 192×192 icon), a text file (package9-note.txt) and a recorded voice note went to the operator's account. All four stanzas are confirmed from the server archive — encrypted: true, oob: null, the OMEMO fallback body — at 15:26:47, 15:26:50, 15:26:51 and 15:26:54 UTC. Each also rendered from a decrypted blob on the sender's own side, and the re-download after a reload returned HTTP 200 for all three.

One pleasant surprise: the voice note went out as .m4a — Chromium offered audio/mp4, so the recorder's first preference applied and the "WebM will not play in Monal on iOS" caveat should not bite this file. That caveat still holds for a browser that only offers WebM.

The receiving half is now confirmed against that profile. Remaining, operator-side and only that: open the three attachments sent to Monal and say whether the photo displays, the file opens and the voice note plays.

Also open: the operator reports that sending an attachment from chat.0ff.space does not work for them, with a description still to come. Nothing here reproduces it — the audit profile sent a photo, a file and a voice note from the deployed bundle minutes earlier, all four stanzas encrypted with no oob. The first hypothesis is a stale installed PWA: the service worker is network-first for the page, so a reload picks up a deploy, but an installed iOS PWA resumed from the background keeps its running document and therefore the old bundle. Previous asset index-DlzpKHNm.js, current index-CKa1YQZ8.js; nginx keeps no access log here, so which one a given client loads cannot be checked from the server.

Dead attachment button on iOS — 2026-10-08, fix shipped, cause unproven

The operator reported that pressing the attachment button on chat.0ff.space did nothing at all: no picker, no error.

openPicker was if (await checkMedia()) picker?.click(), and checkMedia calls mediaCapability(peer, true) — a forced PEP device list fetch plus the WASM probe, so a network round trip — before the programmatic picker.click(). iOS Safari ignores a programmatic click on a file input once an await has let the click's user-activation window lapse, and silently: exactly the reported symptom. The same shape also means a slow or stalled capability fetch leaves the button inert with no feedback, since that call has no timeout. Rooms never showed it because mediaCapability returns for a joined room without awaiting anything real, and an encrypted 1:1 chat only got a clickable button with package 9.

Fixed by splitting the decision: a synchronous mediaGate() uses the capability the view already keeps current, so the picker opens — and the microphone is asked for — inside the click; the forced recheck still runs in sendAttachment before anything is uploaded, so unsupported media still never reaches a slot request or a PUT, and a chat known not to accept media still never triggers a permission prompt.

Confirmed on the operator's iPhone: after the switch to generation 558 they report the attachment button working. That is the only evidence that could settle it, for the reason below.

Two honest limits on the automated side. First, the live acceptance run never exercised this path at all: every media check sets files on the input directly, which bypasses the button. A MEDIA-PICKER-OPENS check now presses the real button. Second, that check does not guard the iOS restriction: a control run with the await deliberately restored passes in both Chromium and Linux WebKit, so neither engine enforces Safari's activation window for this. The regression it would catch is a disconnected or broken button, not a lapsed activation window — do not read a green MEDIA-PICKER-OPENS as cover for that class of bug.

Released as generation 558, client 19a71e9, nginx root …war8p4rppi3xidz11i9716yi480c8lhf-0ff-chat-0.1.0; the Nix build and the HTTPS-served bundle are byte-identical (3626926447…), sw.js and the CSP unchanged, ten services active, zero failed units. Rollback: 557.

The full suite re-ran against it: all eleven checks pass, zero page errors, zero network failures, the room fixture destroyed. One check, MEDIA-GROUP-PLAINTEXT, failed on that first re-run and it was again the runner, not the client: chat(room) waits for an enabled composer, which the conversation being navigated away from already satisfies, so the attach landed before the room was joined and the client correctly refused with "Join the room before sending files". It now waits for the header to show participants. Worth remembering: a green run right after a UI change is worth re-reading, because a check can pass or fail for reasons that have nothing to do with the change.

Quoting an attachment names it — 2026-10-09

The operator swiped a voice note to quote it and got the raw aesgcm://…#<key> URL in the quote. db.ts has always labelled an attachment for the chat-list preview, with the comment that the preview never shows that URL because it carries the file key; the quote path did not. quotedText in src/xmpp/replies.ts now labels it, and displayQuote labels an aesgcm:// line at render time as well, for history written earlier and for whatever a remote client sends. Only aesgcm:// lines are replaced: a plain https link in a quote may simply be a link.

This was never a leak over the wire. In an encrypted chat the quote rides in the same OMEMO envelope as the original, and session.send refuses an encrypted quote into a chat that is not capable. What it was: the file key copied into a second message for nothing, and a wall of hex where a human expects "Voice message".

Checked by SWIPE-QUOTES-ATTACHMENT-BY-NAME in ux-swipe-runner.cjs, which uploads a real encrypted image, swipes it, and asserts the preview reads 📷 Photo, the sent quote names the attachment, and neither the quote nor the outgoing stanza carries aesgcm:. Two unit tests in test/replies.test.ts pin the transformation itself.

An unrelated observation, recorded not chased

While verifying the above, full runs of ux-media-runner.cjs flaked: MEDIA-FILE-ROUNDTRIP ("no message went out" although the receiver had the file), MEDIA-GROUP-PLAINTEXT and MEDIA-NO-STRAY-REQUESTS. The same full run against the deployed site fails the same way, so this is not the quote change. Focused runs of the individual checks pass on both. The likely cause is the state the two audit accounts accumulated across many runner invocations in one day — several of these checks count PUTs and assume no other traffic. Worth a clean-account run before reading anything into it.