How To - Share Internet Content
From The Socknet
Users may share web content with friends either by sending it's GUID or, if it has no GUID, by creating a GUID consisting of the content's URL.
The user may copy-paste this URL into their Socknet provider and the provider may then lookup necessary information in order to perform a notify_message call. If the user wishes to include a comment, it should be sent in the form of a reply to the same friends who will receive the message itself.
If possible, it is better to provide the user with a friendlier way to begin the process than copy-paste. The webpage should prompt the user to enter his OpenID and attempt to send the URL (or a more Socknet-friendly GUID) to the user's Socknet provider via notify_message. (Unless it is registered with the user already, the service will be expected to redirect the user to a verification page.)
Contents |
Simple Sharing
A service can greatly simplify the task of sending a user to share its content by using the share breakout-function.
This breakout-function accepts a single parameter via the URL query string.
Using this feature is dramatically simpler than the standard sharing mechanism.
- The service asks the user for his OpenID
- The service accesses the OpenID and finds the user's provider URL
- The service redirects the user to <provider url>/breakout/share?url=<URL to share> (probably in a separate window)
- The user finds himself at his Socknet provider and either approves or rejects the sharing attempt
The bold item is the only change; it replaces several steps in the standard mechanism.
The service should be sure to URL encode the value of the url parameter.
GUID Discovery
If a GUID is a URL, it should be checked to see if it leads to HTML. If it does it should be checked for <link> tags with specific values for the rel attribute:
- socknet.guid.url
- socknet.guid.serviceid and socknet.guid.id
- socknet.guid.openid and socknet.guid.id
The href attributes of these tags are used to build the preferred Socknet GUID. This GUID should be used to access the message.
For the socknet.guid.serviceid and the socknet.guid.openid fields, the socknet.guid.id link tag must be present in the same parent object. Otherwise it is invalid.
A page may have more than one set of GUID's. For example, a user's profile page may have a GUID for each message it displays (though this is not required). If the provider is not interacting with a user, it may use the first item given or it may generate its own view. For this reason, it is highly recommended that URL GUID's be checked before sending them to others.
If a user posts a link as a message, then the provider may run the check above and show the result to the user. If the result is what the user expected the provider should send the GUID given by the page, as opposed to creating a new message with the link as the body.
Considerations
If a provider receives a reply to a message that it has not previously received, it should lookup the original message. For this reason, if a user wants to share a web URL and also send a reply, the reply notification is sufficient. The web URL will be sent in the reply_to field and should be picked up by the receivers of the reply.
Beware of loops during GUID discovery.
