WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 20 found) #9
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tested
142ee094, XML_LOG AppImage; anotherim-web = the browser build of the same commit in Chromium 156c95b3d9d)vms/)master@b9e675ddEvidence re-recorded 2026-11-09 with provenance (#19): every row links an EVIDENCE.md. Batch 0 (#20): 16 runs (8 fail, 8 pass). Batch 1 (#21): 48 runs (25 fail: 18 libtacky, 7 peer; 23 pass): file sharing, the S14 and C38 rechecks, own-device sync on ejabberd. Batch 2 (#22): 75 runs (43 fail: 41 libtacky/anotherim-js, 2 peer; 31 pass; 1 na): XEP-0045 admin, 0249, 0272/0482, 0353, 0402 across devices, 0425, 0486, 0513, and call/file/own-device-sync rechecks on all three servers; 18 fails are UI gaps ("Not implemented"). All in
runs/2026110[90]-*-aim-vs-*. Batch 3 (#23): 84 runs (70 pass, 14 fail), message extras and own-account sync on all three servers; its two new findings are UI gaps ("Not implemented in aim" below). Batch 4 (#26): 94 runs (75 pass, 13 fail, 6 na), profile, presence, roster, blocking on all three servers (runs/20261110-<ID>-*, IDs 113843–160046): new C47, C48, M30, M31; #1 C12 reproduced; the Gajim empty-nick note withdrawn.2026-11-08: 89 runs with Gajim, Dino, Kaidan (77 pass, 12 fail); 2026-11-09: 39 runs against anotherim-web (37 pass, 2 fail, #11). Every run is agent-judged (
verified_by = "ai",confidence = "low"). Numbering continues #1. Upstream status not checked yet.Fixed upstream column: libtacky v1.2.4–v1.2.7 (2026-11-09/10) name these IDs; anotherim-js develop is on v1.2.7 since 86e54dac (0.8.0). The runs used rc9 / v1.2.3, so every fix awaits a recheck on 0.8.0. Fixed items mentioned elsewhere in this issue: "Also fixed", right under the bug table.
<retract id/>kept beside by default,retract_hint)urn:tacky:push:sealed-signals:0(none yet)<rtcp-mux/>is rejected (Kaidan)Calls: aim's outgoing video never shownurn:tacky:omemo-trust:0: a contact key's change is published only for Undecided → Verified<accept/>/<reject/>/<left/>withheld in an OMEMO room when a member has no OMEMO devicemoderated_by,retract_reason); anotherim-js must show them<delete/>)<nick/>anotherim-web's Contact info keeps the old nickProsody test server hands out no STUN/TURNaes-128-gcm-nopadding:0Also fixed: items mentioned elsewhere in this issue
joinedafter<destroy/>session-infowithunknown-sessionafter a Jingle file transfer (180200)<checksum/>after the last byte (it raced the receiver's terminate)cid:thumbnail unsupported (184517)data:URI (≤16 KiB), sealed when encryptedmod_turn_external)Run links:
https://dev.another.im/another-im/interop/src/branch/main/runs/<dir>/. A bare run ID (Also lines, lists) isruns/20261109-<ID>-*(batch 2 IDs from 000000:20261110-), each with an EVIDENCE.md; 2026-11-08 runs areruns/20261108-<ID>-*(no EVIDENCE.md). Harness and runs came in with #10, #11, #14, #16, #17, #20, #21, #22. #1 rechecks (C34, C30), the features anotherim-js lacks, and untraced observations are under the peer sections.Security / privacy
S14. OMEMO 2: aim's retraction goes out in the clear; Kaidan shows the fallback
<envelope/>); XEP-0424 §4.<retract/>(and its fallback body) inside the SCE<content/>.<retract id=…/>+ "This message was retracted." +<fallback/>outside the encryption in an OMEMO 2 chat, on all three servers (batch 1; on ejabberd the retracted line went out as OMEMO 2 + 0.3). Kaidan keeps the original and shows the fallback as a new message marked Unencrypted. anotherim-web and Gajim (OMEMO 0.3, where the retraction is in the clear too) apply it.steps.logINFO aim sent: <retract/> in clear True, encrypted False.Also batch 0 131521 (anotherim, the same). First seen 2026-11-08: ❌ Kaidan on anotherim 151843 and prosody 151043; ✅ web on ejabberd 203321, prosody 203621, anotherim 222157; ✅ Gajim on ejabberd 141129, prosody 145644, anotherim 133702.
Key stanzas (batch 1; control 131816)
151803 client.log:239the line aim retracts goes out encrypted (0.3 and OMEMO 2);:250its retraction, no<encrypted/>:<retract xmlns='urn:xmpp:message-retract:1' id='1794237639606892'/><body>This message was retracted.</body><fallback xmlns='urn:xmpp:fallback:0' for='urn:xmpp:message-retract:1'/>;peer-kaidan.log:670–:678Kaidan receives it as is.154924 client.log:246,173523 client.log:368;steps.log:37/:40/:49aim sent: <retract/> in clear True, encrypted False. Control 131816:client.log:379clear retraction under 0.3,peer-gajim.log:3503Gajim applies it.S15. OMEMO: reactions, receipts, markers in the clear; file metadata whenever a 0.3 envelope goes out
<reactions xmlns='urn:xmpp:reactions:0'>+<store/>,<received/>and<displayed/>unencrypted in OMEMO 0.3 and OMEMO 2 chats.<media-sharing xmlns='urn:xmpp:sims:1'>(name, media type, size) rides beside the ciphertext whenever a 0.3 envelope goes out: in every 0.3 chat (Gajim, Dino: 6 of 6 runs, all servers) and in OMEMO 2 + 0.3 sends on ejabberd, where vm-kaidan and vm-web still have 0.3 devices. anotherim-web's own file messages leak the same (161932client.log:253), so it is libtacky's. OMEMO 2 alone: nothing beside the envelope (Kaidan and web on prosody and anotherim). All peers still show the pictures.client.logat the cited line:</encrypted>followed by<media-sharing xmlns='urn:xmpp:sims:1'>…<name>paste-….png</name><size>1216</size>; aim's View XML (shot-3) shows the SIMS reference under "Encrypted with OMEMO 0.3" or "OMEMO 2 + 0.3".legacy_file_metadata(default on) in #1.<received/>receipts in the clearAlso batch 1, 0.3: Gajim 151334 (anotherim), 155434 (prosody); Dino 151933 (anotherim), 154657 (ejabberd), 160043 (prosody); the P4 fallback uploads (161341
client.log:457, 173144:270). 2 + 0.3: 162532. ✅ OMEMO 2 only: 151535, 152512, 174225, 174804, 175603. 2026-11-08 (harness †; re-runSERVER=… vms/tools/vmrun.zsh explore vms/examples/xep0444.py s15 <peer>, xep0184.py for receipts): reactions with Gajim 133147, Dino 142139; 0.3 uploads 162721, 160145.Key stanzas (ejabberd: Gajim 154053, Kaidan 155210, web 161932; control prosody 174321)
154053 client.log:242:<encrypted xmlns='eu.siacs.conversations.axolotl'>…<body>I sent you an OMEMO encrypted message…</body><reference …><media-sharing xmlns='urn:xmpp:sims:1'><file …><media-type>image/png</media-type><name>paste-2026-11-09T15-43-25.png</name><size>1216</size>…155210 client.log:283the same beside OMEMO 2 + 0.3;161932 client.log:240aim's,:253web's (<name>image.png</name><size>126984</size>).174321 client.log:252:…</encrypted><body>…</body><encryption xmlns='urn:xmpp:eme:0' namespace='urn:xmpp:omemo:2'/><store xmlns='urn:xmpp:hints'/></message>.140011 client.log:185<reactions xmlns='urn:xmpp:reactions:0' …><reaction>👍</reaction></reactions>(OMEMO 2 chat,:156);131609 client.log:167<received xmlns='urn:xmpp:receipts' …/>(:148).Correctness
C35. MUC: no instant-room configuration after creating a room
muc#ownerform to unlock an instant room), §10.1.1 (a new room is locked until configured).<query xmlns='http://jabber.org/protocol/muc#owner'><x xmlns='jabber:x:data' type='submit'/></query>(or the configuration the user chose).muc#owner. Prosody keeps the room locked ("Room is locked, denying entry") and every other joiner getsitem-not-found: Gajim shows "Failed to Join Group Chat / item-not-found", Dino "Room does not exist". ejabberd and anotherim-server open such rooms anyway: there aim also sends nomuc#owner(0 in every control's client.log), so it is the same behaviour, hidden.muc_room_lock_timeout(default 5 minutes) unlocks the room at the next join after it lapses, still withoutmuc#owner(195222server.log:111619:53:50 →:151719:59:24; 327–356 s in the XEP-0249 runs). The room is not persistent: Prosody deletes it when its last occupant leaves (002115server.log:2103–:2106), so aim's autojoin bookmark leads nowhere. web's rooms (same app) are locked too (224019, 225635). Every batch-2 room run on prosody hit it.steps.log:64,:84)Also batch 2 on prosody: 194144 (Gajim, within the lock window only), 201824 (web, 352 s), 204944 (Gajim, 327 s), 210018 (Dino, 346 s), 210753 (web, 352 s; web's room too), 224019 (web's room, 356 s), 225030 and 225635 (autojoins refused). Batch 0: 125811 (Dino), control 142257. First seen 2026-11-08: ❌ on prosody with Gajim 160636, Dino 172222, web 212252; ✅ on ejabberd and anotherim with all three (harness †).
Key stanzas (prosody 125134, 195222, 002115; control 194543)
125134 client.log:193the room created for aim:<presence from='claude-test-165135@conference.prosody.asxp.io/vm-aim' …><x xmlns='http://jabber.org/protocol/muc#user'><status code='201'/><item affiliation='owner' … role='moderator'/><status code='110'/></x>; nomuc#ownerinclient.log(steps.log:21"room created (201) True, muc#owner submitted False");server.log:1195Room is locked, denying entry;peer-gajim.log:1490<item-not-found …/>.195222 steps.log:21the same;server.log:1291,:1363Room is locked, denying entry(19:55:48, 19:56:24);server.log:1517(19:59:24) Dino's third join creates an occupant,peer-dino.log:2342status 110, participant.002115 server.log:2103"claude-test-042116@conference.prosody.asxp.io" empty, destroying,:2106Deleting claude-test-042116@…; after the restartclient.log:428/:429aim's disco#info of the room, item-not-found at:505,:506.194543 client.log:194status 201, nomuc#owneruntil the destroy; Gajim in the room.C36. Calls: a session-accept without
<rtcp-mux/>is rejected (Kaidan)<rtcp-mux/>is optional); XEP-0338 (BUNDLE grouping optional); RFC 5761.session-terminate.session-initiateoffers<rtcp-mux/>and BUNDLE; Kaidan'ssession-accepthas neither. aim's WebRTC rejects the answer ("Failed to set remote answer sdp: The m= section with mid='0' is invalid. RTCP-MUX is not enabled when it is required", on screen and inclient-tacky.log), sends no terminate, and stays "Ringing…"; Kaidan ends the call withfailed-transportafter ~30 s. Dino's and web's accepts carry<rtcp-mux/>and connect.rtcpMuxPolicytonegotiatewhere available, or answer such an accept withsession-terminate<failed-application/>and tell the user.Also batch 2 000154 (ejabberd); ✅ web on all three (200337, 233237, 000900); batch 0 control 130455. First seen 2026-11-08: ❌ Kaidan on ejabberd 153643 and prosody 175130; ✅ Dino on ejabberd 205011 (harness †).
Key stanzas (125726; batch 2 201136, 232601, 000154)
125726 client.log:226aim's audiosession-initiateoffers BUNDLE and<rtcp-mux/>;:248Kaidan'ssession-accepthas neither (video::326);client-tacky.log:217(video:545):Failed to set remote answer sdp: The m= section with mid='0' is invalid. RTCP-MUX is not enabled when it is required.;client.log:277only Kaidan terminates,<failed-transport/>;rtp.log:2,:102no RTP or DTLS.201136 client.log:384,:465Kaidan's accepts without rtcp-mux;client-tacky.log:244,:603the rejection;client.log:413,:520failed-transport;steps.log:58,:59stun 2 dtls 0/stun 0 dtls 0.232601 client.log:356offer with<rtcp-mux/>,:385accept without;client-tacky.log:284,:630;client.log:410,:511failed-transport.000154 client.log:541;client-tacky.log:217,:546;client.log:652<failed-transport/><text>ICE connection could not be established.</text>.C38. OMEMO 2 with Kaidan: "can't be read" count grows
1794140133942834in four queries).omemo_restart.py(a line each way, 3 restarts, pill read each time, also 6 notches up): the count never changed (0 on all three in batch 1; 2 throughout in batch 0, 134000); each sign-in re-fetches the same 3 archived key exchanges without counting them.steps.log:14,:66) after a discarded XEP-0424 attempt. Kaidan's messages in 151803 look like those in the passing 150810 (client.log:205,:213); which stanzas get counted was not traced.omemo_restart.pywith the XEP-0424 steps.Also 150531 (prosody, read only at the bottom; re-recorded as 153800) and batch 0 134000 (2 throughout). First seen 2026-11-08 (Kaidan, harness †): ejabberd 124708 (4), 122920 (3); prosody 123333 (3), 121829; anotherim 122631 (2).
Key evidence (150810, 173523; 2026-11-08 124708)
150810 steps.log:35…:122aim undecryptable (n, failed) start: (0, 0)…restart-3: (0, 0);:111archived kex messages fetched again across sign-ins: [('1794237037887154', 3), ('1794237040310281', 3), ('1794237096097015', 3)].173523 steps.log:14before: (4, 4),:66after: (4, 4).124708 client.log:132,:141,:239,:250one archived Kaidan message from MAM queries…-2to-5:<result xmlns='urn:xmpp:mam:2' id='1794140133942834' …><key kex='true' rid='989476894'>….C39.
Calls: anotherim-js's outgoing video never shown on the other side(withdrawn, harness)f45e5c5) the web shows aim's live test card (133803, shot-10). Batch 2: aim's card shown by Dino and web on all three servers (195624, 231837, 235447, 200337, 233237, 000900).C40. XEP-0448: aes-256-cbc-pkcs7 shares are not decrypted; a URL-named card, Download keeps the ciphertext
aes-128-gcm-nopadding:0,aes-256-gcm-nopadding:0,aes-256-cbc-pkcs7:0; CBC: 256-bit key, 128-bit IV).pic-…-kaidan.pnginline.urn:xmpp:ciphers:aes-256-cbc-pkcs7:0(its only one), plus the ciphertext's URL as body and OOB. aim ignores the CBC source and falls back to the URL: a card named after its last segment (5tguSQyso9), and Download saves the ciphertext without an error. All three servers. aim's record keeps the share's name and hashes; only the cipher is missing.file.tclesfs_url, L2919–L2931 reads only the two GCM ciphers ("aes-256-cbc-pkcs7 is not read").steps.log:117); its first 16 bytes decrypt to the announced sha-256 (155852steps.log:117–:118). CBC support alone won't open Kaidan 0.16's files unless libtacky tolerates that IV.urn:xmpp:esfs:0source with the CBC cipher.aes-256-cbc-pkcs7:0(taking a 32-byte IV's first 16 bytes, or reporting it); when a share can't be opened, say so on the card (the share's name, "can't decrypt") instead of offering the ciphertext.Also 153241 (anotherim, "fjosqIUewW") and the same card in the XEP-0454 runs with Kaidan (155210 "MoKmgqSiig", 151535, 152512; 2026-11-08 163656, 183515; batch 0 131002).
Key evidence (153012, 153241, 155852)
153241 peer-kaidan.log:562Kaidan's slotfilename="fjosqIUewW" size="126992"(PNG 126984 B, padded).153012 steps.log:112aim's record:<file-sharing xmlns='urn:xmpp:sfs:0'> … <name>pic-193013-kaidan.png</name> … <encrypted xmlns='urn:xmpp:esfs:0' cipher='urn:xmpp:ciphers:aes-256-cbc-pkcs7:0'>;:103the card with Download;:117key 32 iv 32,Invalid IV size (32) for CBC.155852 steps.log:117–:118kaidan's announced sha-256 […] = the fetched plaintext's: True(IV[:16]).C41. XEP-0448: aim's sent picture has no esfs source (aesgcm:// + SIMS only)
<encrypted xmlns='urn:xmpp:esfs:0' cipher=…>with key, IV and the inner source).<url-data target='aesgcm://…#key'/>(174804steps.log:77). web's picture (same build) has an aes-256-gcm esfs source, which aim decrypts and shows. web reads aesgcm, so aim's picture still shows there.message.tclEsfsSource/EncryptedShareNodes, L5045–L5093); the desktop paste path evidently doesn't reach it.urn:xmpp:esfs:0; shot-6 (View XML of web's): anurn:xmpp:esfs:0source,cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding:0', key and IV.Also 162532 (ejabberd, plus S15's clear SIMS).
Key evidence (174804, 175603)
174804 client.log:392aim's message, OMEMO 2 only;steps.log:77its record:<file-sharing xmlns='urn:xmpp:sfs:0' …> … <sources> <url-data … target='aesgcm://…/paste-2026-11-09T17-50-27.png#…'/> </sources>;:127–:130web's shareaes-256-gcm-nopadding:0,key 32 iv 12, sha-256 verified.175603 client.log:255aim's picture (record aesgcm:// + SIMS, shot-3);client.log:267,steps.log:127,:130web's share decrypted and verified.C42.
urn:tacky:omemo-trust:0: a contact key's change is published only for Undecided → Verifiedurn:tacky:omemo-trust:0(libtackydocs/protocol/omemo-trust-0.md,docs/features.md): every user trust decision (omemo trustwithout-blind) is published sealed to the own devices.<publish node='urn:tacky:omemo-trust:0'>→ web, signed in as vm-aim with aim's device Verified, applies it.client.log:246,:270,:283);omemo-chats:0syncs on all three servers.steps.logaim set #… from Accepted to Verified, thenaim published urn:tacky:omemo-trust:0: 0/False; web got its event: False; no<publish node='urn:tacky:omemo-trust:0'>after it inclient.log/server.log.Also ✅
omemo-chats:0: 181559 (ejabberd), 193707 (anotherim), 235706 (prosody).Key evidence (182653, 002914; control 194814)
182653 steps.log:134aim lists vm-gajim@ejabberd.asxp.io's keys [('170', 'Accepted')];:169aim set #170 from Accepted to Verified;client.log:25,:75the only omemo-trust traffic: the sign-in fetch (item of 18:22:08).002914 steps.log:185aim sets the key Accepted → Verified;:187aim published urn:tacky:omemo-trust:0: False; web got its event: False;server.log:1382the only omemo-trust stanza, the sign-in fetch, none through the restore at 00:38:37 (steps.log:208) to the end (00:39:49).194814 steps.log:182aim set #193428444 from Undecided to Verified;client.log:424<publish node='urn:tacky:omemo-trust:0'><item id='current'>(19:53:50), acked:426;peer-anotherim-web.log:406web's event;steps.log:203PASS web lists #193428444 Verified.C43. XEP-0482: aim's
<accept/>/<reject/>/<left/>withheld in an OMEMO room when a member has no OMEMO device<accept/>/<reject/>,<left/>on leaving, to the chat the invite came from).<reject id=…/>to the room, so Dino stops inviting aim; joining and leaving send<accept/>and<left/>. The invitation came in the clear, so a clear answer leaks nothing new.<invite xmlns='urn:xmpp:call-invites:0' multi='true'>arrives in the clear. After Decline aim's card reads "Declined", but libtacky finds no OMEMO device for vm-dino and withholds the<reject/>rather than send it in the clear; aim's room shows "Not sent: it could not be encrypted for vm-dino (no device with OMEMO keys)". Dino never learns of it. Joining works (Muji is presence and Jingle), but<accept/>and<left/>are withheld the same way. In web's unencrypted rooms all three go out.client-tacky.log:21; nourn:xmpp:call-invites:0stanza from aim inclient.logafter the click.<reject/>withheld, "Not sent" banner, card "Declined"client-tacky.log:21<reject/> withheld<reject/>goes to the room, web gets itAlso the XEP-0272 runs with Dino, which pass on the call itself: 205652 and 001757 (accept and left withheld).
Key evidence (002620, 210351, 205652; control 004557)
002620 client.log:653Dino's invitation in the clear:<invite xmlns='urn:xmpp:call-invites:0' … multi='true' video='false'><muji xmlns='urn:xmpp:jingle:muji:0' room='b34172aa@conference.ejabberd.asxp.io'/></invite>;steps.log:61Decline clicked.002620 client-tacky.log:20OMEMO claude-test-042621@conference.ejabberd.asxp.io: not sent; no usable device for vm-dino@ejabberd.asxp.io:no_devices;:21groupcall: <reject/> withheld: no member of claude-test-042621@conference.ejabberd.asxp.io can receive an encrypted call invite, and it is not sent in the clear.210351 client.log:517the clear invite;client-tacky.log:21(21:08:15.313) the same<reject/> withheld.205652 client-tacky.log:21groupcall: <accept/> withheld: …(21:01:00),:537<left/> withheld: …(21:01:44);001757 client-tacky.log:21,:424likewise.004557 client.log:569<message … to='claude-test-044557@conference.ejabberd.asxp.io' type='groupchat'><reject xmlns='urn:xmpp:call-invites:0' id='6c7d2f21bda9a91ad9840a124e521147'/><store xmlns='urn:xmpp:hints'/></message>;peer-anotherim-web.log:334web gets it.214007 client.log:509<accept/>,:613<left/>in web's room.C44. Muji group call: anotherim-web hears nothing from aim (opus arrives, level 0)
groupcall.start, no UI), aim joins from its card and opens a Jingle session to web. aim hears web (1.00); web hears nothing (0.00), though aim's opus reaches web's NIC at full rate (403 packets / 8 s) and web's getStats counts it withaudioLevel0,energy0. Not the autoplay policy (--autoplay-policy=no-user-gesture-required). The pair's 1:1 calls play both ways, and Dino hears aim in a group call. Whether aim sends silence on this leg or web doesn't render the track is not traced; both ends are anotherim-js.steps.logweb hears 440 Hz: 0.00; web's NICin rtp opus/111 … 403 packets; web's getStats line with"audioLevel":0,"energy":0.audioLevelin this call with the 1:1 call, and web's inbound track's attachment to an audio element in the group-call view.web-rtp.log:193 packets,audioLevel0Also ✅ 205652 (Dino, anotherim), 200337 (1:1 with web, anotherim).
Key evidence (003642, 214007)
003642 client.log:452web's invitation,:668aim'ssession-initiateto web,:689web'ssession-accept;steps.log:57,:58aim hears 660 Hz: 1.00,web hears 440 Hz: 0.00.003642 rtp.log:16web's NICin rtp opus/111 ssrc bed035e4: 403 packets 64778 bytes in 8s(its own out,:20);:24{"type":"inbound-rtp","kind":"audio","bytes":135855,"packets":1693,"lost":0,…,"audioLevel":0,"energy":0}, rising at:25.214007 steps.log:59aim hears 660 Hz True (1.00); web hears 440 Hz False (0.00);:62,:63out opus/111 403; … in opus/111 403on both NICs;web-rtp.log:9"inbound-rtp","kind":"audio",…"packets":2060,…"audioLevel":0,"energy":0.C45. MUC: membership and ban sent with the occupant's full JID; Prosody refuses them silently
<item affiliation='member|outcast' jid='vm-gajim@…'/>with the bare JID.jid='vm-dino@prosody.asxp.io/interop') for membership and ban in every batch-2 admin run. Prosody refuses both (jid-malformed, "Bare JID expected, got full JID"): nobody is banned and aim shows no error. ejabberd and anotherim-server apply them (301) to one resource. Nick-based steps (subject, roles, kick, destroy) work.client.logthemuc#admin<item affiliation='outcast' jid='…/resource'>; on prosody thetype='error'answer with<jid-malformed/>right after it; aim's screen unchanged.muc#adminto the user.Also 201047 (ejabberd, Dino), 204649 (ejabberd, web), 221811, 225948 (anotherim, Gajim), 224559 (anotherim, web); 194144 never got that far (C35). No ✅ control: the spec is the comparison; the server's error is the proof on prosody.
Key stanzas (195222, 201824, 194543)
195222 client.log:285<item affiliation='member' jid='vm-dino@prosody.asxp.io/interop'/>;:286Prosody:<iq … type='error'><error type='modify'><jid-malformed …/><text>Bare JID expected, got full JID</text>;:310<item affiliation='outcast' jid='vm-dino@prosody.asxp.io/interop'><reason>kiwi ban</reason></item>, refused at:312;steps.log:113no 301.201824 client.log:325/:351membership and ban withjid='vm-web@prosody.asxp.io/another.im (Js)~…', refused at:327/:353.194543 client.log:270<query xmlns='http://jabber.org/protocol/muc#admin'><item affiliation='member' jid='vm-gajim@ejabberd.asxp.io/gajim.QS09QHG1'/></query>;:294<item affiliation='outcast' jid='vm-gajim@ejabberd.asxp.io/gajim.QS09QHG1'><reason>kiwi ban</reason></item>;peer-gajim.log:2972status 301.223151 client.log:592,:689the same withvm-dino@anotherim.asxp.io/interop;peer-dino.log:8619301.C46. Mediated room invite: a second 1:1-looking chat of the room's JID; on Prosody no invitation card
<message/>from the room's bare JID carrying<x xmlns='http://jabber.org/protocol/muc#user'><invite from=…/>).jabber:x:conference).<invite/>to the invitation card only, not to a chat; accept it on Prosody's relay.Also 204649 (shots 8, 9), 224559 (shot 2), 001757 (aim's call card in that chat), 000658 (the room's picture on it).
Key evidence (211510, 210753, 205652)
211510 client.log:338web's invitation as aim receives it from the room:<invite from='vm-web@ejabberd.asxp.io/another.im (Js)'/>;peer-anotherim-web.log:52aim's to web; EVIDENCE "Seen": web two "claude-test-011510" rows, aim two "claude-test-011510b" rows and a "claude-test-011510c" chat with an unread badge after Decline.210753 client.log:287aim's mediated invite;peer-anotherim-web.log:112Prosody's relay with an addedjabber:x:conference; web's first presence to the room ispeer-anotherim-web.log:165, its join by address after 352 s (steps.log:85).224019 client.log:239web's invitation reaches aim; aim's only joinclient.log:296, by address after 356 s (steps.log:83).205652 client.log:482Dino's mediated invite from the room's bare JID; shot-2 two "claude-test-005653" rows.C47. XEP-0054: aim writes its profile only as XEP-0292 vCard4, never vcard-temp; Kaidan reads an empty card
<iq type='set'><vCard xmlns='vcard-temp'/>and read by others with a get to the bare JID); XEP-0292 §5 leaves the vcard-temp mirror optional.<publish node='urn:xmpp:vcard4'>…<fn><text>aim Mango</text></fn>; aim sends no vcard-tempsetin any run. ejabberd and anotherim-server keep the two apart, so Kaidan's vcard-temp get for vm-aim returns<vCard xmlns='vcard-temp'><NICKNAME/></vCard>and Kaidan keeps calling it "vm-aim". Prosody maps vCard4 to vcard-temp, so there Kaidan gets<FN>aim Mango</FN>and the bug is hidden. Gajim and web read vCard4 (their XEP-0054 runs pass on all three). The other direction works everywhere: aim reads Kaidan's vcard-temp FN "kaidan Mango".client.logaim's Save: aurn:xmpp:vcard4publish and novcard-tempset after it;peer-kaidan.logKaidan's vcard-temp get of vm-aim answered without FN; Kaidan's shot-2: its chat with "vm-aim", no name.<NICKNAME/><FN>aim Mango</FN>; aim shows "kaidan Mango"Also ✅ (vCard4 readers): Gajim 121041 (anotherim), 120250 (prosody); web 142654 (ejabberd), 140411 (anotherim), 141505 (prosody). On prosody Kaidan's Contact Details drew nothing (
155057 steps.log:54,:56), so its display of the name there is unshown; the wire decides.Key evidence (152828, 152203; control 155057)
152828 client.log:531aim's<publish node='urn:xmpp:vcard4'>…<fn><text>aim Mango</text></fn>;peer-kaidan.log:1872Kaidan's<vCard xmlns="vcard-temp"/>get of vm-aim while the name is set,:1880ejabberd's answer<vCard xmlns="vcard-temp"><NICKNAME/></vCard>;peer-kaidan.log:1849Kaidan's own set with<FN>kaidan Mango</FN>,client.log:566aim reads it.152203 client.log:601the vCard4 publish, no vcard-temp set after it;peer-kaidan.log:1346Kaidan's get,:1355<vCard xmlns="vcard-temp"><NICKNAME/></vCard>;peer-kaidan.log:1321Kaidan's FN,client.log:630,:637aim reads it.155057 client.log:411the same vCard4 publish;peer-kaidan.log:1268Kaidan reads<FN>aim Mango</FN>from Prosody's mapping.C48. XEP-0191: after an unblock libtacky never refetches the OMEMO device list that failed while blocked
urn:xmpp:omemo:2:devicesand legacy device list for the first time in its session; Prosody answers bothservice-unavailable, and web's "while blocked" line is not sent: "no devices on vm-aim@prosody.asxp.io's v2 or legacy device lists". aim unblocks (pushed); a minute later web types "after unblock": no new device-list fetch, the same error, the line never reaches aim. The failed fetch is kept as "no devices" and only an event or a new session would replace it. aim's block and unblock themselves work.143450 peer-anotherim-web.log:207,134439 :340), so web encrypts, the server bounces the messageservice-unavailable(XEP-0191 §3.3), and "after unblock" arrives. Gajim on prosody, with aim's devices fetched before the block, passes (125018).peer-anotherim-web.logno device-list get to vm-aim after:158. The "after unblock" failure has no shot in the run (failed-blocking-web.pngstayed in the out dir);steps.log:68is the proof.service-unavailablewhile blocked, never refetched; "after unblock" fails "no devices"Also ✅ XEP-0191 with Gajim 123324 (ejabberd), 114810 (anotherim); Dino 155048 and Kaidan 155601 (ejabberd only).
Key evidence (143456; controls 143450, 134439)
143456 client.log:325aim's<block xmlns='urn:xmpp:blocking'><item jid='vm-web@prosody.asxp.io'/>,:343its<unblock …>,:351the push.143456 peer-anotherim-web.log:157,:158web's gets of vm-aim'surn:xmpp:omemo:2:devicesandeu.siacs.conversations.axolotl.devicelist;:160,:161both<error type='cancel'><service-unavailable …/>; no later get to vm-aim.steps.log:36web sent nothing while blocked,:62web types "prf 183457 after unblock" (14:40:12, aim unblocked 14:39:24),:68FAIL blocking: AssertionError: web: no message to vm-aim@prosody.asxp.io in web.log after 60s.143450 peer-anotherim-web.log:204,:205web's gets while blocked,:207,:210ejabberd answers with the items;client.log:504"after unblock" arrives.134439 peer-anotherim-web.log:337,:338gets,:340,:343items;:357the bounce.Minor / SHOULD
M26. No desktop notification while aim's window has focus
notify-aim.log. With the window minimized aim does notify (notify-aim.log:5in both batch-0 runs). Receipts and displayed markers work both ways.notify-gajim.log:5) and with another chat open (:34), so aim differs from Gajim. Dino doesn't notify while focused (125832).vms/AGENTS.md).First seen 2026-11-08 (harness †): ❌ Gajim ejabberd 125251, Kaidan ejabberd 131609, Gajim prosody 123644; ✅ aim minimized with Gajim anotherim 123358 and web ejabberd 201534.
Key evidence (ejabberd × Gajim, 140003)
140003 notify-aim.log:5aim's only Notify, while minimized (14:06:46);steps.log:77focused with Saved messages open:0 Notify call(s);:44chat closed:aim: no notification.notify-gajim.log:34Gajim, focused with another chat open, notifies (also:5,:63). 141044steps.log:57,:95the same for aim;notify-aim.log:5minimized notifies.M27. "View XML" shows OMEMO 2 messages with the 0.3 EME namespace
namespacenames the encryption actually used).urn:xmpp:omemo:2.<encryption xmlns='urn:xmpp:eme:0' namespace='eu.siacs.conversations.axolotl'/>under the dialog's own heading "Encrypted with OMEMO 2"; on the wire the same message was a single OMEMO 2 envelope with EMEurn:xmpp:omemo:2.tacky/xmpp/modules/message.tcl#L4764the readable-record branch writes the marker unconditionally,j encryption -ns urn:xmpp:eme:0 -namespace eu.siacs.conversations.axolotl(comment: "the profile is not known here, as nothing was encrypted"), while the wire branch a few lines up (L4755–4756) picks v2 or legacy.chats.tcl:276–277does it right (v2 when the profiles include it).omemo::ns v2|legacy, as the wire branch does).steps.log:62).namespace='eu.siacs.conversations.axolotl'.urn:xmpp:omemo:2; View XML's stored recordeu.siacs.conversations.axolotlAlso batch 1 (
FAIL View XML names the encryption used on the wire: stored eu.siacs.conversations.axolotl, wire ['urn:xmpp:omemo:2']):151535 steps.log:56,152512 steps.log:62,153012 steps.log:62,153241 steps.log:62,174225 steps.log:81,174804 steps.log:81,175603 steps.log:81. First seen 2026-11-08: anotherim 152430 (View XML seen by hand after the run, not recorded). No ✅ control: the wire of the same message is the comparison.Key evidence (anotherim-server × Kaidan, 131002)
131002 client.log:365on the wire:<encrypted xmlns='urn:xmpp:omemo:2'>…<encryption xmlns='urn:xmpp:eme:0' namespace='urn:xmpp:omemo:2'/>;steps.log:52View XML of the same id:<encryption xmlns='urn:xmpp:eme:0' namespace='eu.siacs.conversations.axolotl'/>;:56FAIL View XML names the encryption used on the wire.M28. anotherim-web shows no desktop notification for messages or calls
notify-web.loghas no Notify call at all. In the same run desktop aim, minimized, did notify (notify-aim.log:5). Incoming calls only show the in-app "Incoming call" sheet (2026-11-08).First seen 2026-11-08 (harness †): web on ejabberd 201534, prosody 201743, anotherim 205250; call: only the in-app sheet, ejabberd 220703 (shot-2-web-ringing).
Key evidence (ejabberd × anotherim-web, 141044)
141044 notify-web.log:1–:4the whole capture: nomember=Notify, though web got aim's lines with the chat closed (steps.log:23), focused (:124) and minimized (:168).notify-aim.log:5the desktop build, minimized, notifies web's line (14:19:03);steps.log:21,:34,:55,:68receipts and markers both ways.M29. XEP-0425: a moderated message shows as "Message retracted", without moderator or reason
by=, and carries the<reason/>for the client to show).:0<apply-to>,:1in<retract/>) withby='…/vm-gajim'and "kiwi spam", removes the text, and shows the plain "Message retracted · Show history" row of a self-retraction. The same with web moderating (web shows that row too). libtacky's<Retracted>carriesmoderated_byandreason(per the EVIDENCE), so the gap looks like anotherim-js's display.Also 001141 (anotherim, web). Prosody: na, its MUC has no
mod_muc_moderation(214403peer-gajim.log:3137, nourn:xmpp:message-moderatein the room's disco#info). The control is Gajim's own display in the same run.Key stanzas (214417, 233507)
214417 peer-gajim.log:5487<moderate xmlns="urn:xmpp:message-moderate:1" id="1794260806414398"><retract xmlns="urn:xmpp:message-retract:1" />…;client.log:337<apply-to … id='1794260806414398'><moderated xmlns='urn:xmpp:message-moderate:0' by='claude-test-014417@…/vm-gajim'><retract …/><reason>kiwi spam</reason></moderated></apply-to><retract xmlns='urn:xmpp:message-retract:1' id='1794260806414398'><reason xmlns='urn:xmpp:message-moderate:1'>kiwi spam</reason><moderated … by='…/vm-gajim'/></retract>.233507 client.log:669the same notice;steps.log:54PASS aim no longer shows the papaya line.230307 peer-anotherim-web.log:260web's<moderate xmlns='urn:xmpp:message-moderate:1' …><retract …/><reason>kiwi spam</reason></moderate>;client.log:483aim gets it withby='…/vm-web'.M30. XEP-0084: aim keeps a contact's avatar after the contact deletes its metadata node
<metadata/>for "no avatar"; XEP-0060 §8.4 (a node delete is notified with<delete/>): a deleted metadata node leaves no avatar to show.<event><delete node='urn:xmpp:avatar:metadata'/></event>from a contact aim drops its picture and draws the letter, as it does for Gajim's empty<metadata/>(114916).<delete/>and 11 s later still draws Dino's colour bars in its list. On ejabberd and anotherim-server Dino sends the same owner<delete/>(150119 peer-dino.log:5273,144950 :7401) but aim'sclient.loghas no event for it, so aim can't know; M30 is judged on prosody only. The runs pass on their scenario (avatars cross both ways); this was outside it. It also kept 150320 (XEP-0392 with Dino, anotherim) from comparing colours.150252 client.log:634the<delete node='urn:xmpp:avatar:metadata'/>event from vm-dino; aim's shot-3: vm-dino still with the bars.<delete/>(and a<purge/>or retract of the current item) as "no avatar".<delete/>of Dino's metadata node received; aim keeps the bars<metadata/>(client.log:576); aim draws the letterKey evidence (150252)
150252 client.log:520Dino's metadata<info bytes='994' … id='24261029d02cd84f6634bf898c429ef5cb5eac22' type='image/png'/>,:525aim fetches the data;peer-dino.log:3693Dino's owner<delete node='urn:xmpp:avatar:metadata'/>,:3703the event it gets back;client.log:634(15:06:45) aim's<message from='vm-dino@prosody.asxp.io' type='headline'><event xmlns='http://jabber.org/protocol/pubsub#event'><delete node='urn:xmpp:avatar:metadata'/></event></message>;steps.log:61shot-3 at 15:06:56.M31. XEP-0172: after an empty
<nick/>anotherim-web's Contact info keeps the old nick (anotherim-js UI)<nick/>: the user no longer has a nickname).<nick xmlns='http://jabber.org/protocol/nick'/>and (ejabberd, anotherim) an empty<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'/>; web receives both. web's chat row and header go back to "vm-aim", but its Contact info keeps the title "Aim Kiwi", an "A" letter and "Nickname Aim Kiwi", still 45 s later (anotherim). Sending is right: Gajim drops the nick on all three servers. Recorded as libtacky (noappcause yet); the stale field is anotherim-js's Contact info, so aim would show it the same way.Also ✅ Gajim 115550 (ejabberd), 120417 (anotherim).
Key evidence (142149, 140954, 135836)
142149 client.log:576<nick …>Aim Kiwi</nick>,:675vCard4<nickname><text>Aim Kiwi</text></nickname>;:823the empty<nick xmlns='http://jabber.org/protocol/nick'/>,:935the empty<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'/>;peer-anotherim-web.log:357,:364web receives both.140954 client.log:639the empty nick,peer-anotherim-web.log:273web gets it;steps.log:74,:85web's Contact info 10 s later.135836 client.log:1088,:1194empty nick and vCard4;peer-anotherim-web.log:565(14:01:55),:573(14:01:57),:579web's own fetch answers the empty nick again;steps.log:85the Contact info shot at 14:02:41.To report upstream (peer bugs)
P1. Kaidan 0.16: "Transfer failed: Checksum does not match" on aim's OMEMO 2 upload
WHxhFjkD…) = the decrypted upload's (1216 B) = the hash Kaidan stored; the ciphertext's iscKzooa5Q…. Kaidan compares with other bytes. anotherim-web shows the upload inline.steps.logkaidan's stored hash(es) ['WHxhFjkD…']: equal the plaintext's True, the ciphertext's False.Also batch 1 152512 (anotherim, OMEMO 2 only). First seen 2026-11-08 (harness †): ❌ Kaidan on anotherim 152430 (hash checked by hand), ejabberd 163656, prosody 183515; ✅ Gajim (OMEMO 0.3, no hash checked) ejabberd 160145, web ejabberd 214312.
Key stanzas (anotherim-server × Kaidan, 131002)
131002 client.log:354slot for 1232 B (1216 + GCM tag);steps.log:59Kaidan's record'error': 'Transfer failed: Checksum does not match', … 'size': 1216, … 'path': None;:61–:64plain 1216 B sha256 WHxhFjkD…,PASS aim announced the plaintext's sha-256,kaidan's stored hash(es) ['WHxhFjkD…']: equal the plaintext's True, the ciphertext's False.155210 steps.log:66,:69–:70;151535 steps.log:60,:62–:64;152512 steps.log:66,:68–:70.P3. Dino 0.5.1 intermittently sends no audio in calls
senders='both'and then sends no audio RTP).rtp.log; check dino#1487 and open audio issues first.Also ✅ batch 0 130351 (prosody), 131143, 131724 (ejabberd). First seen 2026-11-08 (harness †): ❌ ejabberd 204146 (both calls), 152129, 152700; ✅ ejabberd 205011, 205746, anotherim 202351.
Key evidence (132256; batch 2 231837, 235447)
132256 steps.log:85/:86aim hears 660 Hz: 0.00 …,dino hears 440 Hz: 0.99 …;rtp.log:164Dino's NICout rtp VP8/96 ssrc 3328a7d0: 259 packets …;rtp.log:161out rtcp rtcp ssrc 290fc134: 2 packets 280 bytes in 8s;peer-dino.log:3645Payload for audio with opus using ssrc 688898356(= 0x290fc134);rtp.log:275–:281Dino's Record Stream uncorked.231837 steps.log:87aim hears 0.00 in the video call;rtp.log:11Dino's SSRC b1a22cd3 RTCP only on aim's NIC,rtp.log:161the same on Dino's,rtp.log:162VP8 out; aim sends VP8 1506 and opus 402 (rtp.log:16,:17), Dino receives both (:158,:159).235447 steps.log:47,:48aim 0.00, Dino 0.99 in the audio call;steps.log:57Dino's NICout rtcp 2; in rtcp 2; in opus/111 400;peer-dino.log:3478Using FakeMic for outgoing audio as it's default;steps.log:87,:88the video call 1.00 / 1.00.P4. Dino 0.5.1 rejects aim's JET cipher
urn:xmpp:ciphers:aes-128-gcm-nopadding:0cipher='urn:xmpp:ciphers:aes-128-gcm-nopadding'(what Dino knows).feature-not-implemented"JET cipher or type unknown"; JET never runs. aim falls back to an OMEMO aesgcm upload, which Dino saves with the right sha-256. All three servers.steps.logFAIL it went over Jingle, no upload.urn:tacky:jingle:jet-omemo:2, aes-256-gcm) to web: sent directly, no uploadAlso 163331 (prosody, the same).
Key stanzas (161341, 163331, 173144; control 173948)
161341 client.log:399aim's offer<security xmlns='urn:xmpp:jingle:jet:0' cipher='urn:xmpp:ciphers:aes-128-gcm-nopadding:0' name='file' type='eu.siacs.conversations.axolotl'>;peer-dino.log:4625–:4629<feature-not-implemented …/><text …>JET cipher or type unknown.163331 client.log:260,:265,:313offer, error, fallback slot;steps.log:53,:55.173144 client.log:217,:224. Control173948 client.log:216cipher='urn:xmpp:ciphers:aes-256-gcm-nopadding:0' … type='urn:tacky:jingle:jet-omemo:2',:267success.P5. Dino 0.5.1 rejects aim's IBB transport-replace after losing the tie-break (plain Jingle file transfer)
<conflict/><tie-break/>; Dino then transport-rejects aim's IBB replace and aim ends withfailed-transport. Dino stays at "Downloading 1 kB… (0%)". On prosody and anotherim-server the proxy65 is reachable and the same script passes, so P5 shows only where P6 forces the IBB fallback.client.logDino'saction='transport-reject'after aim's<tie-break/>.client.log:248–:262; check open issues first.Plain Jingle files to anotherim-web pass on all three servers over the WebRTC data channel (173433, 180200, 180009), also with OMEMO-sealed DTLS fingerprints (174347).
Key stanzas (163129)
163129 client.log:228aim's offer with candidateshost='10.0.2.15' … type='direct'andhost='127.0.0.2' jid='proxy.ejabberd.asxp.io/55238004' port='7777' … type='proxy';:241,:247<candidate-error/>both ways;:248,:254both transport-replaces;:255aim<tie-break/>;:260Dinoaction='transport-reject'(IBB);:262aim<failed-transport/>.Gajim 2.6 keeps the old nick after an empty(withdrawn, not reproduced)<nick/><nick/>Gajim logs the removal and shows plain "vm-aim": ejabberd 115550peer-gajim.log:6871Received nickname: vm-aim@ejabberd.asxp.io - nickname removed,:6902Nickname for vm-aim@ejabberd.asxp.io: None(shot-3); prosody 115749peer-gajim.log:3986,:4017(shot-3); anotherim 120417peer-gajim.log:4634the event,:4649"nickname removed",:4680None(shot-3). The stale nick seen in batch 4 is anotherim-web's Contact info (M31).Server issues and peer notes
client.log:228host='127.0.0.2' … port='7777' … type='proxy',server.log:33754. Controls: prosody's proxy (162820client.log:261) and anotherim-server's178.105.240.144:7777(160833client.log:403) carry the file. Config:nix/ejabberd.nix#L96mod_proxy65: { access: local, max_connections: 5, port: 7777 }names no public address; setting itshostname/ipshould fix it (not tried).mod_turn_external): 130351client.log:232extdisco STUN/TURN,:244relay candidates, tones both ways. Batch 2: every prosody call run used relay candidates (231837, 232601, 233237). Before:service-unavailable(2026-11-08 174618client.log:191).mod_muc_moderationnot loaded): 214403peer-gajim.log:3137(nourn:xmpp:message-moderatein the room's disco#info), verdict na. Loading it would make M29 checkable on all three.urn:xmpp:mentions:0in nbxmpp 7.4.0 or gajim/); Dino 0.5.1 has no XEP-0425 and no XEP-0513. XEP-0513 therefore ran only aim ↔ web (232223, ejabberd, pass).cid:thumbnail unsupported); one click fetches it with the right sha-256. 184517 (peer-dino.log:2504,steps.log:53) and 162123 pass with the click; 160550 is superseded.vms/README.mdKnown gaps), upstream unchanged (the user's decision).to; aim still shows the quote.session-infowithunknown-session, having already terminated (180200client.log:305,:315); the file had arrived.precondition-not-met, then reconfigures; 232823peer-gajim.log:23922); bookmark sync still passes.sender, which attaches nothing (the harness flips it to storealways); anotherim-web sends its own links without a card (itslinkmeta previewthrew in the browser, likely CORS, not traced); unmuting a room writes<on-mention/>rather than removing the setting; aim's caps lackurn:xmpp:mds:displayed:0+notify, it still gets the events (own-JID PEP). To OMEMO 0.3 peers (Gajim) libtacky attaches no link preview, and stickers and contact cards go only as their fallback text, as its docs say.urn:xmpp:avatar:metadatanode instead of publishing an empty<metadata/>(XEP-0084 §4.5):150252 peer-dino.log:3693,150119 :5273,144950 :7401(aim's side is M30). And it ignores aim's empty<metadata/>: it receives it (150119 peer-dino.log:5227,144950 :7355) and keeps drawing aim's removed gradient. That made 150320 (XEP-0392, the batch's only peer fail) unjudgeable: no letter avatars to compare (shot-3); aim's own colour is right (264.4° for 264.3°).<photo/>, 152606peer-kaidan.log:270); aim gets its picture through Prosody's XEP-0084 mapping and the vCard. On ejabberd and anotherim-server it did advertisea2dfb30a…after setting the picture (152328client.log:600, 151643client.log:647), so this is Prosody-only (or timing), not "never".<metadata/>(a UUID) as the vCard photo hash: 115336server.log:776<x xmlns='vcard-temp:x:update'><photo>df9f11bc-c4e6-4b56-a11e-9dc4fdf71744</photo></x>in aim's room presence, Gajim:advertised invalid avatar hash(peer-gajim.log:1873). And it keeps the XEP-0084 avatar it derived from a vCard PHOTO after the PHOTO is removed: aim still draws Kaidan's old picture in 154800 (shot-1). Its vCard4↔vcard-temp mapping is what hides C47 there.urn:xmpp:reporting:1, so aim rightly offers only a plain block: ejabberd 131044client.log:69, 143949; prosody 125559client.log:74, 144447; anotherim 115526client.log:110, 135027.#1 rechecks (fixed upstream)
autojoin='false'and doesn't recreate the room after a restart: prosody 194144client.log:289, ejabberd 194543client.log:311(steps.log:121), anotherim 221811client.log:622(steps.log:124), and every other admin run.steps.log:150Remove False, Go to the new room False, Join False, shot-11, shot-13. Already commented: anotherim-js#95 (comment).client.log:457<decline to='vm-web@ejabberd.asxp.io/another.im (Js)'/>(peer-anotherim-web.log:327); 232627client.log:741; 210455client.log:294; 204944client.log:321.client.log:685,peer-anotherim-web.log:1142(shot-7); 034631, 031016.<x xmlns='vcard-temp:x:update'><photo>0a69a94cf904a6231fcbb36ef413a2ff8b4a6993</photo></x>23–233 ms before the result of its own<vCard xmlns='vcard-temp'/>get (XEP-0153 §4.2 MUST NOT);steps.logFAIL C12: no photo hash in aim's presence before its own vCard is read. ejabberd Dino 150544client.log:701presence,:760own vCard result; ejabberd Kaidan 152328client.log:673presence,:717own vCard result; prosody Dino 150721client.log:549presence,:571own vCard result; prosody Kaidan 152606client.log:593presence,:620own vCard result; anotherim Dino 145421client.log:746presence,:834own vCard result; anotherim Kaidan 151643client.log:710presence,:798own vCard result. The vCard avatar exchange itself passes both ways in all six. The Gajim and web XEP-0153 runs (115138, 115336, 122058, 140510, 141359, 141718) predate the restart check and signed in without an avatar, so they don't exercise C12.<advanced/>, so there is nothing to keep; the plain mute syncs (042801, 045211, 042110). libtacky 1.2.4 7912074c touches this.Not implemented in aim (anotherim-js rc9 UI gaps: libtacky can, aim's UI can't; the runs judged them fail, not counted as bugs)
Missing features, like the peers'
lacksinclients.toml: libtacky has the call (web used its API in the harness). Filing them as feature requests is open.muc direct_inviteis not in the app's API or UI. Receiving XEP-0249 works (card, Accept, Decline). aim answers a direct invitation's Decline with a mediated<decline/>through the room, which XEP-0249 doesn't define (servers relay it). 9 runs, all three servers: Gajim 204944client.log:241, 210455client.log:224, 231404client.log:535; Dino 210018, 211132, 232148; web 210753, 211510, 232627.muc set_avatarworks through the API (web set it in 231007, 224019, 000658). Receiving passes everywhere (status 104, vCard fetch, picture in header and list; Dino too). 9 runs: Gajim 215138, 220119, 234127; Dino + Gajim 222216, 222656, 235930; web 224019, 231007, 000658.message.moderate(230307peer-anotherim-web.log:260, 001141:382). The display part is M29.groupcall.start(214007, 003642, 214938, 004557). Joining and declining from the card work (C43, C44 aside)./meon receipt (batch 3, all three servers, 9 runs): a received/me nods …is drawn raw in aim's bubble and chat-list preview (and in anotherim-web's); libtacky setsMessage.me(api.ts:1205),ui/srcnever reads it. aim's own/megoes out as typed and Gajim and Dino draw it as an action. Gajim 012515 (shot-4), 014206, 022041; Dino 014614, 015658, 022431; web 013117 (steps.log:34web shows a raw '/me'), 020052, 022822.<expires/>; receiving works: web's API-set status with<expires/>shows on aim and is dropped at the limit. 045539 (peer-anotherim-web.log:211,client.log:475, shot-3), 041146 (client.log:320), 044109 (client.log:624aim's status without<expires/>).Unexplained / candidates (not yet evidence)
server.log:3969(23:09:02) is aim's last stanza before the disconnect at:4073(23:10:42): its stream went quiet ~35 s before the click. On anotherim (203202) and ejabberd (233830) aim's logs end before the click. aim's own calls terminate fine (195624client.log:435,:556). Maybe a stalled stream, not the hang-up; next: a XEP-0167 run with Dino calling, logs kept to the end.session-initiate37 s after aim's<proceed/>(204353peer-anotherim-web.log:242; no fake mic in that example). web logged nosession-terminatefor a video call aim ended (000900). aim re-sent a kick iq 37 s later (223151client.log:609).<idle/>(XEP-0319) from Gajim (no example yet).Resolved in batch 2: full-JID membership/ban → C45; duplicate chat after a mediated invite → C46; moderated message without moderator → M29. Resolved in batch 1: Dino's JET cipher → P4; plain Jingle files to Dino → P5 + P6;
omemo-chats:0withdrawn (harness),omemo-trust:0→ C42.Harness issues already fixed in the interop repo
ac41415); guest clock lag afterstop/cont(2ff2a33); gnome-keyring aborts (8448d94,9168a55); screensaver (bbe1727); aim before the keyring (e16143e,24aca6b); the fake camera unfed, then 4:2:2, now YUY2 (c137b7b, #16f45e5c5; withdrew C39); a dunst per client start (#16).bc25552,eba181f);notify_calls()reads in the guest (1aaf81a,5493897); 60 s wait forsession-terminate(43c4549);client-tacky.logkept (4638f85); "Answer" fallback (9c3f35a); Gajim popovers and composer (342b1c6).4526b3a);omemo_sync.pyverifies own devices (f54a4b7) and needs aim's publish and web's event (a090834); Dino's download button (8d4d2d1,1be1499; also no false View XML FAILs from sealed PEP publishes); the CBC 32-byte IV retried as 16 (d6cf5b1).a717672,b535cd9); Dino's room form (da67334) and Join Channel under a notification (22cf9bf); Gajim's room header after a room picture (4fc6beb); aim's keys column scrolled to a far key (eee9d69) and a key id with one misread digit (daa0f43); the destroyed-room read for anotherim-js#95 (a276241).Not covered
start_callisn't scripted, so aim declining a Kaidan call is covered only with Dino and web); group calls with Kaidan.omemo-chats:0/omemo-trust:0, JET-OMEMO 2, DTLS-OMEMO; Kaidan calls on anotherim-server; web calls on prosody (233237).urn:tacky:spans:0andurn:tacky:live-location:0arena(libtacky only reads them; no harness client sends them; S6 and M25's live-location part unchecked);urn:tacky:schedule:0only on anotherim-server (mod_schedule); Dino and Kaidan lack most batch 3 specs (clients.toml).SKIP presence: kaidan: set_presence not scripted yet); Kaidan's Contact Details don't reliably draw in the VM (155057), so its display of aim's name and picture is judged from the wire; XEP-0191 with Dino and Kaidan only on ejabberd (155048, 155601); XEP-0377 na everywhere (no server offers it).VM runs 2026-11-08: bugs found with Gajim, Dino and Kaidanto Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 8 found)Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 8 found)to Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 7 found)Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 7 found)to WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 7 found)WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 7 found)to WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 9 found)WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 9 found)to WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 11 found)WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 11 found)to WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 16 found)WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 16 found)to WIP: Verify anotherim-js/libtacky bugs from the GUI VM runs (rc9 / v1.2.3, 20 found)