Author: | Evan Prodromou (Control Yourself, Inc.) |
---|---|
Contact: | evan@controlezvous.ca |
Revision: | 0.1.1 |
Date: | 2008-07-07 |
Copyright: | To the extent possible under law, Control Yourself, Inc has waived all copyright, moral rights, database rights, and any other rights that might be asserted over The OpenMicroBlogging specification. |
To allow users of one microblogging service to publish notices to users of another service, given the other users' permission.
Depends on OAuth 1.0, OAuth Discovery 1.0, YADIS 1.0.
We piggy-back additional information onto these protocols to pass microblogging information back and forth.
[*] | May be the profile URL, if it's defined not to change or be re-used. The profile URL of some services includes the nickname, and some let the user change his/her nickname. This user's profile URL may change from 'http://example.net/~john' to 'http://example.net/~johnsmith' A tag URI, like 'tag:example.net,2008:user:1' may be more appropriate here. |
[†] | IWBNI the notice URI is used everywhere the notice is published; for example, in any RSS feeds. |
The user submits their profile URL [‡] to the remote service somehow -- for example, with an HTML form on the remote service's Web site.
[‡] | For OAuth Discovery, this is the "protected resource". It may be more correct that the protected resource is the postNotice URL (see below), but the listener will be more familiar with their own profile URL. So there will have to be discovery of the postNotice URL anyways, and it might as well all be done in one step. |
The remote service recovers a YADIS document from the profile URL, as described in OAuth Discovery.
The request token service must have a LocalID associated with it, containing the identifier URI for the listener.
The following two extra services must be included in the YADIS document, with accompanying URIs.
If any of the URIs is unavailable, the remote service MUST stop processing.
The remote service must go through the OAuth 1.0 dance to get authorization to post notices and update profiles.
In all OAuth, the consumer key should be the root URL for the microblogging service, if available. The secret should be the blank string (''), unless the remote server and local service have negotiated another key. Such negotiation is out-of-scope for this document, and we assume an "open" network of microblogging services. But if you want to have that kind of network, do it with this key.
The remote service MUST do OAuth for every new listener, regardless of whether they've already received authorization for posting to the given postNotice URL. See Posting a Notice below.
The remote service uses the defined requestToken URL to get a request token.
In the request token HTTP request, the remote service MUST send the following additional parameter(s):
In the results for the request token request, the local service MUST send the following additional parameters:
In requesting user authorization, the remote service must send the following parameters:
The remote service should send as many of the following parameters as possible. This will help the user decide if they really want to allow the listening to happen, and allow the local service to store a copy of the listenee's profile.
The local service, in a successful response, must return the following additional parameters:
It should return as many of the following as possible:
This will allow the remote service to display information about the listener in the listenee's "listeners" or "subscribers" list.
The access token step of the OAuth protocol requires no additional parameters.
To post a notice to the local service, the remote service sends an HTTP POST message to the postNotice URL discovered above. The message must use OAuth authorization. The message must also include the following parameters:
The message may include the following parameters:
The local service should include the following parameters in its response:
The local service makes no guarantees about the delivery of the notice to anyone.
The remote service SHOULD NOT send a message with the same notice URL to the same postNotice URL more than once. [§] If the request returns a 403 Unauthorized message, the remote service SHOULD NOT post messages to the same URL again with the same listenee, until another listener has gone through the OAuth dance. [¶]
[§] | A half-assed optimization. A local service may have a lot of listeners listening to the same listenee. It would be pointless to have the remote service post the same notice 100 times to the same service. However, if the local service wants fine-grained control, it can have a different postNotice URL for each listener. |
[¶] | If there's one postNotice URL per listener, the 403 message means the listener has told the local service not to allow posting any more ("unsubscribed"). If there's one postNotice URL per local service, it means that the count of listeners has dropped to 0. |
If the listenee's profile information changes, the remote service MAY send an HTTP POST message to to the updateProfile URL to tell the local service about the change.
The message must use OAuth authorization. The message must also include the following parameters:
The message may include any of the following parameters:
Missing parameters should not be construed to mean that the profile field has been blanked. The remote service MUST set the parameter to an empty string to show that the field is blank.