A new table `pending_reactions` is now used,
to store reactions that arrived before the referenced message.
When receiving a new message, pending_reactions is checked and any
reactions that arrived earlier are applied.
Fixes: #8367
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
Unpublished relays aren't shown in the list of relays anymore, and can't
be deleted manually. Therefore, we want to automatically delete them in
order to make space for more relays when the limit (5) is reached and
the user wants to add another relay.
Before this change "Err" case spams the logs with
"Failed to download message rfc724_mid=...: IMAP location for ... post-message is unknown."
logged by every transports when the message is not available on any transport.
Un-escapes footer marks in long plain-text messages when retrieved with
`get_message_html`/`dc_get_msg_html`.
Additionally, makes escaping stricter,
only matching lines starting with `-- ` instead of `--`.
Fixes: #8269
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
Not clear why `GROUP BY` was needed -- a chat can't appear in the selected rows multiple times
because we do JOIN on the last message in the chat, there can't be multiple last messages.
This speeds up chatlisting by 3--4 times on my biggest profile, so the difference is visually
noticeable, particularly after dropping disk caches. Before, `msgs_index2` was used which has less
ordering and requires a full scan of `msgs` table.
Network errors such as timeouts should not break out of the loop
by bubbling up errors. There may be more candidates to try,
breaking out of the loop skips trying them.
Automatically remove relays that are hidden (`is_published=0`) and
haven't been used to receive new messages for over 90 days.
Closes: #8384
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
This is a follow-up to 8f51c7b9d5
which removed sync_seen_flags().
MODSEQ is a message attribute related to
CONDSTORE IMAP extension and is not used anymore
since CONDSTORE is not used.
BREAKING CHANGE: UIs should use `list_transports()` rather than `list_transports_ex()`, because unpublished transports count as removed from the user point of view, and should not be shown in the relay list anymore.
We use the timestamp of the latest transport modification
as the timestamp of the Direct Key Signature.
However, first transport is created before the public key
and existing transports may even have zero timestamp
if they were created before migration 142.
For interoperability with Sequoia-PGP,
make sure signatures always have a timestamp
that is not in the past compared to the timestamp
of the primary key.
This is necessary because
https://github.com/deltachat/sysadmin/issues/270 switches our
server-side authentication to rrsync, and that uploads to a restricted
path already; keeping it like this will result in a destination path
like `/var/www/html/var/www/html`.
Co-authored-by: j4n <j4n@systemli.org>
These messages are AUTH-encrypted and shalln't contain profile data as per the SecureJoin v3 spec,
otherwise the profile data can be seen e.g. by other broadcast subscribers.
An Iroh-Node-Addr message (realtime advertisement) may arrive earlier than the referenced webxdc in
case of multi-transport. By not creating a tombstone we still can receive it later on another
transport.
It's unclear whether this logic works, but I think we should at least
properly document why it exists (I already sent this text while figuring
out what the code does, so it was easy making this PR now)
Could add a XXX note that it's unsure whether this works
Alternative to https://github.com/chatmail/core/pull/8355/, fixes
https://github.com/chatmail/core/issues/8329
This fixes the following bug:
Scanning QR for existing contact doesn't update relay list
Two chat partners suddenly lost connectivity to all of their relays. They added another relay, which is accessible, and set it as main. Of course, they still couldn't communicate, because there was no way to announce a new relay list to each other (clients know only about old relays so they try to send updates there).
That's why the friends used a different channel (e.g. met IRL) to send their QR codes once again.
Expected behavior: They would expect that clients update their relay lists according to the contact info inside the QR codes, and they can continue talking in Delta.
Actual behavior: But Delta Chat client doesn't update a list of announced relays on scanning a QR in case a contact already exists. It simply opens the existing chat without altering any contact info.
---------
Co-authored-by: holger krekel <holger@merlinux.eu>
