They are an overkill and do not solve any problem. Also they aren't documented anywhere. And all
necessary tests were added before and they work w/o the removed code.
AFAIU, they were added for Alice (joiner) to be sure that Bob (joinee) has Alice two-way verified,
i.e. Bob can add Alice to other verified groups because Bob knows that Alice trusts them. But that
means Alice should retry sending vc-contact-confirm/vg-member-added messages until getting
*-received message from Bob. But then better let Bob retry sending *-auth-required until getting
vc-contact-confirm/vg-member-added from Alice. And if Alice sees no more retries from Bob, either
Bob has got vc-contact-confirm/vg-member-added from Alice or there are communication problems. But
the latter can't be solved anyway by adding extra messages to the protocol. Note that there are no
retries currently, instead we rely on that Bob will eventually receive a message from Alice and thus
know that Alice verified them. But i could miss some details why they were added, so just in case,
citing from #3836:
@iequidoo: Btw, can somebody explain the purpose of
vg-member-added-received/vc-contact-confirm-received messages in the protocol? They look
excessive and for me it's like a try to solve that problem with two friends that want to meet
and drink some beer but only if each of them is sure that their beermate is also going to the
meeting :) Even if Bob didn't receive vg-member-added message (e.g. because of mail delivery
problems), we can consider Bob joined -- Bob can try sending messages to the group and that must
work afaiu.
@flub: Yes, this is a weird state. It is currently the difference between an internal state
"un-idirectional verified" and the exposed state "bi-directional verified". The latter (bi-)
means both know that both have each other verified, in the former (uni-) only one of them knows
this and the other hasn't figured this out yet.
IIRC the last time this was discussed the revelation (at least to me) was that the main
practical difference between these two is that bi-directional allows you to add the other person
to a verified group, while if you only have them uni-directional verified you can not do they
since they don't trust you enough (IIRC, there should be a cryptpad somewhere with this written
down).
@link2xt: When Bob receives vc-auth-required, he already has Alice one-way verified. When Alice
receives vc-request-with-auth, she has Bob two-way verified (she has verified Bob's key and she
know Bob has verified her), but Bob still does not know about this. When Bob receives
vc-contact-confirm (or vg-member-added) he sets Alice state to "two-way verified".
The question is what happens if vc-contact-confirm/vg-member-added is lost. In this case Alice
has Bob two-way verified, while Bob has Alice only one-way verified. Because of this, Bob cannot
safely add Alice to any verified group, because Bob thinks maybe Alice has not received
vc-request-with-auth and has Bob completely unverified. However, Alice still can add Bob to
verified groups and if Bob later receives any message from Alice in a verified group, he sets
Alice to two-way verified, so eventually both Alice and Bob converge to a two-way verified
state. This is not how it is currently implemented, but this was the idea during the discussion
with @flub and @missytake.
But vg-member-added-received/vc-contact-confirm-received is an overkill and can be removed IMO,
it does not solve any problem.
It's a compatibility crutch for old clients (< 1.107.0), they require it in the subject
messages. Currently DC sends Autocrypt key gossips instead, they're better because knowing a key
allows not to only trust the peer, but also encrypt to it. Before it was a problem for other devices
on a joining side going online after a successful Securejoin setup -- they didn't have a joiner's
key to encrypt to it. So, we decided not to complicate the Securejoin with sending keys instead, but
rely on the Autocrypt.
Also there's a PR to the Countermitm doc documenting when gossips in 'vc-request-with-auth' are
needed:
Bob's own key fingerprint ``Bob_FP``,
the second challenge ``AUTH`` from step 1 and
optionally an Autocrypt-Gossip header for Alice's
Autocrypt key in order for a second device of Bob
to learn Alice's verified key.
Why? because desktop currently fetches the chatlist multiple times, even though it just needs the
chatlistitem for one chat.
Note: @r10s was worried before that exposing the method to get a single updated chatlistitem could
lead to race conditions where the chatlist item is newer than the chatlist order. But I don't think
this will change anything for desktop besides making it a little faster (because currently desktop
fetches the whole chatlist instead of just the entry it needs when an entry updates).
This way is more compatible to JSON-RPC libraries
that do not support receiving notifications from the server
and allows describing event types in the OpenRPC specification.
Event thread converting events to notifications in the FFI
is removed, so it is now possible to construct a dc_jsonrpc_instance_t
while still retrieving events via dc_event_emitter_t.
Otherwise sending a message without plaintext part
resets the signature. It is particularly dangerous
in multidevice case, because it's easy to accidentally
reset the signature on your other device with a non-text message.
I.e. > 500K for the balanced media quality and 130K for the worse one. This can remove animation and
transparency from PNG/WebP, but then a user always can send an image as a file.
Also don't reduce wide/high images if they aren't huge. Among other benefits, this way most of PNG
screenshots aren't touched.
Also remove Exif from all images, not from JPEGs only.
This patch adds new C APIs
dc_get_next_msgs() and dc_wait_next_msgs(),
and their JSON-RPC counterparts
get_next_msgs() and wait_next_msgs().
New configuration "last_msg_id"
tracks the last message ID processed by the bot.
get_next_msgs() returns message IDs above
the "last_msg_id".
wait_next_msgs() waits for new message notification
and calls get_next_msgs().
wait_next_msgs() can be used to build
a separate message processing loop
independent of the event loop.
Async Python API get_fresh_messages_in_arrival_order()
is deprecated in favor of get_next_messages().
Introduced Python APIs:
- Account.wait_next_incoming_message()
- Message.is_from_self()
- Message.is_from_device()
Introduced Rust APIs:
- Context.set_config_u32()
- Context.get_config_u32()
* Don't let blocking be bypassed using groups
Fix#4313
* Fix another bug: A blocked group was sometimes not unblocked when an unblocked contact sent a message into it.
* Small performance improvement by not unnecessarily loading the peerstate
* Remove wrong info message "{contact} verified" when scanning a QR code with just an email
I think that this was a bug in the original C code and then slipped
through two refactorings.
bjoern <r10s@b44t.com> wrote:
> maybe_add_time_based_warnings() requires some date guaranteed to be in the near past. based on
this known date we check if the system clock is wrong (if earlier than known date) and if the used
Delta Chat version may be outdated (1 year passed since known date). while this does not catch all
situations, it catches quite some errors with comparable few effort.
>
> figuring out the date guaranteed to be in the near past is a bit tricky. that time, we added
get_provider_update_timestamp() for exactly that purpose - it is checked manually by some dev and
updated from time to time, usually before a release.
>
> however, meanwhile, the provider-db gets updated less frequently - things might be settled a bit
more - and, get_provider_update_timestamp() was also changed to return the date of the last commit,
instead of last run. while that seem to be more on-purpose, we cannot even do an “empty” database
update to update the known date.
>
> as get_provider_update_timestamp() is not used for anything else, maybe we should completely
remove that function and replace it by get_last_release_timestamp that is then updated by
./scripts/set_core_version.py - the result of that is reviewed manually anyway, so that seems to be
a good place (i prefer manual review here and mistrust further automation as also dev or ci clocks
may be wrong :)
that way, UI can just close the transfer dialog,
so that, at the end, both devices end in the chatlist.
we can also use this for troubleshooting -
if the device message is not present,
transfer did not succeed completely.
(a separate device message may be nice in that case -
but that is another effort,
same for making the device message reappear after deletion
or after some time)
some providers say that they support QUOTA in the IMAP CAPABILITY,
but return an empty list without any quota information then.
in our "Connectivity", this looks a bit of an error.
i have not seen this error often - only for testrun.org -
if it is usual, we could also just say "not supported"
(as we do in case QUOTA is not returned).
a translations seems not to be needed for now,
it seems unusual, and all other errors are not translated as well.
Similarly to how `imex_inner()` runs migrations
after successful call to `import_backup()`,
migrations should be run after receiving a backup
using `transfer_from_provider()`.
`install_python_bindings.py` was not used by CI
and scripts, except for `scripts/run-python-test.sh`
which only used it to invoke `cargo`.
Instead of using an additional script,
run cargo directly.
The documentation is updated to remove
references to `install_python_bindings.py`.
The section "Installing bindings from source"
was in fact incorrect as it suggested
running `tox --devenv` first and only then
compiling the library with `install_python_bindings.py`.
Now it explicitly says to run cargo first
and then install the package without using `tox`.
`tox` is still used for running the tests
and setting up development environment.
