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.
| } | ||
| } | ||
| /// Applies a few select non-default config values that used to come from provider database. | ||
| async fn apply_legacy_domain_config_defaults(context: &Context, addr: &str) -> Result<()> { |
There was a problem hiding this comment.
This whole function can likely be deleted if hermes provider is deleted.
| match self.certificate_checks { | ||
| ConfiguredCertificateChecks::OldAutomatic => { | ||
| provider_strict_tls.unwrap_or(connected_through_proxy) | ||
| if disable_strict_tls { |
There was a problem hiding this comment.
This is the same as !disable_strict_tls && connected_through_proxy.
There was a problem hiding this comment.
yes, but i am not really a fan of such short-circuiting behaviour. In Python that was considered an issue by a number of devs, until guido introduced the ternary operator operator which would read here like this:
False if disable_strict_tls else connected_through_proxy
So i'd prefer the current more verbose form, but will change it if you insist :)
There was a problem hiding this comment.
yes, but i am not really a fan of such short-circuiting behaviour.
connected_through_proxy and disable_strict_tls are simple bool variables, so there is no short-circuiting in this case, can also be connected_through_proxy && !disable_strict_tls and will likely compile to exactly the same code. But not important, can be just marked as resolved.
There was a problem hiding this comment.
i found a third solution directly in the match arms. reads nicer than either of our approaches imo.
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
| /// Provider.db lookup was removed, but a handful of domains still need these overrides, | ||
| /// so they are hard-coded here instead. | ||
| pub(crate) fn legacy_settings_for_addr(addr: &str) -> LegacyProviderSettings { | ||
| let Ok(email) = EmailAddress::new(addr) else { |
There was a problem hiding this comment.
Maybe the function should be resultified, get_provider_info was returning an error in this case. Then there is also no usage of LegacyProviderSettings::default() (related discussion at https://github.com/chatmail/core/pull/8437/changes#r3631683726).
3 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