The possibilities of device to device signalling would benefit from Automagic able to act as an XMPP receiver. That is the protocol underneath the popular Jabber Instant Messaging. Why popular? Because many services use it, but don't name it accordingly. For example, Google chat isn't generally known as yet-another-XMPP-messaging-service.
XMMP is organised similar to email: A Jabber id looks like name@domain, and contrary to some proprietary IM protocols, users don't need to join the "same network" in order to exchange messages. But XMPP is designed for low latency message transfer, which email isn't.
XMPP is also used for exchanging messages between non-human users: machines signalling or controlling other machines. This way of use is what makes XMPP attractive for Automagic: As listener, it could react to messages sent to it. Through notifications or email can Automagic react to remote events already, in a way, though it's uncommon - not impossible - to create an email account for the sole purpose of the device listening to control messages. Through notifications, there is simply no standard way to talk to another device. XMPP clients (listener+sender) commonly provide an integrated way for account creation "on the fly", on a host of your choice, no additional software component (like, a webbrowser or a shell prompt) required.
Automagic needs:
A trigger, for XMMP message received. If the trigger is used for an active flow, and net is available, Automagic connects to the XMMP server. Account details (mostly name, host, password) will have to be specified in or for the trigger. Account creation would be nice, but optional. Message details (sender, body, time) are passed in variables or (body) written to file. Time is important, because messages are cached on server, when device is without connectivity, then offloaded to device once it connects again. Being able to listen to a jabber conference (a multi user chatroom, comparable to an IRC channel) gives multicast (one to many) messaging. This describes the listener part.
Sending should be easier, because it doesn't require a maintained connection for messages pushed to receiver. Again, account details are needed - this could be a different account than the listener account, or it could be the same. Recipient must be specified. A conference could be a recipient too. And, of course, the data sent. Text, in its most basic form. I haven't thought about items of other data types. Nor about how to deal with no-net conditions: should user implement spooling within flow logic, or should Automagic take care of this. I guess that the most predictable behavior is what is wanted, and in this case does "predictable" possibly mean "same as send email with Gmail action" about which I don't know whether it will spool.
XMPP receiver and sender
Moderator: Martin