Flow

Basic notification flow

Node registration

1. UA does a GET to the http://push.telefonica.es/token to get the token. Receives a plain response with the token in the body.
2. UA opens a WebSocket connection to the NS_UA_WS (ws://push.telefonica.es/) with the protocol push-notification.
3. Once opened, the UA must send the registration message, which is:

this.ws.connection.send('{"data": {"uatoken":"' + this.token + '"}, "command":"register/ua"}');

or

this.ws.connection.send('{"data": {"uatoken":"' + this.token + '", "interface": { "ip": "' + this.ip.value + '", "port": "' + this.port.value + '" } }, "command":"register/ua"}');

Depending if it's on a private network or in the public. (Should this be done by Gecko?)

4. The answer received could be just a plain OK if it's correct or a JSON with a "error" message explaining what went wrong like this:

{ "error": "Token received is not accepted. Please get a valid one" }

Webapp registration

1. Once the Node registration is made, the UA must ask for a URL for the webapp once the user got requested and accepted the petition.
2. The WebApp (WA) registration MUST be done by websockets, by sending to the previous open connection (or opening again if it's closed) this message:

'{"data": {"uatoken":"' + uatoken + '", "watoken": "' + watoken + '" }, "command":"register/wa"}'

3. A URL is received in plain text in the body with the URL to send notifications.

4. That URL should be shared with the service.

The user and the app has been registered.

1. Application server (AS) sends a notification to the Notification server URL that was previously provided, like https://push.telefonica.es/notify/abcdef1234567890, with a correct JSON body:

"message": "$2",
"signature": "$3",
"ttl": 0,
"timestamp": "SINCE_EPOCH_TIME",
"priority": 1 }"```

where:

* id: Your own internal identification. Can be used to track if the notification is delivered or not. If you send following notifications with the same id, the previous one is deleted and substituted by this one.
* message: plain text or JSON. This is delivered to the user. Limited to XXX bytes.
* signature: a SHA256 hash to sign JUST THE MESSAGE with your private key to verify the sender.
* ttl: time to live. After this time, your notification is discarded.
* timestamp: time when your notification leaves your server, in EPOCH. ttl is summed to this to discard the notification.
* priority: 1, 2, 3 (real time, less, less).

2. That notification reaches the NS-AS (Notification Server - Application Server), which:
	1. Connects to the MongoDB (DB) to store the message.
	2. Add the message ID to the queue `/queue/newMessages` which is monitored by the NS_MSG_Mon

3. The monitor is subscribe to that queue (`/queue/newMessages`) and listens for every new message
	1. Once a message is pushed on the `/queue/newMessages` queue, the monitor reads it and gets application that has that WAToken.
	2. Gets all nodes that has that application.
	3. For all the nodes, push the message to every queue (`/queue/WS1`, `/queue/UDP2`) of the server ID(s) that matches the URL where the notification has been pushed (need to search for those servers in the DB). This can be one or more, since the user could have more than one UA to receive notifications (p.e. desktop and mobile)

4. The queue (managed by ActiveMQ) has one specific NS-UA (Notification Server - User Agent) server which consumes the data from those queues:
4. That server fetches the data from the queue (which are message IDs)
5. The message is fetched from the DB corresponding to that unique messageID generated at first push.
6. Depending on the registered UA:
	1. If it's a WebSocket server (there is a permanent connection between the NS-UA and the UA):
		1. The message is sent through the WebSocket to the client, which ACKs it.
		2. When ACKed, the NS-UA must send a notification `(MSGid,UAToken)` to the NS MSG Manager to change the status of the given message (the message has an array of delivery notifications)
	2. If it's a UDP server:
		1. The UDP server sends a "ping" to the device open port (UDP 5000)
		2. The device connects to the pull server (which is the method `/pull` from the NS-UA-UDP) to reclaim its notifications