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.
Move DebugLogging into debug logging module.
Remove Context.send_log_event().
Use blocking_read() instead of try_read() to
get read lock on debug_logging() in synchronous code.
Do not try to log events while holding a lock
on DebugLogging.
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.
