Better support for form updates is a very common request (here for example) and I think it'd be great to have an ecosystem-wide answer to how they are communicated to enumerators and how the update process on Collect can be made easier than it currently is.
###How forms get updated
Before getting to the communications aspect which is what your post is mostly about, I'd like to also discuss the update mechanism. I know Ona allows more significant updates to forms than Aggregate does. Aggregate currently requires a different formID for any change that affects database schema (adding fields, renaming fields, etc).
For Ona users who use ODK Collect to fill out forms, how do you currently tell them to update when there's a major change to a form with the same ID? Do you tell them to delete the form and then redownload it? Do you give them any guidance around partially filled out instances that may still be on the device? In Collect, those partially filled instances would no longer be openable if the form definition changes. @martijnr I believe Enketo has a strategy for handling the situation where there are drafts and the form definition changes. Is this something that it would make sense for the ODK ecosystem to align on?
@Jason_Rogena, am I correct in saying that these things need to be figured out regardless of the way that Collect learns about form updates? In other words, even if you end up building an external app, you'll need to tell Collect to update the form and so Collect has to know what that means?
By the way, I tried to verify how all this currently works in my Ona demo account. I was able to replace my form in Settings > Edit Form Settings > Replace form without any errors. However, the new form doesn't show up in either Enketo or Collect.
###Push notifications
As I've been thinking about this, it seems like the push notifications story is much simpler in the context of a hosted service such as Ona than it is in the context of ad-hoc server installs like what happens with Aggregate. It makes sense for Ona, Kobo, etc to run message brokers but I don't really know how that would work for organizations that self-host. With self-hosting, polling may be more appropriate rather than pushing. Additionally/alternately, although I appreciate your point about vendor lock-in, relying on a hosted solution like Firebase Cloud Messaging might be more realistic in a self-host context. I'd like to be wrong on this so if anyone has a good sense of how Aggregate instances could be set up for pushing notifications and form updates using a protocol like MQTT, please share.
An additional question which I think is relevant to your implementation as well is when registration and de-registration for messages happens. For example, let's say I download form1 with Ona credentials sally/password. Presumably Collect would then register for any updates to that form. Let's say I then change the Collect Ona credentials to bob/password1. Do I get registered for notifications for bob's form1 and stop receiving notifications for sally's form1?
Is anyone else in the ecosystem interested in push notifications? Would it make sense for Enketo to receive them, @martijnr? Is it something Kobo @dorey or ELMO @Tom_Smyth would want to add?
I hope some of these questions help in your design. I don't yet know what the best approach is to adding the feature to Collect and I think the answers to the questions will help guide that.