support apps to subscribe to general (non-chat) push notifications? (Email-note spec?)

[testbird]

This issue is to let interested devs find out about the idea of building an IMAP based push notification alternative, to be used instead of proprietary third-party push message services:

https://gitlab.com/foss-push/planning

It looks as if deltachat-core has most of the needed features implemented, except a spec that allows the separation of notification messages from chats.
So it looks as an ideal basis to implement a mobile push client service (daemon).

[testbird]

A further thought:
Once there actually is one push message client (daemon) available per device. May it then make sense to also let deltachat-android subscribe to chat messages through this daemon, instead of shipping and runninig its own deltachat-core?

[r10s]

I do not think deltachat-core gets superflous, it's only the IMAP-IDLE call that would be replaced by sth. else to wake up on new messages. However, it's not 100% clear to me how this "sth. else" should work.

[testbird]

I see, it depends on if it would make sense for the push client daemon (the sth. else) to fetch and store messages in a db, or just "ping" appropriate apps with change notifications when detecting a new notification message.

I don't know what the referenced android inter-process communication is capable to support. https://stackoverflow.com/questions/5740324/what-are-the-ipc-mechanisms-available-in-the-android-os But hopefully message passing is possible.

An advantage of having the daemon run the whole deltachat-core (including chat message database) may be that it could allow other protocol chat apps to (also) communicate over Email-chat using the deamon (in addition to getting change notifications for any other protocols).

Well, and not all chat apps that want to support Email-chat would have to ship their own deltachat-core, if there were some local server/daomon access available.

---

Edit:
Maybe using androids "content-providers" may allow deltachat-core to provide frontend apps with access to the message database?
https://developer.android.com/guide/topics/providers/content-providers.html
It even sounds as if notification of DB observers is possible: https://stackoverflow.com/questions/15610527/notifychange-with-changed-uri-from-contentprovider-update

[testbird]

Hm, thinking about design consequences..., there might then be three package abstraction levels:

deltacore-lib (imap messaging)

The current deltachat-core, which would get support to handle not just chat messages, but both the Email-chat and an Email-note folder separately.

deltacore-android (imap push client for android)

Would be a new package that uses deltacore-lib to create one android content-provider for notifications and one for chat messages, and incorporates the email account setup UI from the current deltachat-android chat client. This effectively already establishes a FOSS "pushcore-android", a push client service for android. And it could be made in a way that enables others to make pull requests to also support other protocols to listen for messages, like XMPP etc. Builds of other -platform packages may be made to provide apps on other platforms with their particular way of push data access (instead of android content-providers).

deltachat-android

May then depend on the chat content-provider from delta/pushcore?-android to provide its chat interface front-end to the user, instead of shipping and using a copy of the current deltachat-core.

Other android apps can depend on deltacore-android and request access to get notifications and/or the Email-chat messages.

[DJCrashdummy]

well, it gets pretty confusing now with several streams on different platforms and different naming...

but if i got this discussion right, i simply want to record, that the Push Client should only process the signaling and no messages (payload) which are only relevant to the different App Clients.

in the case of DeltaChat it may imply that there will be 3 levels, since the App Client is split into 2 levels ("backend/frontend") which is completely up to the respective app (App Client) developers.

---

for the emphasized vocabulary please have a look at https://gitlab.com/foss-push/planning#vocabulary. i tried to use it to stay in one line to not further confusion.

[testbird]

Thanks for your note, I now tried to adjust the bolded parts above to follow the vocabulary.

Email based messages don't require a "payload" like in the body, and the envisioned Email-notify spec won't need to require nor forbid either.

The point here was that deltachat currently consists of two packages, deltachat-core and the frontend UI.
But it could be possible to split the current deltachat-core functionality into a deltacore-lib package (imap support coded in C) and a new package that resembles the push client functionality (if app clients desire, passing "payload" to app-client frontends as well). And this newly split-off package could be the basis for implementing a more generic free push client (for android and others).

[DJCrashdummy]

ok... now i've got the point: you are talking about the concrete possibility of implementing this in one way (with the DeltaChat-base), and i am talking about a general foss-push eco-system.

for sure separating the software which handles the IMAP-push system and IMAP-messages is a kind of unnecessary if you think about this one use-case... but as you somehow already wrote: hopefully someday we have a generic foss-push system supporting different push methods which can be extended.

[testbird]

hopefully someday we have a generic foss-push system supporting different push methods which can be extended

Right, separating some "deltacore- or pushclient-android" package from deltachat could be done in a way that allows extending it to support additional on-the-wire protocol methods.

[r10s]

closing this for now here, of course, the discussion can go on in the new support forum at https://support.delta.chat