feat: stop requiring XDELTAPUSH capability for push notifications - #8454
Conversation
cb60880 to
feb8def
Compare
Can also move the discussion here from #8454 (comment) It is not clear that it is rare as i checked mailcow and it supports metadata out of the box and simply stored the token on the inbox. @Hocuri checked gmx and it does not support metadata (including post-login). The token is encrypted, but it is encrypted once per profile and not per transport, so i think we should start encrypting it per-transport and not into the global config value (not in this PR). |
|
i am not convinced spurious setmetadata calls are a real-world problem we want to care about, but added a commit to avoid spurious setmetadata calls, anyway. |
157e235 to
3c19c2a
Compare
|
i also dropped getPushState support, and rebased the PR into two clean commits (not to be squashed on merge) |
3c19c2a to
8440c1b
Compare
register device token if XDELTAPUSH IMAP capability is available (current relay setup provides it) or if "maxsmtprecipients" IMAP metadata key is available (relays since May 2026 provide it), allowing chatmail relay setups to drop XDELTAPUSH capability marker with the next release while retaining push notification support.
Since deltachat/deltachat-ios#3224 pushstate is not used (android, desktop etc. never used it, only ios)
8440c1b to
390d8a1
Compare
2 participants
try to register device tokens if
XDELTAPUSHin IMAP capabilities ordelta/maxsmtprecipientsmetadata key is present, so the PR works for both old and future relays that will drop XDELTAPUSH.Also removes the unused
getPushStateAPI and simplifies/private/devicekeymetadata token key writing to be ASCII, and thus not in need of LITERAL+ encoding.see also #8448