This way, the statistics / self-reporting bot will be made into an opt-in regular sending of statistics, where you enable the setting once and then they will be sent automatically. The statistics will be sent to a bot, so that the user can see exactly which data is being sent, and how often. The chat will be archived and muted by default, so that it doesn't disturb the user. The collected statistics will focus on the public-key-verification that is performed while scanning a QR code. Later on, we can add more statistics to collect. **Context:** _This is just to give a rough idea; I would need to write a lot more than a few paragraphs in order to fully explain all the context here_. End-to-end encrypted messengers are generally susceptible to MitM attacks. In order to mitigate against this, messengers offer some way of verifying the chat partner's public key. However, numerous studies found that most popular messengers implement this public-key-verification in a way that is not understood by users, and therefore ineffective - [a 2021 "State of Knowledge" paper concludes:](https://dl.acm.org/doi/pdf/10.1145/3558482.3581773) > Based on our evaluation, we have determined that all current E2EE apps, particularly when operating in opportunistic E2EE mode, are incapable of repelling active man-in-the-middle (MitM) attacks. In addition, we find that none of the current E2EE apps provide better and more usable [public key verification] ceremonies, resulting in insecure E2EE communications against active MitM attacks. This is why Delta Chat tries to go a different route: When the user scans a QR code (regardless of whether the QR code creates a 1:1 chat, invites to a group, or subscribes to a broadcast channel), a public-key-verification is performed in the background, without the user even having to know about this. The statistics collected here are supposed to tell us whether Delta Chat succeeds to nudge the users into using QR codes in a way that is secure against MitM attacks. **Plan for statistics-sending:** - [x] Get this PR reviewed and merged (but don't make it available in the UI yet; if Android wants to make a release in the meantime, I will create a PR that removes the option there) - [x] Set the interval to 1 week again (right now, it's 1 minute for testing) - [ ] Write something for people who are interested in what exactly we count, and link to it (see `TODO[blog post]` in the code) - [ ] Prepare a short survey for participants - [ ] Fine-tune the texts at https://github.com/deltachat/deltachat-android/pull/3794, and get it reviewed and merged - [ ] After the next release, ask people to enable the statistics-sending
deltachat-jsonrpc
This crate provides a JSON-RPC 2.0 interface to DeltaChat.
The JSON-RPC API is exposed in two fashions:
- A executable
deltachat-rpc-serverthat exposes the JSON-RPC API through stdio. - The JSON-RPC API can also be called through the C FFI. It exposes the functions
dc_jsonrpc_init,dc_jsonrpc_request,dc_jsonrpc_next_responseanddc_jsonrpc_unref. See the docs in the header file for details.
We also include a JavaScript and TypeScript client for the JSON-RPC API. The source for this is in the typescript folder.
Usage
Using the TypeScript/JavaScript client
The package includes a JavaScript/TypeScript client which is partially auto-generated through the JSON-RPC library used by this crate (yerpc). Find the source in the typescript folder.
To use it locally, first install the dependencies and compile the TypeScript code to JavaScript:
cd typescript
npm install
npm run build
The JavaScript client is published on NPM.
A script is included to build autogenerated documentation, which includes all RPC methods:
cd typescript
npm run docs
Then open the typescript/docs folder in a web browser.
Development
Running the example app
Testing
The crate includes both a basic Rust smoke test and more featureful integration tests that use the TypeScript client.
Rust tests
To run the Rust test, use this command:
cargo test
TypeScript tests
cd typescript
npm run test
This will build the deltachat-jsonrpc-server binary and then run a test suite.
The test suite includes some tests that need online connectivity and a way to create test email accounts. To run these tests, set the CHATMAIL_DOMAIN environment variable to your testing email server domain.
CHATMAIL_DOMAIN=ci-chatmail.testrun.org npm run test
Test Coverage
Running npm run test will report test coverage. For the coverage to be accurate the online tests need to be run.
If you are offline and want to see the coverage results anyway (even though they are inaccurate), you can bypass the errors of the online tests by setting the
COVERAGE_OFFLINE=1environment variable.
A summary of the coverage will be reported in the terminal after the test run. Open coverage/index.html in a web browser for a detailed report.