CF notifications would provide a single mechanism for delivering messages to end-users, rather than forcing each component to figure out that problem separately. I'm proposing an optional platform component that provides other components with the functionality to deliver a message to a user, space, and eventually org/systemwide (optional because notifications are inherently optional to begin with). The complexity comes from notifying groups like spaces & organizations, and we wouldn't want platform components and services to duplicate that logic.
The initial implementation would just be a synchronous HTTP to SMTP bridge, but it would open the door to add notifications to many places in the CF ecosystem. Currently only the login component sends emails to users, but we'd like to add them to the mysql service, and it seems like most GUIs and services would eventually make use of this component (OSS or commercial). This component could be replaced with API-compatible endpoints that provide more advanced functionality like notifications preference pages, SMS, digest, unsubscribe, and push notifications.
I'm very interested in your feedback on whether this is a good idea to add to the platform, and what the API endpoints should look like. Thanks!
-David Stevenson
Director of Engineering, CF Services (and PM of the notifications service hopefully)