Push delivery mechanism

[WhyNotHugo]

For vdirsyncer (and probably for other native desktop/server applications), having a websocket where messages indicating updates are sent would be the logical choice. It builds on HTTP (which is already the base here), and should be usable by clients without additional infrastructure (aside from the CalDav server itself).

However, I understand that for Android and iOS this MUST go through a third party server which then relays connections. Support for UnifiedPush aligns very closely with those requirements too, so I think it makes sense to keep these three in the same bag.

Is it even feasible to have a proxy service connecting WS->Apple and WS->Google? It seems that the client implementation would be messy, since it's not the client itself that subscribes to notifications, but this unusual proxy.

To summarize this a bit, a client can subscribe to push notifications with a server, but may want one of two approaches:

• Send an webhook-like request to an external service (e.g.: Apple's notification service).
• Upgrade to websocket, and send push notifications there.

On top of this, the webhooks themselves need a payload format specific to what Apple/Google/UnifiedPush expect. Again, the only thing that comes to mind here is a proxy that does this conversion, since I can't imagine an extension to CalDav taking into account the nuances of these third party services.

I'm curious to hear more about what kind of designs you have in mind; I'm sure you've given this aspect a lot more though.

[devvv4ever]

Hi Hugo, the basic interaction would more or less be like seen here on the graphic. This is how most Push mechanisms basically work I think. We've looked a bit at the pretty new W3C Push API and on JMAP Push. This all only covers a typical Server-Client system.

The payload here would not be actual user data. It would only be a trigger for the client containing the servers collection id a user has subscribed to earlier. So the notification provider does not know which data will be transmitted - it only tells the client that it should sync a certain collection of the CalDAV server.