* core: fast queue rotation not requiring the current server to be online
* simplexmq
---------
Co-authored-by: Evgeny Poberezkin <evgeny@poberezkin.com>
* desktop: fix stretched video preview and playback for AV1 videos
libvlc passes the padded size the decoder allocated to the buffer format
callback, not the size of the picture. dav1d pads to a multiple of 128, so
a 1920x1080 AV1 video arrives as 1920x1152, and vlc scales the picture to
fill it - the preview sent with the message, and desktop playback, were
6.7% too tall. H264 pads much less, so it was barely visible there.
Ask for the size of the track being played instead. It is already populated
when the buffer format is negotiated, and matching the track that is playing
matters for files with more than one video track, where the first track is
not necessarily the one being decoded. Falls back to the previous behaviour
when the track is not known.
* plans: desktop video preview aspect ratio
* android, desktop: open group member profile without loading all members
Clicking member avatar in chat loaded the whole member list (apiListMembers)
before showing member profile, and it was repeated on every click - in a group
with 10000 members it takes several seconds.
The full list is not needed to show the profile of one member, so instead the
opened member is added to the model, the same way as in iOS app.
* plans: member profile in large groups
* plans: correct relay warning section - it is not affected by the change
* core, ui: auto-accept group invitations per user profile
Add a per-profile toggle for auto-accepting group invitations, and regroup it
with the existing contact-requests setting under a single Auto-accept section
in Privacy & Security, relabelled "Contact requests in groups".
The join is fully async. processGroupInvitation already had an async accept
path, used when the invitation matches a group link the user opened:
prepareAgentJoin + createMemberConnectionAsync + joinAgentConnectionAsync,
with the outcome reported later against the CFJoinConn command id. Auto-accept
takes that same path instead of going through APIJoinGroup, so it works while
the app is closed and never blocks message processing.
An auto-accepted invitation still records a CIRcvGroupInvitation item in the
chat with the inviting contact, so there is a record of who added the user to
which group.
Two details worth noting for review:
hostContact is reported to clients only for group links. Clients respond to it
by replacing the transient host connection view with the group and removing
that chat - correct for a group link, where the contact is a placeholder, but
wrong for a plain invitation, where it is a real contact.
A resent invitation returns the existing group, because createGroupInvitation
is idempotent on inv_queue_info. The join therefore only runs while the
membership is still GSMemInvited, so a resend cannot open a second connection.
* booldef
* order
* refactor
* update translation key
* query plans
* ios: export translations
---------
Co-authored-by: Evgeny Poberezkin <evgeny@poberezkin.com>
Co-authored-by: Evgeny Poberezkin <2769109+epoberezkin@users.noreply.github.com>
* directory: identify registration owner by member id to fix incorrect de-listing
The leave/removed/role-changed handlers identified the registration owner by
contact id. A non-owner member can be associated with the owner's contact (via
the contact/member merge), so its departure incorrectly de-listed the group.
Compare by group member id (owner_member_id) instead, falling back to contact
id for registrations recorded before owner_member_id existed.
* fix test, always compare contact ID in owner check
---------
Co-authored-by: Evgeny Poberezkin <evgeny@poberezkin.com>
* directory: only create group links after approval
* update test
* update messages
* diff
* get group and link in one query
* reduce database reads
* better errors
* typos
* query plans
---------
Co-authored-by: Evgeny @ SimpleX Chat <259188159+evgeny-simplex@users.noreply.github.com>
* feat: add simplex-support-bot-light
* feat: package simplex-support-bot-light for docker
* docs: document simplex-support-bot-light
* fix: make a missing config actionable and bounded
* docs: note the attached compose Ctrl+C behaviour
* refactor: use the library for startup and custom data
* refactor: drop the display-name workaround
* style: shorten the startup comment
* build: build the core and the library into the image
* docs: correct where the image type rule comes from
* fix: log what the core said a command got wrong
* build: run the container as the operator's uid
* docs: keep the container uid in .env
* docs: tighten the README
* core: do not commit refused name changes
* feat(python): add error base and missing commands
* feat(python): let callers drive startup themselves
* style(python): satisfy the linter, skip generated types
* feat(python): expose the message of a command error
* core: update query plans
* core: fix the batch limit parse error on GHC 8.10
* feat(python): reject profile images no client can render
* ui: send dropped .webm as video only when it has a video track
.webm is as commonly an audio-only container as a video one, so the
extension alone cannot tell whether there is a frame to embed. Read the
container to decide: files with a video track are sent as video, the rest
as files.
Only done for files attached without the user saying how to send them
(drag & drop, paste). An explicitly picked video is still sent as one, so
.webm is now listed in the video file picker too.
* plan: send dropped .webm as video only when it has a video track
* android: add google and foss build flavors
* android: get the Google Play account country in the google flavor
* android, desktop: update whats new
* temp: comment out wefunder link
* ui: connect when a SimpleX link is pasted as a markdown hyperlink
* remove comments
Co-authored-by: Evgeny <evgeny@poberezkin.com>
---------
Co-authored-by: Evgeny <evgeny@poberezkin.com>
* core: enhance server test result handling with additional server info
* simpler
* nix
---------
Co-authored-by: Ed Asriyan <service.github@asriyan.me>
* android, desktop: fix live message sent to the chat opened after switching
A live message is sent when the chat is switched, but by then this view
already shows the chat that was opened - the effect that sends it runs
with that chat, so the message typed in one chat was sent to another.
The chat the message was composed in is passed to the send, and it is
resolved by the chat id from before the switch. If that chat is no longer
there the message is not sent at all, rather than sent to the chat opened
instead. The draft cleared after sending is the one of that chat too.
* plan: correct references; clear the draft of the chat the message is sent to
* plan: note the blast radius and how to resolve the overlap with #7308
* android, desktop: only pass the chat to what a live message can reach
A live message has no context item, so the forwarding, editing and
reporting branches of the send cannot run for it - they keep using the
chat of the view, and the chat it was composed in is passed only to the
message send, to the update of an already sent live message, and to
clearing the draft after sending.
* android, desktop: give the opened chat its own compose state while the live message is sent
Sending the live message to the chat it was composed in is not enough on
its own: composeState is shared between the chats opened in this view, and
the chat switch branch of KeyChangeEffect is the only one that neither
resets it nor loads the opened chat's draft - the branch that loads a
draft is later in the same if chain and cannot be reached.
sendMessageAsync then made it visible. It runs on Dispatchers.Default, so
its writes land after the switch: the whole composed state (via
cs.copy(liveMessage = null)) and its spinner (sending()) were written to
the compose state of a view that already shows another chat, which then
displayed the text composed in the previous one until the send completed.
The draft it should have shown was still in the model, and the next switch
away dropped it.
- sendMessageAsync takes composed, and sendMessage takes it as null by
default, so only the chat switch passes a state and every other sender
reads it inside the coroutine, where the send read it before. The chat
switch captures it on the main thread before replacing it - otherwise
the send would read the compose state of the chat that was opened and
send its draft to the previous chat.
- checkLinkPreview takes that state too. It re-read composeState rather
than what was passed in, and every text live message reaches it through
updateMsgContent, so it would have rebuilt the message from the opened
chat's draft instead of committing what was composed.
- every composeState write in sendMessageAsync is guarded by
composeIsForSend() (toChat.id == chat.id), which compares the two chats
instead of checking which one is open, so this send never takes the
compose state back if that chat is opened again before it completes.
- the chat switch branch then resets composeState to the opened chat's
draft, or to an empty state, like the branches below it do.
* plan: document the compose state handoff; correct the #7308 overlap resolution
The note on resolving the overlap with #7308 said its cs.liveMessage !=
null clause "already covers the send made by the chat switch". It does
not - in #7308 that clause sits outside the chatIsOpen check, which is
correct only while a live message is always sent to the chat that is
open, the assumption this fix removes. Read as written it exempts the
chat switch send from the guard that protects the opened chat, and a
merge that follows it reintroduces the leak.
Also records what manual test 2 was found failing on, and adds a slow
send variant so the window between the switch and the send completing is
long enough to type in the chat that was opened.
* android, desktop: keep reading the current state where a forward appends it
checkLinkPreview taking the composed state is needed where a live message
reaches it, but the forwarding branch is not one of those - it cannot run
with a chat other than the view's - and forwardItem suspends before it. So
there the captured state is stale by a network round trip, and text typed
while the forward was in flight stopped being appended to the message it
adds, while still being cleared when the send completed.
* plan: correct references and the claims that no longer hold
Line references were against the base this branch forked from, before
#7308 landed. Also: the live message loop no longer exits because the send
clears liveMessage - the chat switch replaces the compose state, on the
main thread, before the send runs; checkLinkPreview is not passed the
captured state everywhere; and chatsCtx.getChat can only return null in a
secondary context, which is not how "the chat is gone" reads.
Adds the two manual checks the review implied: a live message carrying a
link preview, which is what breaks if checkLinkPreview stops reading the
state it was given, and returning to the chat before the send completes.
* android, desktop: narrow the change to what the fix needs
- the draft id a failed message is saved under keeps using chat: that
branch is behind !liveSend, which the send made by a chat switch never
satisfies, so toChat is always chat where it is read;
- the state the chat switch installs no longer carries maxFileSize over.
That field is kept in sync on chat switch by LaunchedEffect(chat.chatInfo),
which is why the branches below this one construct it without one, and
the paths where that effect does not re-run are the ones where the send
overwrites the state anyway;
- sendMessageAsync takes its cs as a parameter rather than aliasing a
separately named one.
* plan: follow the narrowed change
* android, desktop: shorten the comments
The threading mechanism behind cs is explained where it is used, so the
function comment only has to say what it is; the rest is rewording.
Evgeny Poberezkin