The most important protocol element of a social network, beyond connection establishment, is messaging. Messages can be sent between profiles with a single sender and multiple recipients, just like with email. A great advantage to using social networks for messaging is that it eliminates spam. There is no way to send a message unless the sender's profile is authenticated against the recipient profile.
When communicating between profiles both within and between providers, a message must adhere to one or more formats. There are several existing standards, with some under active development. One notable example is XHTML-IM, which is part of the XMPP protocol. XMPP itself is based on Jabber.
Open Connections will not be bound to a single format. However, it must be noted, that in order to facilitate interoperability, a minimum standard must exist. The approach taken will be to specify a minimum, which will be a bare plain text message format, and to then allow each provider to advertise an accepted list of message formats. This is similar to how the HTTP Accept header allows user agents (e.g., browsers) to handle different MIME types.
The reason for specifying a minimum plain text format is to simplify the task of implementing a profile provider for the first version of Open Connections.
The first three message formats are, provisionally:
Status will be used to support the broadcast or asymmetrical model vs. the symmetrical model of messaging. It is asymmetrical because a profile may subscribe to another profile's status stream without having a reciprocal subscription, as is required for a friend invite and accept. A subscriber authorizes a profile to send status messages to their profile, using the standard OAuth 2.0 mechanism.
Scalability is the biggest challenge in an asymmetrical model such as this. For example, if a profile has 100,000 subscribers, and these subscribers are on disparate providers, any status messages sent out must be sent to a potentially large number of providers. In this example, if a message had to be sent out one connection at a time, and the sending system could make 10 HTTP connections per second, it would take nearly three hours to send a single status update. For these reasons, the status protocol has provisions for dealing with scalability challenges.
The status format will be based on ActivityStreams.