# Reducing the number of dependencies for packaging \[Iroh, OpenSSL\] **URL:** \ **Category:** Feature Proposal\ **Created:** [December 16, 2025, 5:22pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481 "2025-12-16T17:22:33Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![link2xt](https://forum.delta.chat/user_avatar/forum.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://forum.delta.chat/u/link2xt)\ **Post date:** [December 16, 2025, 5:22pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/1 "2025-12-16T17:22:33Z")
Continuing the discussion from [P2P and proxy settings](https://support.delta.chat/t/p2p-and-proxy-settings/4274/17): > [@P2P and proxy settings](https://support.delta.chat/t/p2p-and-proxy-settings/4274/17): > > Slightly offtopic, but would it be reasonably possible to exclude some extended features at compile time, making a sort of Deltachat Lite? It would be much easier to package (Iroh, used for P2P, is huge), and could act as an on-ramp. I don’t think we can exclude Iroh 0.35 because it is used for “add second device” feature that is not optional. We generally don’t want users to handle backups .tar files manually when possible. Another huge dependency is OpenSSL, it can be excluded and replaced with Rustls. We currently maintain OpenSSL for compatibility with nauta.cu which has self-signed TLS certificate and algorithms that Rustls refuses to support at all (RSA1024 and SHA1 IIRC). It is used when “strict TLS” is off. However it will still be a problem for users who use such servers and likely not help with packaging efforts because non-vendored OpenSSL is already packaged in all distros. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [December 18, 2025, 12:30am UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/2 "2025-12-18T00:30:38Z")
> [@link2xt](#): > > I don’t think we can exclude Iroh 0.35 because it is used for “add second device” feature that is not optional. We generally don’t want users to handle backups .tar files manually when possible. Add-second-device transfers user profiles and contacts, and optionally chat histories and shared files, right? Doing that in globs over an e-mail backend would send it all via a server; is that acceptable if it’s E2EE? How about doing the initial transfer via a screen-and-camera link, since slow seems acceptable here? ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 24, 2026, 4:26pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/3 "2026-02-24T16:26:22Z")
@s0ph0s asked about removing the IMAP METADATA extension, used for notifications and Iroh setup, from the serverside: > [@Chatmail: IMAP METADATA extension to set up notifications and Iroh relays](https://support.delta.chat/t/chatmail-imap-metadata-extension-to-set-up-notifications-and-iroh-relays/3540): > > Hello! I’m working on [implementing chatmail support in the Mox email server](https://github.com/mjl-/mox/issues/251). I have just noticed that both notifications and the Iroh relay are set up using the IMAP METADATA extension. It seems like: Iroh is configured by returning a server URL from GETMETADATA "" /shared/vendor/deltachat/irohrelay Notifications are configured by calling SETMETADATA "" /private/devicetoken\tuser@host.tld notification\_token where user@host.tld is replaced by the actual email address, \t is a tab character, an… ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 24, 2026, 4:47pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/4 "2026-02-24T16:47:09Z")
For me, handling .tar files and not getting notifications would be a negligable price to pay for \>tripling the number of people I’d be able to talk to, and more-secure installs. (I would now also lose the experimental calls functionality, but I haven’t actually used it yet, and text-only is better than nothing). I already do not get notifications unless running the app, and honestly I turned them on for user testing, not because I want notifications. Nor will a Linux OS aggressively kill background processes and require I use a proprietary centralized notification service. Correct me if I’m wrong here, but I think I could create a new profile on my new device, connect it to a profile on my old device, and send the tarfile E2EE. That doesn’t sound too hard to do manually. Using this method, I could also [Reverse the "Add 2nd Device" flow](https://support.delta.chat/t/reverse-the-add-2nd-device-flow/3965) or not, trivially, since either device could scan the QR code on the other. ---
**Author:** ![s0ph0s](https://forum.delta.chat/user_avatar/forum.delta.chat/s0ph0s/32/2392_2.png) [@s0ph0s](https://forum.delta.chat/u/s0ph0s)\ **Post date:** [February 24, 2026, 5:15pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/5 "2026-02-24T17:15:58Z")
In that thread, I’m not asking for it to be removed. I’m asking for confirmation whether I’ve understood the design correctly so that I can implement matching code in Mox. If it became unnecessary, that would certainly be easier for me! But I’m not requesting that per se. I just want to know what the requirements are. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 24, 2026, 5:17pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/6 "2026-02-24T17:17:20Z")
This would also effectively [Add Lockdown Mode](https://support.delta.chat/t/add-lockdown-mode/4357) . But this is not something for which there are currently resources: > [@P2P and proxy settings](https://support.delta.chat/t/p2p-and-proxy-settings/4274/18): > > if is all open source, so you can just do it slight_smile for the current dev team, it is indeed not reasonable to remove resources from other areas to a maintain a “lite” version; it is lots of effort to release that on all platforms - on desktop the effect would be not noticeable as largest part is electron runtime but also when using tauri, stripping down further seems not reasonable when looking at the android sizes: Delta Chat got [smaller over time](https://download.delta.chat/android/) - eg. android 1.0 was 64 MB - while … ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 24, 2026, 5:18pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/7 "2026-02-24T17:18:26Z")
Sorry for misinterpreting you! ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 24, 2026, 7:29pm UTC](https://forum.delta.chat/t/reducing-the-number-of-dependencies-for-packaging-iroh-openssl/4481/8 "2026-02-24T19:29:17Z")
> [@Minim](#): > > Add-second-device transfers user profiles and contacts, and optionally chat histories and shared files, right? Doing that in globs over an e-mail backend would send it all via a server; is that acceptable if it’s E2EE? How about doing the initial transfer via a screen-and-camera link, since slow seems acceptable here? Another apology. I should clarify that histories and files [can be quite big](https://support.delta.chat/t/maximum-message-size-issues/4781), and transferring all of those via e-mail would be slow and put a heavy load on the relays. Profile and contact data would be comparatively compact. Separate [export of individual chat contents](https://support.delta.chat/t/export-chat-to-zip/1225) might complement a compact just-contacts-and-profiles transfer, especially if the [chat-contents backup was encrypted](https://support.delta.chat/t/researching-a-zero-trust-storage-layer-for-deltachat-core-rust-thoughts/4554/8) using the keys in the profile backup. But if messages are ephemeral, then just abandoning the history would be a lot easier.