Closes https://github.com/chatmail/core/issues/8576.
The diff might look big, but it's only two things:
- move `can_call_me` one scope up
- replace `emit_incoming_msg` with `emit_msg_event`
with `important = can_call_me`
I decided not to completely unify the `important` logic
with the other occurrence of `emit_msg_event()`
as I suggested in the issue yet.
That IMO should still be considered, but let's start simple.
Note that there is #7840 which may be closed by #7955,
which will basically supersede this MR.
I think, however, that it's OK to merge this one,
and then that one can just revert this one, including tests,
and rebase on top of the revert.
I have an old profile which has ProfileImage param
set on the reserved SELF contact. When I deleted
an avatar from the profile, very old profile image
showed up in the settings in Delta Chat Desktop instead,
which can be "deleted" again without any result.
This fix is to return `None` early from get_profile_image_ext
for self contact without trying to load the parameter.
Fallthrough to loading params was likely there
since keycontacts and grey avatars for address contacts
introduction in 416131b4a2
all published deltachat-rpc-server wheels so far fail "wheel tags"
and probably other tools.
Translate "dev" cargo-versioning to PEP440-versioning
to make CI dev wheel builds reproducable at least for the 11 non-mac targets.
.execute() was returning the number of rows, so usually 1.
.insert() is returning the row ID.
In most cases it does not matter because the result is checked with .is_empty(),
but send_msg_sync() actually uses the row IDs.
Authentication failures may happen because of internal server errors.
Device message saying "Please check if the email address and the password are correct"
was written for classic email setups when the user knows the password.
For users of chatmail relays this message is not actionable,
but still appears when relay fails to check the password.
Changes filenames used in the db backups and key exports,
preferring fingerprint over the email address.
Part of: #8572
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
this is meant to help configuration event consumers (Python, UIs)
to not hang waiting for configuration outcomes.
One test case is added that fails on main.
This did not affect actual message deletion,
because select_expired_messages already takes timestamp_rcvd
into account and does not delete system messages
that say "Messages are end-to-end encrypted" too early.
So it is a minor bug as estimate_deletion_cnt
is meant to only roughly estimate the number of messages
to be deleted. Still, there were no tests before,
so now estimate_deletion_cnt is tested.
Address inside the KML is not used anywhere,
and we are moving away from "primary" relay notation (and thus also
identifying contacts by email address).
Part of: #8572
Signed-off-by: Jagoda Ślązak <jslazak@jslazak.com>
chatmail relays (filtermail) expect {vc,vg}-request
messages to be multipart/mixed with a single part.
Messages had this structure
before commit e0494b0b37
so we need to keep it for compatibility.
This is mostly a reaction in response to
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/
I don't know when exactly
`cargo clippy` and similar commands (check, build, run etc.)
may update dependencies
and it does not look like they actively pull
the package index and update yanked crates.
We also keep the lockfile updated all the time
by checking in CI.
Still, all commands better use --locked as a precaution.
Requests now register before testing for shutdown,
so either the reader loop or the caller answers them.
Also failed start() winds down its threads, ignoring a broken pipe on stdin.
`version_string` is meant to be displayed by UI, and comes from the
wire.
therefore, as a general precaution, ensure a string that is
regarded as a typical version string. all versions in scope are
currently v123.456.789-shortsuffix, where suffix is a-z and mostly
unused in production. that is the base. we can adapt if there is really
a need, but not for theoretical version strings. as we do not stop
processing, things are not bad even if we missed a valid usecase herr.
moreover, if `version_string` is empty, we skip the candidate - as we
cannot display something useful to the user. that little bit of care is
expected from relays :)
This replaces independent data structures
which allowed invalid state of having both the public keys
and the shared secret, or having a shared secret
but not encrypting the message because encryption_pubkeys
was None instead of Some(Vec::new()).
Creating QR code or sending a message will still fail
with a shorter error, but no info message will be created anymore.
Most users should have migrated the channels by recreating them by now.
This change is needed for moving loading of the shared secret
to earlier stages of message preparation,
otherwise mimefactory will have to create these info messages
when loading the message into memory.
"ex" means "used to be, but no longer is".
"ext" means "extended", which is the intended meaning.
"Ext" is more common not only in the Rust ecosystem but in general.
We already had several people (myself included) asking
what "ex" is supposed to mean.
To reproduce this commit, search and replace `_ex(?!\w)` -> `_ext`.
But don't change `list_transports_ex` because it's public API.
Unencrypted messages are no longer sent as multipart/mixed
with Message-ID header duplicated inside.
This was useful as non-standard protection
against servers that rewrite the Message-ID,
but now most messages are sent encrypted
and for them standard RFC 9788 header protection
works the same way.
it is outdated and incomplete, and always was experimental.
it is not in use in any UI but to get the name of the chat in Ubuntu
Touch, i created an issue for that at
https://codeberg.org/lk108/deltatouch/issues/305
moreover it is used for python bindings as get_summary(), not sure how
much that is in use,
we can leave the API for that for now, but we should not encourage
further usage of the API
---------
Co-authored-by: adb <adb@merlinux.eu>
> we aim to inform about updates for installations outside of any
appstore soon.
>
> there is already a PR on android at
https://github.com/deltachat/deltachat-android/pull/4582, however, the
information about "update available" is a mockup there.
>
> in general, there are 3 ideas around about how to gather the "update
available" infomation - (1) checking a central url, (2) let contacts
provide information, (3) let relay provide information. on various
one-to-one discussions, outcome is that (3) is the most reasonable way
to go.
this PR is about reading update information via IMAP metadata from the
relay.
it is up to the UI to call `get_app_version()` at a reasonable time and
frequency, see comment in the code. when called, `get_app_version()`
iterates over all known profiles and relays and checks for version
information, returning the newest for the given scope.
we do not use an event, as that is tricky wrt changes - we do not know
if other relays report later a newer version. we also do not cache
anything, to prevent bad relays avoiding us to update permanently. also
it is easier :)
<details>
<summary>outdated notes and questions</summary>
- ~~it is up to the clients to get the needed information, we could let
core filter, but it seems easy enough the other way round, and may have
debug advantages, one can iterate etc.~~ EDIT: we now filter in core,
this also makes the jsonrpc part easier, see review comments
- when is IMAP METADATA actually read? when are they ready? is that
really the correct place? i am up to change that, but beware, this is
not really my expertise, so someone else may need to take over :)
EDIT: see below, IMAP METADATA is read on connection, before fetching
starts, usually fast enough
- relay part is missing. once the format is settled and discussed
shortly here, that should be done soon as well. but this is definitely
not my expertise and needed to be done by someone else :)
- key for IMAP METADATA is `/shared/vendor/deltachat/appversions` -
shall we continue use `deltachat` for compatibility or so? `chatmail`
seems to be more correct
EDIT: we stay with the current
</details>
relay counterpart issue: https://github.com/chatmail/relay/issues/1037
cc @link2xt @Hocuri @hpk42
---------
Co-authored-by: holger krekel <holger@merlinux.eu>
There is currently no place to document up to date SQL schema.
New database is initialized with src/sql/tables.sql
and then updated by migrations,
So tracking down how some column is used requires grepping the code,
looking for a migration adding it and corresponding commits.
Co-Authored-By: biørn <r10s@b44t.com>
