api!: remove provider-db handling and provider lookup APIs - #8437
Conversation
713db31 to
8261244
Compare
3854b27 to
d8956eb
Compare
feea15b to
f159d46
Compare
| worse_media_quality: true, | ||
| ..Default::default() | ||
| }, | ||
| _ if is_exact_or_subdomain(&domain, "hermes.radio") |
There was a problem hiding this comment.
hermes.radio settings can likely be removed, cc @rafael2k
The problem is that with v2 encryption is always used unless you try really hard to send plaintext emails by typing email addresses and not using the QR codes, so Delta Chat is likely not working as is.
The project is likely using v1 in some form, so if we want to make current v2 versions usable for rhizomatica/hermes, there are other changes needed.
There was a problem hiding this comment.
i am fine to remove hermes.radio special case, and you are probably right, but i didn't want to make the call in the PR so far. If we remove it, then we can also inline apply_legacy*
There was a problem hiding this comment.
I'm fine removing hermes.radio, we can deal with this in other ways I think.
There was a problem hiding this comment.
Same as with .aco-connexion.org.
There was a problem hiding this comment.
@rafael2k Do you use v2 versions of Delta Chat currently? If it works for you there is no problem keeping the code, but i thought your setup relies on disabling OpenPGP/E2E encryption and removing Autocrypt headers is no longer enough for this with v2.
There was a problem hiding this comment.
By v2 you mean 2.xy.z? Yes.
We do strip all Autocrypt header. If that will not work anymore, I need to change our setup asap.
There was a problem hiding this comment.
There are no unencrypted Autocrypt headers anymore normally, especially since https://delta.chat/en/2026-03-31-zero
When the users get in contact by scanning a QR code, the QR code already contains symmetric key for encryption, and Autocrypt header is sent in the encrypted part. So users get encrypted chats this way. And generally since v2 (https://delta.chat/en/2025-08-04-encryption-v2) encrypted chats never become unencrypted.
Settings like worse_media_quality: true still make sense to make the client send worse quality images, but you cannot disable E2E encryption by intercepting Autocrypt headers to do your own compression anymore.
There was a problem hiding this comment.
i removed hermes/aco-connexion special casing for now. Maybe it's best if we do a dedicated discussion and analysis what would be most helpful for you, @rafael2k
BREAKING CHANGE: provider lookup APIs were removed from CFFI and JSON-RPC. also removes offline provider database code and generated provider data, provider-specific fields in configure/transport paths, and REPL providerinfo.
f159d46 to
2bfe067
Compare
r10s
left a comment
r10s
left a comment
There was a problem hiding this comment.
i created issues for andoid/ios/desktop/ubuntutouch to stop using these apis. should be simple to do (i did on android/ios), so unless we expect and urgent core update these days, i would say this PR can be merged at any time. if we want to play save, give UIs a little time
|
about nauta.cu, there was also some logic to treat it as a chatmail server so when multi-device mode is disabled it deletes messages from the server immediately just as with chatmail, but I guess that was never influenced by provider-db but something hardcoded in core even before this PR |
|
There is no special nauta.cu logic for deletion, since #8240 messages are deleted automatically when |
|
yikes that explains reports I just got from people with full inbox |
This comment was marked as outdated.
This comment was marked as outdated.
Closes #6575. Core is removing this API: chatmail/core#8437.
5 participants
this removes all provider-db related code and data because it's not needed and we do not want to care or maintain for provider-db anyway.
Note that 6dddb97 re-introduces very few exceptions. I verified with adb regarding nauta.cu that it's still needed to provide a working experience for a sizable number of users so i guess it makes sense to retain the exceptions. the other two (hermes and aco-connexion) are less clear but i kept them anyway for now.
provider-db is also preparing for archiving chatmail/provider-db#341