Architecture variant: no topics, Web Push (including UnifiedPush) + others

[rfc2822]

This is our current favorite architecture. Other architectures we have thought about: #16, #17, #18, #20

Update 25 Dec 2023: UnifiedPush is a 100% compatible subset of Web Push from a WebDAV-Push point of view

---

A key decision is whether to support topics (= multiple clients subscribe to the same topic and then the application server pushes only one "topic update" and leaves sending the single notifications to the push transport) or not. In this architecture we don't have topics. This allows to keep things simple and, more important, to directly support UnifiedPush. The WebDAV server and especially the FCM redirector have to handle a bit more traffic (one notification per client instead of one topic update for all clients), but this comes with the advantage that software components can be less complex: the redirector doesn't need to keep any state and is thus much easier to build, maintain and host. As soon as we drop the "topics" requirement (which came up when studying proprietary APIs like FCM, who always provide topics and it seems common to use them here), it becomes much easier to use other open standards/components.

We aim to support the possibility of other push transports, but for our primary use cases and planned implementations we focus on

Web Push

• for browser apps (like the Nextcloud Calendar app)
• for desktop and mobile apps over UnifiedPush (UP)
• already available in all major Web browsers and for platforms on which UP is supported
• Web Push supports VAPID and Message Encryption and we want to use it

UnifiedPush can be used for mobile (like DAVx⁵) and desktop apps (like desktop Groupware applications or file managers). From an RFC 8030 Application Server point of view, UP endpoints are designed to be 100% compatible RFC 8030 push resources and UP servers can be treated like RFC 8030 Push Services.

• It's already working and established, FCM redirector already exists (when it's even needed [1] [2], which should be clarified)
• Further proprietary transports can be implemented over redirect proxies, if required
• For desktop applications, disadvantage in comparision to SSE directly provided by the Push-capable WebDAV server is that apps need a UnifiedPush distributor / server. However for instance KDE has attempts in this direction. It has more chances to add an existing protocol (UnifiedPush) and required infrastructure to desktop clients instead of defining and adopting a new protocol (WebDAV-Push over SSE).
• E2EE can be implemented on application level: Add payload encryption UnifiedPush/specifications#12

[mar-v-in]

Firebase Cloud Messaging is directly compatible to WebPush notifications. This is used by Chrome and some other Chromium-based browsers to receive WebPush notifications through the Firebase Cloud Messaging infrastructure (which is also used by Chrome). I wrote down how to register as a client app with FCM to receive a token that can be used to push using WebPush protocol here: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0aaeb74#webpush This would allow to completely get rid of the redirect proxy when sending to FCM.

You can also send WebPush notifications to a UnifiedPush endpoint. UnifiedPush currently implements a subset of WebPush (i.e. it does not use VAPID), but it still would delivers the push notification to the client. I think it would make more sense to extend UnifiedPush server-side protocol to fully support the WebPush protocol rather than supporting WebPush AND UnifiedPush in every protocol. UnifiedPush would still be responseible for delivering the push notification to the client on the client-side (using the APIs specified in the Android and DBus specification documents of the UnifiedPush protocol).

Limiting this whole specification to use WebPush exclusively reduces complexity in the specification. If a vendor wants to use any other protocols than WebPush, their best way to do so is to provide a WebPush redirect proxy. Let's unify on one common standard for the server side of push notifications - and with WebPush already having wide support (on Google Android and all major browsers) and being an IETF standard, it seems the obvious choice for that.

[rfc2822]

@mar-v-in I didn't manage to send messages to Android over FCM without sharing a key between the app server (which would be the WebDAV server later) and the client (DAVx5). I have used the Android Firebase API to generate and get a token. This token seems to be bound to the key in google-service.json in the app. When I then send a Web Push (with some payload, because we want payload) request to that token

• without authentication, FCM returns 401
• with a random VAPID key pair (request generated by WebPushDataTestPage), FCM says: "The VAPID credentials in the authorization header do not correspond to the credentials used to create the subscriptions."

