This is a rough outline of the required methods needed to meet the working specification of FPS (Federated Packet Service or Federated Micro Publishing).

Core API Methods

Publisher Token Exchange

The purpose of the publisher_token methods are to enabled autonomous Consumer-Provider (under OAuth) key exchange so that all future federated requests may be validated using OAuth.

Notice: Publisher/Consumer token exchange has been voided and replaced with domains. The Consumer key pair in OAuth transactions should be the domain which is sending requests.

POST /api/fmp/share_token

Parameters:

  publisher   - user@domain (a user on the destination service)

  subscriber  - user@domain (a user on the calling service)

  request_token - Under OAuth, a public key

  request_token_secret - Under OAuth, a secret key

Used in subscribing for the publishing service to request an access token from the Subscriber. The access tokens provided (oauth_token and oauth_token_secret) should be stored on both the subscriber and publisher for federated authentication. This method goes hand-in-hand with the subscribing node's subscribe method (unspecified).

GET /api/fmp/access_token

Parameters:

  request_token - The request token, as shared by a Subscriber

  request_token_secret - The request token secret, as shared by the Subscriber

  [other Parameters according to OAuth, Consumer key exchange should already have taken place]

Publishing Methods

POST /api/fmp/publish

Parameters:

  id - The ID of the packet on the publishing node (for permalinking, editing, removing).

packet

- Valid XML fps packet <fps>...</fps>

  [other Parameters according to OAuth, Consumer key exchange should already have taken place]

Publish allows a publisher to distribute packets to their subscribers, after OAuthentication. Namespaces may be used in order for themes/plugins/handlers to render the packet-data in customized ways (these are not part of the specification). Multiple namespaces should be comma-delimited. The packet may have any valid XML contents, but some services may restrict packet size (unspecified, recommended 5Kb).

Upon success, the subscribed node should return a message containing the number of subscribers reached.

POST /api/fmp/republish

[see publish from above]

The purpose of the republish method is for allowing publisher to edit their data. Rather than writing a new packet to the service, all identification is maintained, but the packet content (whether inside a database or flat file storage) should be updated with the new packet. The ID should be the local ID of the packet.

POST /api/fmp/unpublish

Parameters:

  id - The ID of the packet on the publishing node.

  [other Parameters according to OAuth, Consumer key exchange should already have taken place]

Unpublishing allows publishers to remove their messages from subscriber nodes, for whatever reason.

Notify Method

POST /api/fmp/notify

Parameters: [see publish]

The notify method follows the exact form as publish except without a packet id. Notify packets are unidentified and stored neither on the source or destination nodes. The purpose of this method is to transmit data which may be stored in an application, but should not be considered a published item, such as a user profile or location.

Questions/Comments

Why are subscribe and unsubscribe methods not specified?

 - These methods are bound to local nodes and do not play a part in the federation core. They act to instantiate some of the above specified methods (namely share_token), but only locally authorized users should be allowed subscribe (across the federation).

Why is a dispatch method not specified?

 - The dispatch is a key component to publishing as it may be serial or parallelized for efficiency. This is also in the hands of the local node and only serves as a gateway for local packets to be distributed to subscriber nodes via the publish method.