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.
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?
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 or not, trivially, since either device could scan the QR code on the other.
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.
Another apology. I should clarify that histories and files can be quite big, 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 might complement a compact just-contacts-and-profiles transfer, especially if the chat-contents backup was encrypted using the keys in the profile backup. But if messages are ephemeral, then just abandoning the history would be a lot easier.