XMPP
Secondary devices may use XMPP to communicate with one another, and with a receiver.
The communications may consist solely of device-to-device communications (not intended for direct user consumption), or may consist of user-oriented messages (i.e., chat sessions), or some combination of both.
- Receiver implements an XMPP server, advertises on local network. Uses NAT-PMP to open external port.
- Users discover via Bonjour, inform receiver XMPP server (by some means?) of other XMPP accounts – e.g., GTalk, Facebook, Livejournal
- XMPP server on receiver sends auth request to external accounts, using its own external address:port as server info, device UUID as account name, vCard includes ‘friendly name’ of device (e.g., “Joe’s TV”)
- When not at home, user can use normal XMPP client to talk to the receiver, schedule recordings, etc. Custom apps can provide for pretty front-ends to this (presenting different UI when on same LAN vs when remote)
Where receivers implement an XMPP server, they should advertise themselves on the local network using Bonjour, with a service name of xmpp-server. e.g.:
receiver.local. IN A 169.254.238.34
Test\ Set-top\ Box._xmpp-server._tcp.local. IN SRV 0 0 5222
_xmpp_server._tcp.local. IN PTR Test\ Set-top\ Box._xmpp-server._tcp.local.
The server advertising the above should permit authentication from clients with a JID in the form <uuid>@Test\20Set-top\20Box using a Pairing protocol passcode as a password. The server should automatically populate the roster with other users who have connected to the XMPP server at least once using the same mechanism.
Clients connecting to this server should update the server-held vCard automatically based upon locally-held information where possible.
Devices may communicate with one another directly through the use of serverless messaging as described in XEP-0174