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.
Delta Chat Rust
Deltachat-core written in Rust
Installing Rust and Cargo
To download and install the official compiler for the Rust programming language, and the Cargo package manager, run the command in your user environment:
$ curl https://sh.rustup.rs -sSf | sh
On Windows, you may need to also install Perl to be able to compile deltachat-core.
Using the CLI client
Compile and run Delta Chat Core command line utility, using cargo:
$ RUST_LOG=deltachat_repl=info cargo run -p deltachat-repl -- ~/deltachat-db
where ~/deltachat-db is the database file. Delta Chat will create it if it does not exist.
Optionally, install deltachat-repl binary with
$ cargo install --path deltachat-repl/
and run as
$ deltachat-repl ~/deltachat-db
Configure your account (if not already configured):
Delta Chat Core is awaiting your commands.
> set addr your@email.org
> set mail_pw yourpassword
> configure
Connect to your mail server (if already configured):
> connect
Create a contact:
> addcontact yourfriends@email.org
Command executed successfully.
List contacts:
> listcontacts
Contact#10: <name unset> <yourfriends@email.org>
Contact#1: Me √√ <your@email.org>
Create a chat with your friend and send a message:
> createchat 10
Single#10 created successfully.
> chat 10
Single#10: yourfriends@email.org [yourfriends@email.org]
> send hi
Message sent.
If yourfriend@email.org uses DeltaChat, but does not receive message just
sent, it is advisable to check Spam folder. It is known that at least
gmx.com treat such test messages as spam, unless told otherwise with web
interface.
List messages when inside a chat:
> chat
For more commands type:
> help
Installing libdeltachat system wide
$ git clone https://github.com/deltachat/deltachat-core-rust.git
$ cd deltachat-core-rust
$ cmake -B build . -DCMAKE_INSTALL_PREFIX=/usr
$ cmake --build build
$ sudo cmake --install build
Development
# run tests
$ cargo test --all
# build c-ffi
$ cargo build -p deltachat_ffi --release
Debugging environment variables
-
DCC_MIME_DEBUG: if set outgoing and incoming message will be printed -
RUST_LOG=deltachat_repl=info,async_imap=trace,async_smtp=trace: enable IMAP and SMTP tracing in addition to info messages.
Expensive tests
Some tests are expensive and marked with #[ignore], to run these
use the --ignored argument to the test binary (not to cargo itself):
$ cargo test -- --ignored
Fuzzing
Install cargo-bolero with
$ cargo install cargo-bolero
Run fuzzing tests with
$ cd fuzz
$ cargo bolero test fuzz_mailparse --release=false -s NONE
Corpus is created at fuzz/fuzz_targets/corpus,
you can add initial inputs there.
For fuzz_mailparse target corpus can be populated with
../test-data/message/*.eml.
To run with AFL instead of libFuzzer:
$ cargo bolero test fuzz_format_flowed --release=false -e afl -s NONE
Features
vendored: When using Openssl for TLS, this bundles a vendored version.nightly: Enable nightly only performance and security related features.
Update Provider Data
To add the updates from the provider-db to the core, run:
./src/provider/update.py ../provider-db/_providers/ > src/provider/data.rs
Language bindings and frontend projects
Language bindings are available for:
- C [📂 source | 📚 docs]
- Node.js
- Python [📂 source | 📦 pypi | 📚 docs]
- Go
- Free Pascal1 [📂 source]
- Java and Swift (contained in the Android/iOS repos)
The following "frontend" projects make use of the Rust-library or its language bindings:
-
Out of date / unmaintained, if you like those languages feel free to start maintaining them. If you have questions we'll help you, please ask in the issues. ↩︎