Found testing calls between two phones on the Compose call stack:
- The famedly SDK keeps only "important" state in memory for a room that
hasn't been opened, so call memberships of other rooms were invisible:
no ring (it was cleared at once, the call looking empty), no room-list
marker. org.matrix.msc3401.call.member is now important state.
- The incoming-call card closed itself with Navigator.pop when the ring
cleared, which popped the call screen pushed above it on Answer. The
buttons now close the card first, and it closes itself only while it
is the top route.
Tested: a voice call in a room of two (ring, answer, both connected
through LiveKit), and a video call in an encrypted room (to-device media
keys, frame cryptors OK on both sides, each phone showing the other's
video). The web client sees a phone's membership and rings for its
notification.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Calls the way the web client and Element Call do them, with the same
events, so the three can share a call. The famedly SDK's own group calls
use com.famedly.call.member events, which the others don't read, so this
is written against the matrix-js-sdk wire format instead (lib/matrix/
calls.dart):
- Membership: org.matrix.msc3401.call.member state, key
_@user:server_DEVICE_m.call, with the legacy session fields the js-sdk
sends (application m.call, call_id "", membershipID, expires,
focus_active, foci_preferred). An empty delayed copy (MSC4140) is
scheduled first and pushed back every 5 s; leaving sends the empty
state and cancels it.
- Media: a LiveKit token from the JWT service (the call's, else the
homeserver's rtc/transports or .well-known rtc_foci) for an OpenID
token; livekit_client connects.
- Encrypted rooms: a random 16-byte key per device, sent to every other
device in the call over encrypted to-device
io.element.call.encryption_keys, keys from others applied per LiveKit
identity (@user:server:DEVICE); per-participant keys, no ratcheting,
HKDF, like the web client's livekit-client.
- Ringing: a call started in a room of two sends a ring notification
(MSC4075); the other side gets an incoming-call card and an insistent
ringtone notification (full screen on a locked phone), declines with
MSC4310 or answers by joining. The caller gives up after a minute or on
a decline.
- UI: voice and video buttons in the room header, a call screen (the
other person large and you in the corner, or a grid; mute, camera, flip,
leave), a Join banner and a room-list marker for calls going on.
Not tested end to end yet: it needs a LiveKit SFU and JWT service.
README: replies, reactions, threads, spaces, QR verification, sliding
sync and calls.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The famedly SDK only knows /sync, but its sync loop asks Client.sync for
each response. WarpClient answers that with a sliding sync request and
rewrites the response into the /sync shape (slidingToSyncJson), so
decryption, the database, timelines and notifications work unchanged.
- Two lists, rooms and direct chats (with all their members, so DM names
come out right), over a window that starts at the 20 most recent rooms
for a quick first screen and widens to every room (up to 1000).
- The state the screens and encryption need, $LAZY members and $ME, and
call memberships; timeline_limit 10, with prev_batch for history.
- Extensions: to_device (its since rides in the token), e2ee, account
data, receipts, typing.
- Rooms the user left while the connection was open become leaves;
invite_state and knock_state become invites and knocks.
- The SDK's token is ss1|<pos>|<to-device since>. A classic token, none, or
M_UNKNOWN_POS starts a new connection; a server without
org.matrix.simplified_msc3575 gets plain /sync.
Tested against Warp: first sync, encryption setup (account data and
oneShotSync through the connection), live messages, unread counts and
typing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When both sides support it, a verification offers QR codes first: this
device shows its code (in a white quiet zone, whatever the theme) and can
scan the other's with the camera (mobile_scanner; only codes that start
with MATRIX count). The side whose code was scanned confirms the other
saw it succeed. Compare emoji stays available, and is used directly when
either side has no QR support.
Adds the CAMERA permission (camera hardware not required).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Replies: Reply on a message's long press puts it above the composer;
sent replies quote the message they answer (sender and first line),
with the reply fallback left out of the body.
- Reactions: six quick ones and any other on long press, chips under the
message with counts, the user's own highlighted; tapping a chip adds or
takes back a reaction, a long press lists who reacted.
- Threads: Reply in thread opens a thread view (the root, then its
replies, older ones fetched from /relations, new ones live from the room
timeline) with a composer that sends into the thread. Thread replies
are hidden from the main timeline; the root shows "N replies". Room info
lists the room's threads (/threads).
The composer moved out of the room screen into widgets/composer.dart so
the room and thread views share it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
apps/mobile is a Matrix client for Android on the famedly Matrix Dart SDK,
with vodozemac (compiled from Rust during the build) for end-to-end
encryption. It speaks the plain Client-Server API and uses the web
client's design tokens, fonts and symbol.
- Sign in by server name (.well-known), homeserver address or full user ID;
sign up with the dummy and registration token stages. Sessions survive
restarts: SQLite in private storage, credentials also in the Keystore,
both excluded from backups and device transfers.
- Room list with unread and mention counts, invites, search and filters.
Timeline with grouping, day separators, notices, history on scroll,
links, images and files (authenticated media). Sending text, photos,
camera shots and files, with Sending/Sent/Read/Not sent and Retry.
Typing, receipts, deleting. New rooms and DMs, encrypted by default;
joining by address; room info with members, invite, rename, topic,
notification level, leave.
- Encryption: one-step setup behind a recovery key, verifying a new session
with the recovery key (restoring the backup) or another session, emoji
verification of people and sessions, reset. Undecryptable messages say
why. Session list with verify and sign out.
- Notifications while running, and push through UnifiedPush (no Firebase):
the distributor's endpoint becomes an event_id_only pusher, the gateway
is discovered, and a push starts the app headless to fetch, decrypt and
show the event.
Make targets: mobile (release APKs per ABI into bin/), mobile-run,
mobile-test. Kotlin incremental compilation is off (Windows, project and
pub cache on different drives), and Tink's JVM artifact is excluded in
favour of tink-android.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
