Linked TV: Buttons
Buttons is a project to help televisions, remote controls, their users and associated gadgets communicate more usefully. It's a mix of some old ongoing foaf-projects work from the FOAF project, and some findings from the NoTube EU project.
There isn't much to see here yet, but if you're technically minded, some of the following links might be interesting:
Status (as of 2009-11-08): I've some experimental prototyping work partially blogged, including an OSX adaptor that relays local Apple Remote events into XMPP, an iPhone app which does much the same, and some experiments with Strophe/BOSH and HTML5 as UI. Also some experiments with pushing those HTML pieces down into social networks via OpenSocial (which will involve fiddling around with flXHR and Punjab XMPP proxying to get around x-domain rules). And eventually wiring up wrappers for Boxee/XMBC/Plex, MythTV, iTunes, EyeTV etc etc. For now, here's a screenshot of a simple HTML5 video playing UI driven from Apple Remote and/or iPhone. --Danbri.org 20:57, 8 November 2009 (UTC)
Note that there is no real protocol yet, beyond code that looks for ad hoc strings in XMPP messages. This is by design. A protocol will come once we've a suitable environment with data, code, services that need to communicate. We might have some hackathons for this kind of stuff as part of the NoTube project.
- website: buttons.foaf.tv
- NoTube Buttons work: buttons.notube.tv (hmm this might point to Chris' Zapper demos for now)
- earlier FOAF project work on JQbus, for data query using Jabber.
- The NoTube EU project; Buttons builds on NoTube's research and use cases.
- For work-in-progress NoTube survey of iphone remotes, EPGs, video and radio apps, etc. see flickr.
- XMPP specs for TV / media centre remote control on XMPP Social list.
- related bookmarks: buttons, remotes, notube.
- The XBMC HTTP API shows some example facilities that might be exposed over Buttons
- ageing book chapter on P2P and the Power of Metadata
- some blurry ideas for visuals, showing buttoned home media kit (slideshow)
- initial danbri 'linked tv' essay
The plan, roughly, is to define some lightweight Social TV protocols based on XMPP, FOAF and various other standards, with the goal of reducing friction and fragmentation between different TV watching environments and of allowing Buttons-compatible remote controls to connect arbitrary media centres, smart phones, Web video sites and - eventually - set top boxes.
Initial prototyping is with the XBMC family of media-centre systems (Boxee, Plex, etc.), and using iPhone, Android and Web (Javascript / OpenSocial / BOSH) as clients. There is currently no spec, no requirements document, no mailing list and no project plan. But things are moving along...
Contact: Dan Brickley
Spec drafting
Notes towards a spec.
Pairing
Devices connect to each other via accounts; for larger shared devices (TVs, tables, ...) these are typically per-device, for personal devices like smart-phones, they can connect via per-user accounts. It is possible but not required for multiple devices to simultaneously be using the same account, e.g. a phone and a laptop could be logged into the network as jana.notube@gmail.com; or TVs in bedroom and living room could be sharing a single janas.tv@gmail.com account. To make sense of such potential complexity, service description and 'presence' mechanisms are quite important.
Devices may also use XMPP XEP-0174 for discovery and server-less communications. For example, a smart-phone (eg. iphone) on a home Wi-fi LAN could locate and communicate directly with a set-top mini PC running NoTube's custom MythTV system.
QR Codes can be used as an alternative discovery mechanism. A device can advertise an XMPP address for itself, eg. xmpp:bob.notube@gmail.com/mythtv12321
There are various trust and knowledge levels that can hold between devices. The simplest is to know the full XMPP network ID ('JID") for a device. This is sufficient to send it an 'info query' message, although that may be ignored. Typically a device playing a client/remote role will use this to request to be added to a roster. The XMPP service infrastructure maintains a roster list for each device, identifying JIDs of other devices that have been accepted onto the roster, as well as those that are asking to be accepted.
Once a device is on another's roster, it may send/receive Buttons messages using XMPP. Whether these are accepted or even acknowledged is entirely in the control of the targeted device. Each media-centre device will typically partition its roster into different trust levels, eg. read-only, or child-only profiles of its full capabilities.
Pairing by QR can be initiated in a media centre by sending it (from a device/account that is already sufficiently trusted) a 'PAIR' message (handwaving here). This requests the device to go into pairing mode, where it will advertise its XMPP address visually (by QR Code). More detail needed on this point to handle security, but end result should be the extension of some trust level to a new device which will introduce itself by sending a message to the advertised address.