Do I have to create the Android subscription like this, with the app server public key (that's also the public VAPID key)? In this case this would not really usable by us, because

1. there may be multiple accounts/servers per client, and I guess we can have only one FCM subscription per client app (because onNewToken would indicate the previous token is now invalid)?
2. the registration over a crafted undocumented Intent is, while very interesting to understand how things work, maybe not something that I'd use in a production app …

Or is there another way? How can I test sending a notification over a POST to the device token without having to know the private key that's built into the app? Because that would be the scenario of WebDAV-Push.

[mar-v-in]

For reference, the code in Chromium is here: https://source.chromium.org/chromium/chromium/src/+/main:components/gcm_driver/android/java/src/org/chromium/components/gcm_driver/GoogleCloudMessagingV2.java

Also, directly crafting the corresponding intents without using a library once was officially documented, see e.g. https://web.archive.org/web/20121206054553/http://developer.android.com/google/gcm/gcm.html#registering (of course way less features back then)
I'm not sure if any of the several official libraries to invoke C2DM has the required functionality (subtypes aren't a popular feature, so I'm not sure if they are exposed directly).

[rfc2822]

The problem with multiple accounts per client would still persist, no?

Let's say we have WebDAV server A (with key pair A) and WebDAV server B (with key pair B). A client which wants to use FCM (DAVx5) gets only one FCM token, which can only be bound to one public key (A_public or B_public).

Or can multiple tokens be generated and used at the same time? Because the FCM Android API only has a onNewToken callback and it looks like if there could only be one active token per app.

Or don't we need multiple tokens and I have understood it incorrect?

(And it may have reasons why they have removed it from the docs?)

[mar-v-in]

You get one token per subtype.

[rfc2822]

Ok thanks. All these undocumented things sound really dirty… but however it's then a client decision (crafting undocumented Intents vs hosting a redirect proxy) and doesn't matter from a WebDAV-Push point of view :)

[rfc2822]

I don't necessarily agree with that.

* You can always redirect WebPush to something else using a push redirector service if needed. In general, the redirector service infrastructure is probably very sensible as it means that WebDAV server implementations don't need to support more than one push protocol themselves. Redirectors can be shared across completely independent WebDAV server implementations.

I wouldn't specify that they have to implement a single backend. May be RFC 8030 but there may be times where RFC 8030 (or a direct successor) isn't used anymore, but WebDAV-Push is. Similar things have happened for many protocols.

That said, it certainly also doesn't do a lot of damage to have an extension point in this version of the protocol where a future specification (or vendor specific extensions) can tie in, similar to how it currently is.

Where is the problem / "damage" with specifying that multiple transports are supported, and RFC 8030 is currently the (maybe only) recommended one?

Regarding UP / Web Push: I have seen that they are too similar as this could be by chance, however I'm still confused that there's no official reference from one to the other, no compatibility table, no definition about missing features etc. And for instance sending VAPID headers to UP without reason, well yes, one could do it, but it still sounds strange to me.

But I think at the end this question won't matter. It's now time to make these things actually work, and how we call the transport then and whether there are two slightly different ones or one for all, shouldn't really make a difference.

---

My biggest previous questions (without having experience in the "push universe") were whether WebDAV-Push could support topics in the sense of FCM (transport does the 1:n multiplication), and it seems that a 1:1 architecture is a better idea becaues of simplicity, E2EE and existing protocols/components. Another question was whether we can support both open and proprietary (and not only Google FCM, but also Huawei Push and maybe others) push systems, and I'm happy to know that this should work without big extra efforts.

If someone sees "big" problems with this architecture (like missing components or that something won't work in reality), please tell us here. In this case we'd had to re-think everything and it should happen as soon as possible. Otherwise we would now build more functional components on all sides (client + WebDAV server) while updating our draft continously.

[mar-v-in]

Where is the problem / "damage" with specifying that multiple transports are supported, and RFC 8030 is currently the (maybe only) recommended one?

The "damage" is complexity, both for the specification itself and implementations.

• If you want to specify the use of UnifiedPush and you want this to eventually turn into an RFC, you would first need to create a proper specification of UnifiedPush server protocol (because, well, proper specifications can only reference other proper specifications and as you noticed yourself, the UnifiedPush server specification is still more like an early draft/sketch than an RFC)
• As you allow multiple transports, you would need to specify how clients should react when they see multiple transports that they support. Register for one or for both? If they registered for UnifiedPush before, but now want to switch to WebPush to make use of encryption, how does that work? What happens if you register the same endpoint for UnifiedPush and WebPush (which is technically possible because UnifiedPush endpoints are also valid WebPush endpoints)? What if the set of supported transports changes on either the server or the client?

no compatibility table, no definition about missing features etc. And for instance sending VAPID headers to UP without reason, well yes, one could do it, but it still sounds strange to me.

There is also no compatibility table or definition of missing features of the WebPush endpoints of the servers of various browsers. Do you know if the push server used for Firefox on Android verifies VAPID for push notifications? Do you care? As long as push notifications arrive when they are sent to the push server and the push server behaves WebPush compliant in the interaction with the application server, the application server should not really care.

Otherwise we would now build more functional components on all sides (client + WebDAV server) while updating our draft continously.

Of course this is certainly an option for exploring possibilities and drafting the protocol. I just want to raise awareness for the risk of later unwanted functionalities and complexities ending up in production deployments which might be hard or impossible to reverse and can lead to clients/servers having to be able to handle "legacy systems" for eternity. The smaller the feature set is that you originally plan to support, the less risk you have of this happening. Intentionally not supporting something while leaving it as a future extension point is what makes a specification flexible and future-proof, not trying to think about every possibility in advance.