Minimal-dependency install?

Mutual Help
1

I really like the decentralized structure and reliability and use of standards in Deltachat; I’d like to start using it.

So I’m trying to install Deltachat on my Debian stable desktop. Unfortunately, there isn’t a Deltachat package in Debian stable. So I’ve been trying to check the dependencies manually.

And some of them are in Debian, which is great. “rustc” (the Rust language), the QT/QML dependencies, those are all there. But the deltachat-core-rust package has 41 dependencies, all of which seem to have a dozen or so dependencies, and so on.

I want to be able to investigate all the dependencies before installing them. I don’t want to run a command which installs an unknown number of unknown dependencies.

How can I install Deltachat with really minimal dependencies (other than those in Debian stable)? I don’t mind using a text-based client or some such. Are there any Deltachat projects parallel to snac2?

Thanks in advance for any advice!

2

Delta Chat is deltachat-core-rust, unless you want to use the ancient c version.

deltachat-core-rust has reproducible builds with nix and there are some projects for auditing rust dependencies (https://rustsec.org and GitHub - crev-dev/cargo-crev: A cryptographically verifiable code review system for the cargo (Rust) package manager.).

The rustc version available in Debian might be too old to build core, you’d need to check.

Also I doubt that Debian maintainers read and audit every line of code that is in the Debian repositories. Anyways in case you find something bad in dc-core dependencies please let us know immediately.

Suppose I’m a bit paranoid/worried about evil/bad dependencies: The bigger risk could be with delta chat-desktop (based on electron) because it uses npm dependencies, while we try to reduce npm dependencies, there are still 600 of them, and I have maybe reviewed 1% myself so far.

So text based clients, there is a python package deltachat-cursed/README.md at master · adbenitez/deltachat-cursed · GitHub but it doesn’t have all features. if you want to use qt there is deltatouch (possibly complicated to build because it is made for ubuntu touch, and can also be build for nixOS, but probably not easy on debian) or kdelachat (based on qt, but very early in development).

If you want to contribute to an existing client or want to make your own, we are happy to answer any questions that you might have. The process is simple, link to the cffi interface of deltachat code (libdeltachat library) or talk to core as a separate process via jsonrpc over stdio (deltachat-rpc-server binary) and if you want to use core there is the third option of using deltachat core as a statically linked rust dependency. + there are also wrapper libraries for python, go, nodejs/javascript.
Making a client is not that hard as this blog post shows, @lk108 started deltatouch in his spare-time: Introducing DeltaTouch, a new community created client for Ubuntu Touch - Delta Chat

Related:
List of all known clients: List of all know Client Projects

3

you can look into Cargo.lock, there all resolved dependencies are listed.

Also you could run the flatpak, because flatpak has some sandboxing if you want to restrict what it can do: Install Delta Chat on Linux | Flathub

4

The easiest way to review dependencies is probably to run cargo vendor and look into the folder with downloaded source code.

1 Like
5

I’m sure the Debian devs don’t read, mark, learn, and inwardly digest every line of code. Fortunately, even imperfect review has some effect, and reviewing even 1% of deltachat-desktop’s npm deps is useful; my thanks for your efforts on it.

I’m not promising to read every line of the dependencies, either! By “check”, I meant a much less time-consuming process. I’d like to know what they are, and at least something about them. This is not because I have any specific reason to suspect anything bad; if I acquired one, I would let you know.

Thank you for all the advice; I’ve used it to do some more reading, and will post on that below.

1 Like
6

TL;DR: A Deltachat client with few deps is doable. The Deltachat core has too many deps to be plausibly manually reviewable, or packagable in a Debianlike distro. This is hindering Deltachat from meeting the packaging goal it is focussing on; Deltachat would be in more repos if it had fewer deps.

I went through the list of known clients. A low-dependency client doesn’t seem too difficult. I haven’t actually installed it, but it seems Kdeltachat has done a good job of minimizing non-standard dependencies, and might be the first thing to try. npm is indeed a bit of a show-stopper if you’re trying to minimize deps :), so delta-chat-desktop is indeed unsuitable. Deltatouch says it runs on desktop (at low res), but relies on some Ubuntu-Touch-specific elements, like ContentHub (for external-file handling). Something that would run on Debian could probably be made to run on Mobian mobiles with only minor UI adjustments, and vice-versa.

