Re: [dispatch] Potential incoming work: web push for IMAP, CalDAV and CardDAV

[Michael Toomim <[e-mail]>]

Bron Gondwana:
> It looks like the conversation went a long way down this path, which by my reading is "ask the server to maintain a long running connection and keep pushing updates down it" which is a slightly different use-case from the push proposals I was making, which are:
> 
> Client establishes a relationship with a third party push server (potentially via some platform specific, highly efficient protocol - e.g. APNs <https://en.wikipedia.org/wiki/Apple_Push_Notification_service> or GCM <https://en.wikipedia.org/wiki/Google_Cloud_Messaging>)
> Client requests server inform the third party push server when there are changes.
> Third party push server passes details down to client, which can then request updates from the server without having to hold a connection open or poll.
> 
> This is a general pattern which 1st party clients frequently use (including ours at Fastmail) but which doesn't have a general solution, so my impression of the work required there is defining a standard for how to request the server make that push to a third party, and what gets included in that push.
> 
> This other work of having the server hold a connection open is also interesting and potentially useful, it's just not exactly what I was suggesting!

Hi Bron, thank you for articulating this distinction, it gave me a bunch to chew on!

However, after some thought, I don't think we are actually that far off. Consider that JMAP supports both of these methods: you can subscribe to a stream of updates via a long-running GET request (section 7.3 <https://tools.ietf.org/html/rfc8620#section-7.3>) or via a third-party server (section 7.2 <https://tools.ietf.org/html/rfc8620#section-7.2>). Braid should eventually support both as well.

The choice between whether you want to use a long-running TCP connection vs. a third-party server mostly comes down to whether you're a cell phone— it saves radio power if you don't have to maintain a TCP connection to each data source you care about. But if you're a server, or you're a cell phone that is already online, it's better to connect directly.

Now, we could certainly go about defining separate web push standards for these two cases. But I think there's a good case to be made for putting them together in a single standard, with a single API for programmers to use.

I think we can gain a lot by putting this standard into basic HTTP, rather than building layers on top. By adding Synchronization to HTTP, we get the functionality of Web Push, but it can be implemented automatically, for all resources, without any extra effort from the programmer. The whole web has changed in the last 20 years— from static pages to dynamic data —and it's time we upgrade the protocol at a deep level. Getting a notification of a message on your phone shouldn't be any different from getting the actual message in the app.