bitfireat / webdav-push Goto Github PK

Create a Nextcloud app that sends a Push over POST to a pre-defined URL (of the Push Director) as soon as a contact / event / task changes. Until it's ready, we can simulate this by sending the POST over curl.

When the server pushes notifications to the client, it'll have to send a specific payload.

I'm opening this issue with the intent of discussing and agreeing on the format for this payload.

I think that using XML is probably the best choice. That's really a sentence I never though I'd write (I'm not a huge fan of XML), but I think it's the logical choice given that CalDav is already using XML. Any client can be expected to be able to parse and handle this already, and an extension to CalDav should really just use the same underlying format.

In particular, I think that the message that servers "push" to clients, could include a payload very similar to the result of a PROPFIND querying the etag for the element that has changed:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
          xmlns:C="urn:ietf:params:xml:ns:caldav">
 <D:response>
   <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
   <D:propstat>
     <D:prop>
       <D:getetag>"fffff-abcd2"</D:getetag>
     </D:prop>
     <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
 </D:response>
</D:multistatus>

This tells the client which resource has changed and is enough for the client determine what course of action they want to take (usually, fetch the updated resource).

Aggregation of multiple entries (e.g.: multiple response nodes with a different href each) should be perfectly valid.

See https://github.com/bitfireAT/webdav-push-director-demo

I suggest these steps to get a first demo of DAVx⁵ with Push:

• Set up a test Nextcloud that we can use to test.
• #10 (https://github.com/ArnyminerZ/webdav-push-nextcloud-demo)
• #11 (https://github.com/bitfireAT/webdav-push-director-demo)
  • send the push for any notification, so we can skip the Push Director subscription for now (DAVx5 still has to register for the topic on FCM side),
  • use an easy topic ID generation like md5(collection URL),
  • choose the language/framework so that it can be done most quickly. In the case of FCM-only for demonstration I think this can even be PHP: a script that is called on POST and then forwards the push to FCM.
• #12
  • See https://github.com/bitfireAT/davx5/pull/367 for inspiration :)
• Create demonstration video (@ArnyminerZ)

I'd put code like the demonstration Push Director into this repository for now, too.

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.

• Separate Subscription graphs (I suggest one graph per subscription method) from Overview graph
• Overview graph:
  • Depict possible proprietary subscription APIs somewhere. In the case of Google Calendar, a client (or maybe even the Push Director?) can subscribe to Google Calendar API: Push notifications, which would then act as an Application Server, but with a proprietary protocol (it will send POST /push messages, but in their format).

Prepare DAVx5 so that it supports FCM and initates a sync when it receives a notification.

Is this Push implementation only meant to work with Nextcloud? Personally, I'm not the biggest fan of Nextcloud, but I'm using SabreDAV with some patches. I'm very interested to have this also working with standard SabreDAV. I had a discussion with evert some years ago about the same topic, but we came to no real starting point.

Hopefully this will change now.