* core: compress messages if needed to fit envelope, even if there is no PQ e2ee in connection
* simplify
* remove noise
* compress messages without PQ too
* case
* update query plans
---------
Co-authored-by: Evgeny @ SimpleX Chat <259188159+evgeny-simplex@users.noreply.github.com>
* core: fix races when sending and receiving files (in tests, or when server is very fast)
* update simplexmq
---------
Co-authored-by: Evgeny @ SimpleX Chat <259188159+evgeny-simplex@users.noreply.github.com>
- redeem errors are typed (CEBadgeRedeemError) instead of matched by text in the apps
- service timeout (A_SERVICE) decodes in the apps and offers Retry via the existing retry alert
- unexpected redeem errors show the error itself instead of a generic message
- service error codes are a typed enum in the apps (BadgeServiceErrorCode)
- CRBadgeRedeemed returns badge state, so the apps skip a second round-trip after redeem
- setBadgeAlertAcked is scoped to user_id
- badgeChanged updates non-active profiles, so other profiles' badges don't go stale
- pitch banner is not shown to a profile that already has a badge
- one badgeTypeName per platform, used by the badge screen and the badge info alert
- BadgeAlertKind and BadgeAlertPrice decode via standard JSON, no custom decoders
- dead "Support ended" title branch removed from Your Badge view
- kotlin: users from badge responses carry remoteHostId
- kotlin: redeem code field keeps the IME's cursor and composition state
- kotlin: "Get your code" shown in all flavours
- kotlin: "Don't show again" -> "Dismiss", matching iOS
- kotlin: parseBadgeCode moved next to its FFI in platform/Core.kt
- kotlin: BadgesView no longer cross-fades on badge state updates
- kotlin: section title not uppercased
- ios: redeem code field parses once per change
- ios: A_SERVICE rejected reason is not decoded
- CLI: "cannot redeem badge code: ..." with the source of the error
- comments clarified
* core: support message signing in p2p groups
* improve
* add member key
* distribute keys and sign
* refactor
* better query
* map
* sign in relay groups too
* clean up
* list
* fix test
* update bot types
* some refactor
* remove unnecessary condition
* simplify
* refactor
* simplify
* move
* clean up
* diff
* diff
* limit attempts for key sending
* optimize
* fix test
* split
* fuse
* null
* only mark as "key sent" when forwarder supports binary encoding
* fix bot apis
* fix some tests
* add key distribution steps, and fix some tests
* fix test
* increase timeout
* fix tests
* fix more tests
* simplify
* disable test output
* mark keys sent with invitations
* fix test
* fix test, query plans
* unify signing of connection info packets
* revert change to createNewGroup
* create key at group/member creation
* rename, remove liftIO
* clean up
* fix type
* remove ad hoc key sending
* update bot api
* diff
* reduce diff
* failing test
* fix sending messages in groups with members before version 18
* remove test delays
* update query plans
* update test
* add tests
* fix tests
---------
Co-authored-by: Evgeny @ SimpleX Chat <259188159+evgeny-simplex@users.noreply.github.com>
* 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: 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>
* core: enhance server test result handling with additional server info
* simpler
* nix
---------
Co-authored-by: Ed Asriyan <service.github@asriyan.me>
Messages of blocked members are hidden, but they still marked chat item
as user mention, showing mention badge and counting group as unread in
"mentions only" notification mode:
- createNonLive passed mentions unfiltered, allowing members blocked by
admin to mention user - it is the default path, as it is only used
when full delete is not allowed;
- userReply was set for replies to user messages from blocked members.
* core: remove SimpleX Status preset contact
Preset contact cards are only created at user record creation
(createPresetContactCards), so this affects new profiles only;
existing profiles keep their stored SimpleX Status contact.
Removing the card shifts contact ids allocated after /create user
down by one, hence the test id updates.
* plans: justify SimpleX Status preset contact removal
Surface the XFTP servers that hosted a file's chunks in the message info
screen (Android, desktop, iOS), so a user can see which servers they are
downloading from (or, for sent files, uploading to) whenever they want to know.
APIGetChatItemInfo now returns fileXftpServers, derived from the stored file
description (private snd descr for sent items, rcv descr for received items);
extraction is best-effort and never fails the call.
Evgeny @ SimpleX Chat