OStatus/Implementation plan

Outgoing notice delivery diagram

Subscription lifetime timeline

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/<profile_id>.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/<group_id>.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 <link> 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 <link> 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.