SOCML Standard

Overview

Below I will provide a generalized description of how the standard will work and be implemented. This standard is still a work in progress and things are subject to change. The concepts enumerated should provide a general framework for how the SOCML standard can be implemented; furthermore, detailed specifications of the standard are described in the SOCML Technical sub-pages.

How it Works

Much like an RSS feed, the SOCML standard is a format in which data can be shared and aggregated across multiple applications. SOCML makes use of XML as a primary means of organizing information and can incorporate dynamic data. These data files are encrypted and cannot be viewed by anyone except for the intended recipient.

Data is transmitted through the various social networks by simulcasting all user updates to each connected peer in the user's social network. Each member in the user's network has both a public and private encryption key. Data that is sent from the user to members of their social network is encrypted with each members public key. On receipt of other members updates, all transmissions are decrypted using the user's private key.

Since the data standard is "protocol-less" it can be transmitted in any number of ways; however, it is envisioned that transmissions will occur through exposed web services since they are easy to implement, do not require additional software to be installed, and can communicate easily through firewalls.

Users can verify the identity of peers wishing to join their social network (friends list) with the use of digital signatures. This process is similar to the encryption process described above; however, it is done so in reverse. In this case, the peer requesting to join user's social network will encrypt their request using their private key. The user would authenticate this request by using the peer's public key to decrypt the request.

Users can also locate and add peers by searching public directories for their locator ID, or by entering their name at the service they are registered at. In addition, users can limit the information shared with peers by creating groups or establishing individual permissions.

Finally, users can allow for dynamic content to be added to their social network feed that can either be maintained as private or simulcasted to selected peers or groups. This opens the ability for non-socially integrated services, like online merchants, games, and financial services to provide real-time information to the user such as when bills are due, payments are received, items that have shipped with tracking information, or when it simply is their turn to "make a move" in an online game.

Privacy Standard

Encryption / Authentication

The most important part of any social network is maintaining the integrity and privacy of the user. The use of asymmetric cryptography allows for us to transmit data reliably without worry that the contents will be intercepted by a third party. Furthermore, we are able to establish identities and trusted parties through the use of digital signatures.

The SOCML standard will initially support a RSA/AES encryption schema similar to how PGP works. In this case, asymmetric keys will be created by the social media service for the user. These keys will then be used to encrypt a randomly generated password that will decrypt the transmitted content that has been encrypted using the AES specification. The user will also have the ability to specify their own public and private keys.

Regulated Content

User privacy can further be maintained by allowing for content to be regulated by the user. What this means is that for every post, share, picture upload, or information provided by the user only selected parties will be eligible to see this detail. To accomplish this, each item posted by the user will have roles assigned to it that only people in eligible groups can see. The actual implementation of this will be largely managed by the social network service; however, the rules and groups will be standardized and accompany the user with all their social network data.

Groups

The user will have the ability to establish groups. Groups will consist of peers selected by the user who they wish to provide certain access rights to their social media data. Individual roles can also be established to provide for more customized privacy control.

The goal is to have the user aggregate each social network connection into a group. For example, if a user wishes to delineate certain access rights to only friends, the user can establish a group for these people and grant the proper access rights. This comes in handy if the user wants to maintain a professional and a personal profile.

Transmission Standard

The SOCML data standard is intended to be protocol independent, as such any implementation of the SOCML standard can use any method for transmitting SOCML data; however, it is highly recommended that user data be simulcasted through web services. Essentially, whenever a user posts content or makes changes the service provider will iterate through the users network of peers with the proper permissions and transmit this data to only those users. Each peer in the users network will have their social networks service address in their stored contact information. The users service provider will then broadcast the users content to each of these providers following the standards for encryption.

Unreachable services will be queued for later transmission. If the service is unable to reach a peer in a users social network, a message will logged for the user to review and an action to take can be requested.

Users can also request historical content that a peer has posted by sending a request to the peers service provider.

Transmissions can also be compressed if the peers service provider allows for it. This standard needs to be reviewed and should be considered.

Content Archival / Transmission Requests

Data that user has created should be stored in the SOCML format. It is up to the service provider to determine how much history they will allow the user to store, in addition all content that the user posts should be made available for easy removal.

Content that is received from peer nodes can also be stored and similarly It is up to the service provider to determine how much history the provider will allow the user to store. At any point that the user wishes to download or transfer their social media data, the data can be made available in a singular SOCML data feed, or in a series of files.

Again, the purpose of the SOCML standard is to facilitate in data transmission and the portability of information. The user should also have the ability to download their data in an unencrypted format, should they lack the sophistication needed to decrypt their data.

In the event that no match is found, the user can default to public services that allow people to list themselves in the search results. Again, the SOCML standard is intended to normalize social network data, and describing possible search techniques would be outside of the scope of this standard.

Dynamic Content Providers

Dynamic content providers can be classified as non-social entities that are allowed access to post and receive personal data to a users social network feed. Essentially, this allows for third-party developers to interface with the users social network feeds and can be granted access privileges to limit the amount of information made accessible to these providers.

Dynamic content providers will transmit and receive SOCML data in the same fashion as peer-to-peer data is sent.

User Search Requests

One of the more perplexing, and perhaps difficult, questions around creating a federated social network involves establishing a discovery system for searching for people. The SOCML standard intends to help with this by providing a data structure that will facilitate in social networks querying of user bases. When a user searches for a contact, each peer in their network will be sent a request to return contact information of the person searched for if there is a match found.