On to the deltachat-rust-core the clients all depend on. I didn’t know there was an obsolete version in C (or that it might still be usable); thank you, Simon! In retrospect I should have known, as the C version of the deltachat core was in Debian testing, and was removed in 2021 only because it was unmaintained upstream after the Rust rewrite. The old C package was 0.510.1, and lacked some of the functionality of the 1.0 Rust rewrite that replaced it.

The devs say “For now, we focus on getting stable releases into all app stores (Google Play/iOS/Windows/macOS/Linux repositories) as native apps.” I know there’s strong interest in a simple-to-use, reliable, decentralized, encrypted messenger, especially from Mobile Linux. I see that a Debian dev, Micah, volunteered to package the old C version, and did it in 5 months.

So how many deps does the core have? 41 direct deps, but total deps? Grepping Link2xt’s recommendation (cargo vendor might well be easier if I had downloaded everything), the raw Cargo.lock file for Deltachat for “[[package]]”, gives an answer.

Deltachat-rust-core has 752 dependencies (counting recursively, dedupped; 203 of these deps have no deps of their own). Better than Mastodon. Some, like Brotli, are in Debian already, and it might be easyish to lop off a few large branches of deps, but 752 deps would probably be impractical to package in any Debianlike repository (if there were few deps, it would certainly be in all Debian-based distros already). This says I can’t even hope to check all the deps, even superficially. Which in turn says I can’t expect that most of the people I want to talk to will use the current deltachat-core-rust. Which is a great pity, as Deltachat is otherwise excellent.

This is a really depressing conclusion. Is there any probability of Deltachat’s core having fewer deps in the future?

7

The c version also was impossible to build for windows, at least multiple tries of different people didn’t mange to build/link it for windows.
With rust everything go easier and also more stable, especially builds for all platforms and architecture.

There was also another reason for removing Deltachat core from Debian again, deltachat has updates at least every quarter year, while debian’s release cycles are longer. Though nowadays it could be worth to try again, though I think in a dedicated ppa might be better suited for faster updates.

8

There is a pending PR Remove old iroh 0.4 by link2xt · Pull Request #5783 · deltachat/deltachat-core-rust · GitHub reducing the number to 676 crates. Many dependencies are split into smaller “crates”, e.g. in case of macro packages there is usually a second -impl package. Cryptography packages have each algorithm (rsa, sha2, …) in a separate crate. windows_* dependency which is not used outside of windows build target is split per architecture. There are also many duplicate dependencies of the same crate with different version which is not really worth the effort to eliminate because every time a new dependency is released crates that depend on it update at their own pace.

2 Likes
9

I already made some adaptions for DeltaTouch to run on Mobian. It’s not perfect and not properly packaged yet, but it can be installed manually and can be used without Content Hub: Installation on Mobian and Droidian (manual, experimental) - lk108/deltatouch - Codeberg.org

2 Likes
10

You know, I was honestly dreading a “We don’t care, go away” response. Instead I got an informative answer and information on a Mobian build. :grinning:

This despite the fact that, in light of a closer look at the deps, I was far too hasty and too harsh. It seems the vast majority of the Deltachat crate’s 42 direct Rust deps are already packaged in Debian. Here’s a list, probably buggy and certainly ill-informed, fixes welcome:

  • async (Debian has lots of things called rust-async-[something])
    – async-broadcast (rust-async-broadcast exists in Debian)
    – async-imap (all deps, recursively, are in Debian as rust-[cratename], except the crate imap-proto, which has only one dep, which is already packaged in Debian.
    – async-native-tls (rust-async-tls? async-native-tls’ 6 deps are all in Debian as rust-[cratename])
    – async-smtp (10 deps, all in Debian as rust-[cratename])
    – async_zip (rust-async-zip)
  • brotli brotli rust-brotli is in Debian
  • escaper (rust-shell-escape? the escaper crate has one dep, entities, which is rust-entities)
  • fast-socks5 (no, but rust-socks; fast-socks5 has 6 deps, all in Debian as rust-[cratename])
  • fd-lock (rust-fd-lock))
  • hex (rust-hex)
  • hickory-resolver (rust-hickory-resolver)
  • humansize (rust-humansize)
  • image (rust-hickory-resolver))
  • iroh (to be removed, so I didn’t check)
    – iroh-net [edit: (77 deps, 20 not already in Debian)*]
    – iroh-gossip [edit: (20 deps, 3 not in Debian, 3 overlap with iroh-net)]
  • kamadak-exif (rust-kamadak-exif)
  • mailparse (rust-mailparse)
  • mime (rust-mime)
  • num_cpus (rust-num-cpus)
  • num-derive (rust-num-derive)
  • percent-encoding (rust-percent-encoding)
  • parking_lot (rust-parking-lot)
  • pgp (in Debian as pgpgpg)
  • qrcodegen (rust-qrcodegen)
  • quick-xml (rust-quick-xml)
  • quoted_printable (rust-quoted-printable)
  • reqwest (rust-reqwest)
  • rust-hsluv (no, but node-hsluv, python3-hsluv; rust-hsluv depends only on three crates, all of which have Debian packages: rust-serde, rust-serde-json, and rust-serde-derive)
  • sha-1 (rust-sha-1)
  • smallvec (rust-smallvec))
  • strum (rust-strum)
    – strum_macros (rust-strum-macros)
  • tagger (crate has no deps)
  • textwrap (rust-textwrap))
  • tokio (rust-tokio))
    – tokio-io-timeout (rust-tokio-io-timeout))
    – tokio-stream (rust-tokio-stream)
    – tokio-tar (has 7 deps, all in Debian: rust-filetime, rust-futures-core, rust-libc, rust-redox-syscall, rust-tokio and rust-tokio-stream, in Debian as above, and rust-xattr)
  • toml (rust-toml)
  • url (rust-url)
  • uuid (rust-uuid)

If my count is right, that’s nine unpackaged deps, recursing [edit: not counting the two iroh crates]. It doesn’t look too insanely difficult to package Rust crates for Debian, either. It looks doable.

There are also Debian packages for all of the dev deps except testdir (and all of testdir’s deps are in Debian). There are Debian packages for all the deps, recursively, except typescript-type-def-derive and typescript-type-def, of the other crates on that page (deltachat_derive, deltachat-time, format-flowed, ratelimit, deltachat_ffi, deltachat-jsonrpc, deltachat-rpc-server, deltachat-repl, deltachat-contact-tools).

Debian stable’s 2-year update schedule is a pain, despite its upsides. Debian-backports is increasingly used to get more recent software. But one of the major advantages of Deltachat, to me, is that it is standards-based, so ideally different versions should be able to communicate.

A major problem I’ve had with Jami is that everyone is getting it from different repos, they all update at different times, and even two copies of the exact same version from different sources can’t always actually communicate. Even by text. If Deltachat can resolve that huge annoying overhead, that would be a great feature.

3 Likes
11

one iroh stays, currently there are two versions of it. It’s used for backup transfer and realtime channels in webxdc, if you don’t need those features, you could make a fork with iroh removed.

12

why would one need all source code dependencies to be packaged in Debian for it to be part of Debian, are so many people really building stuff from source this days? I have been using Debian for some time now and I always install the built binaries from the debian repos, the only thing needed is for Delta Chat core library and/or JSON-RPC server to be included

sorry if I misunderstood something

oth, having some super-old delta chat client in Debian incompatible/buggy with recent versions and with security and interoperability issues is not appealing, more if the Delta Chat team doesn’t have control to push new versions when needed, for an offline/single-player tool it is fine but for a multi-user networked application fragmentation is harmful

on the pros side: it is good if Delta Chat is in Debian and other stores because then more users can discover the app

13

@Simon: Thank you, I’ve updated the list accordingly. You’re right, leaving the iroh crates out is very tempting.

