OStatus/Implementation plan





Implementation Plan

 * Protocol
 * Determine namespaces for endpoints
 * Subscription server URL :rel - http://ostatus.org/schema/1.0/subscribe
 * Publisher server Feed URL : rel - http://ostatus.org/schema/1.0/publish


 * Webfinger discovery [walkah]
 * XRD parsing / generation
 * Discovery from publisher site (determine subscriber's site & subscription endpoint)
 * Discovery from subscriber site (determine publisher's feed endpoint)
 * Add additional "subscribe" buttons


 * OStatus/PuSH consumer implementation [brion]
 * Offer a "top-level" endpoint for subscribing
 * Ensure that Atom parsing is extensible enough for incoming ActivityStreams information
 * Parse incoming PortableContacts information for creating profiles
 * Integrate subscription end for consumer


 * OStatus/PuSH producer/hub implementation [brion]
 * Create integrated hub for producer
 * [so we only have to build and push feeds that are subscribed]
 * retry/redelivery improvements
 * automatic subscription refresh
 * ^ probably ok to drop the built-in hub & use an external -- double check on deletion notification requirement?
 * ^ slave replication delay could be a problem actually; external hub might not pick up a new post. Replication delay is cited as a reason why one might implement an integrated hub at http://code.google.com/p/pubsubhubbub/wiki/PublisherEfficiency
 * ^ external hub is available an option


 * ActivityStreams [zach?]
 * Ensure that Feeds contain additional ActivityStreams verbs for
 * partial Add profile information (name & avatar in, still need home/bio/location/tags/etc)
 * abstract atom element generation/parsing for re-use by PuSH and Salmon


 * Salmon [walkah]
 * (partly) Implement salmon endpoint
 * Signature generation code
 * See MagicSig spec (http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html)
 * (partly) Salmon posting (particularly on notice parsing - see below)
 * Parse notices for 'mentions' (webfinger / email addresses)


 * Interface [csarven]
 * Landing page for subscription (based on current OMB ?)


 * missing stuff

Key URL interfaces
Publisher+hub side:
 * /api/statuses/user_timeline/.atom
 * Public Atom feed of a given user's posted notices.
 * Discovery: should be in the XRD discovery info?
 * This URL must remain stable -- recommend using user ID numbers rather than nicknames so a user can change nicks without breaking subscriptions.
 * /api/statusnet/groups/timeline/.atom
 * Public Atom feed of a given group's posted notices
 * Discovery: should be in the XRD discovery info?
 * This URL must remain stable -- recommend using user ID numbers rather than nicknames so a group can change nicks without breaking subscriptions.
 * /main/push/hub
 * PuSH hub endpoint for remote sites to establish a subscription to the notice feed
 * Discovery: provided via in the feed
 * Can be used by both general feed subscribers and OStatus subscribers, but only the public notice feeds are handled. Requests to subscribe to other feeds will be rejected.
 * PuSH is a site-to-site protocol; the subscribing site need only establish the subscription once, and can deliver received notices to multiple local subscribers. Each individual OStatus subscriber should also send subscription/unsubscription notifications and profile updates via the Salmon reply channel
 * /main/salmon (?)
 * Salmon endpoint for receiving individual sub/unsub notifications, favorite notifications, replies, etc.
 * Discovery: provided via in the feed (double-check this?)

Consumer side:
 * /main/push/callback
 * PuSH subscriber callback endpoint. Hub sends feed subscription verifications and new updates to this endpoint.
 * Discovery: provided by consumer when establishing PuSH subscription.

Subscription management
Internals at the consumer end:

Remote subscription via UI action
 * my user FOO is subscribing to external user BAR


 * check if we have a PuSH sub to BAR's feed
 * if not, establish PuSH sub to BAR's feed
 * fixme: confirm async verification of the PuSH sub state?
 * is there a local profile for BAR?
 * if not, save it
 * if so, update it if necessary
 * save a local subscription record for FOO -> BAR
 * send Salmon subscribe notification to BAR's server
 * fixme: any verification step? (the remote server gives us an HTTP return at least; could probably handle 4xx for rejects and 5xx for internal server error?)

Remote unsubscription via UI action
 * my user FOO is unsubscribing from external user BAR


 * remove local subscription record for FOO -> BAR
 * send Salmon unsubscribe notification to BAR's server
 * PuSH garbage collection:
 * check if any other subscriptions to BAR
 * if not, cancel the PuSH subscription to BAR's feed

Internals at the producer end:

Salmon subscribe notification
 * external user FOO is subscribing to my user BAR!


 * verify the subscription signature against profile
 * is there a local profile for FOO?
 * if not, save it
 * if so, update it if necessary
 * save a local subscription record for FOO -> BAR

Salmon unsubscribe notification
 * external user FOO is unsubscribing from my user BAR!


 * verify the subscription signature against profile
 * remove local subscription record for FOO -> BAR
 * profile garbage collection:
 * check if FOO is subscriber or subscribee to anything else locally
 * if not, remove the profile fixme: could be a problem with group subs

Group subscriptions
considerations:
 * we have a separate group membership table -- safe to use or should we treat them as semi-users?
 * groups have a sort-of profile, but we also need to save profiles for each foreign user who posts through the group

Currently experimenting with saving a local 'shadow' group in the main user_group table, but with '@remote' on it -- needs work.