RFC - Messaging over social networks

Angus Thomas athomas at redhat.com
Thu Jan 31 19:23:36 UTC 2013


This is a problem which I've been thinking about in the context of 
Winged Monkey, but it is more generally applicable.

We want Winged Monkey to be available on people’s phones, tablets etc so 
that they can see the state of running instances, receive notifications 
whenever there’s an outage etc..

So long as the users are standing fairly near the server which is 
running Winged Monkey, and can get wifi connectivity to the same network 
that the server is on, then it’s all relatively simple.

However, as soon as users step outside the building, it all gets a bit 
more complex. In order for the users’ phone to be able to connect over 
the internet to the Winged Monkey server, then either the phone is going 
to need to have a VPN connection, which is a significant overhead, or 
the Winged Monkey server instance is going to have to be directly 
accessible over the internet. A lot of the organisations which are 
potential users of Winged Monkey wouldn’t be prepared to do that.


We could use a social network as a messaging conduit between the Winged 
Monkey server and a client application on users’ phones.


For the rest of this mail, I’ll expand in this in the context of 
Twitter. I don’t *think* this use would be a violation the Twitter’s 
terms of service. ( https://twitter.com/tos ). There are several public 
social networks which could serve the purpose...

So, here’s how this could work:

* The Winged Monkey server would register a Twitter account, with 
protected tweets.

* A user would install and run the Winged Monkey phone app. The first 
run would also create a protected Twitter account, and when the user 
authenticates, the two Twitter accounts start following each other.

* Thereafter Winged Monkey and the phone app use tweets to communicate 
over the internet, sending instructions, status updates etc. as strings 
up up to 140 characters. So long as both the server and the client app 
poll frequently for new tweets, the responsiveness should be acceptable 
to users.


Some of the benefits are:

* The communications are authenticated, with access permission which can 
be very quickly revoked by unfollowing an account which is no longer 
supported.

* The communications are also (moderately) secure, in the sense that 
tweets from and between protected accounts aren’t generally readable.

* The timelines of the accounts constitute an audit history of events 
etc.. It would be trivial to scrape that audit history from Twitter if 
required.

* The principle benefit, though, is that the requirement for the Winged 
Monkey server to be directly accessible over the internet is removed. So 
long as the Winged Monkey server can make a client connection to 
Twitter.com, stuff just works.


I’m not pretending that this is a flawless proposition, but I think 
there’s enough of an idea here to want feedback. I’d love to hear a 
better way to solve the problem.



Angus


More information about the aeolus-devel mailing list