I imagine this is not news, but something a little bit bad.

14

@adbenitez: Yes, I think most Debian users use pre-compiled binaries, they usually work well. But the built binaries in the repos have to be built from source, reproducibly. :slightly_smiling_face:

From a developer’s point of view, making multiple versions intercompatible is extremely unappealing. From the point of view of a user, it is very appealing.

I like to talk to people who really can’t update their own software, for various reasons, and people who always have the very latest beta version of everything. For us all to talk together without endless complications, we need intercompatibility. Deltachat actually has a huge headstart here, as it is based on mostly-quite-stable standards, like IMAP.

I agree on the accessibility; anything in the Debian package database will be very easily available in the majority of Linux distros. And if it’s as easy-come-easy-go as apt install deltachat, people install it on a whim, just to try it out.

1 Like
15

Brotli crate is GitHub - dropbox/rust-brotli: Brotli compressor and decompressor written in rust that optionally avoids the stdlib (Rust implementation by dropbox), Debian package is GitHub - google/brotli: Brotli compression format (C implementation by google).

2 Likes
16

This is old advisory, deltachat currently uses tokio 1.38.1 which is not affected.

2 Likes
17

Thanks, I edited the list to fix brotli.

Ah, okay, I misunderstood. Apologies. Tokio is a dep of some of deltachat’s direct deps, like iroh-gossip, and some of those allow affected versions of tokio. But other inderiect deps of deltachat, like tokio-util, require non-vulnerable versions. So deltachat as a whole will demanda non-vulnerable version, and it should be fine. I should have looked more closely.

18

I guess you could also run cargo vendor, then (rip)grep for the keywords to find out if the vulnerable feature is even used

19

I’m a bit unsure about the purposes of the nine crates deltachat_derive, deltachat-time, format-flowed, ratelimit, deltachat_ffi, deltachat-jsonrpc, deltachat-rpc-server, deltachat-repl, deltachat-contact-tools. I don’t think the core depends on them; some of the clients seem to depend on some of them (it seems deltachat-cursed depends on bindings from the deltachat-rpc-server crate, for instance, and that Deltachat-desktop might need deltachat-jsonrpc), but I’m unsure of the details, even after reading the readmes here.

Clients that might work in Debian

All clients depend on deltachat-rust-core. Some depend on some of the the nine other Deltachat crates listed above. Otherwise, if I’ve understood correctly:

Deltatouch (QML & C++) was originally designed for Ubuntu Touch, but can run on Debian and Mobian, using only deps already in Debian. It is still in the process of being adapted for Mobian, but quite usable. It is officially-supported[correction: endorsed].

Kdeltachat (also QML & C++) can run on Debian and Mobian, also using only deps already in Debian. It does not yet have all the features of some of the other clients, but it is quite usable. It is in use on Pinephones, probably on Mobian, and the interface works well on mobile.[1][2]

Deltachat-cursed (Python) is a command-line client. It is still implementing some features.

Deltachat-desktop (Typescript) has 600-odd npm deps (list of Deltachat-desktop’s npm deps). The core has more, and wasn’t as bad as it looked, so I guess I could got through the deltachat-desktop deps and see how many aren’t in Debian, but at first glance it seems like “too many”, and there are other clients available. [edit: Deltachat-desktop is fully convergent and works just fine on mobile, too.]

There is also the Debian-Mobian convergence goal; I suspect, subject to correction, that it might be easier to make the mobile clients UIs adaptively desktop-friendly than to make the dedicated desktop client work on mobile.

I think the other clients are all Android or iOS-specific, or not in active development (Kdeltachat was last updated in January, Deltachat-cursed in April, the rest within the last week). If I’ve missed anything, please let me know.

20

There is also the Debian-Mobian convergence goal

DeltaTouch (as well as DC Desktop) is already convergent :grinning: and I use it on my Debian laptop. Main issue atm is that emojis are not displayed correctly. Including the Noto Color Emoji font would double the size of the package, and I think the licenses are not compatible.

screenshot-convergence
screenshot-convergence1283×774 104 KB

2 Likes