Add rest-api endpoint to push a notification

[johnhooks]

What problem does this address?

The current rest-api does not support creating a new notification message and broadcasting it to subscribed users.

What is your proposed solution?

I propose adding and a new endpoint:

POST /wp-json/wp/v2/notifications - Create a new notification

To create the message, the message data should be in the request body, something like:

{
 // It might be more convenient for devs to use the channel's name, because that will be known
 // variable in their code when register a channel, the id of the channel will not.
 //
 // Though that could create issues if a plugin attempts to register a channel by the same name
 // as another, and possibly broadcast messages to the wrong channel.
 //
 // What could prevent this problem?
 // We could use "channel_source" and "channel_name", rather than just the "channel_name".
 // This would allow a lookup scoped only to channels registered by a single source.
 "channel_id":  { "type": "number" } 

 // Managing date time stamps between client and server could be a pain.
 // Perhaps use "expires_in" from the client and transform it into the right timestamp on the server
 "expires_at": { "type": "number" },

 // Maybe an enum?
 "priority": { "type": "number" },

 "title_key": { "type": "string" },

 "message_key": {."type": "string" },

 // Stringified JSON
 "meta": { "type": "string" }
}

The post body will provided all the necessary information to create a new message in the database and broadcast it to it's subscribers.

Questions

Same as #176

Should a plugin receive a nonce when registering a channel, and that is required for pushing notifications to a channel? The proposal doesn't have a mechanism to ensure that only the source can broadcast a message on one of it's channels. Is this even a concern? I could see issues with a plugin emitting on a core channel to look like official content from core, is this ever a problem in the current system?

[erikyo]

In my idea some notifications could be shown without "permission" like the notices that a plugins could show in the WordPress dashbord. However let's say these are the temporary notifications like the Gutenberg editor toasts notifications (the notification component in short)

Indeed to store something in the plugin database the plugin (or whoever emits) it should be authorized but I hadn't really thought how to "certify" the provenance, because I had assumed that everything works only in backend and was covered the WordPress auth

[johnhooks]

@erikyo I'm just new to WordPress and the concept that a plugin isn't sandboxed or authenticated in anyway is something I'm still trying to wrap my head around. Now that I think about it, the issue of authenticating a plugin is moot, any registered plugin has total control of the database, and could just put a notification directly into the db on its own, by passing any restrictions we tried to make.

@Sephsekla this is the question I was trying to ask at the end of the last meeting. Because the user's authentication does help determine the client is authorized, but it isn't the user's permissions that actually allow emitting a message, it's the plugin that is calling the API. Example: a user's actions cause some notification to be emitted to the Admins, it's not the user's permissions that are being checked if that emitter should be able to broadcast. It's the channel and source, and how it's been registered on the server.

[erikyo]

@johnhooks - Yes, but I don't think it's wrong to try to authenticate the origin of the message (if it's possible), although as you say it's a bit of a dummy check since a plugin by controlling the database could access the notifications table directly.