OMB over PuSH

Brainstorming... there's some interest in using PubSubHubub as infrastructure for next major version of OMB rather than continuing to implement the low-level bits on our own.

OMB needs/reqs

• sub setup/auth
  • subscriber and subscribee are both clearly identified
• push new notices in real time
  • fixed payload params
• push updated profiles in real time
  • fixed payload params

Features for OMB 0.2

Organization:

• make use of other standards as much as possible to minimize the detailed protocol description and maintenance that we would have to do otherwise

New features:

• Info in notices
  • reply-to (for clear conversations)
  • forward-of (for new-retweet style)
  • subscriber profile updates
  • group subscription
  • private direct notices
  • unsolicited replies from people who aren't subscribed
  • share plaintext, formatted HTML, and attachments
• Subscription management
  • push unsubscription/block events to remote
    • -> PuSH + ActivityStreams ? [PuSH can declare an unsub; if we want other metainof in that we'd need to push an event, then unsub]
  • redelivery on failure
    • -> PuSH
  • garbage collection of dead links
    • -> PuSH

The cheap road

If we just expand current 0.1 protocol...

• change from plaintext payload to Atom elements
• add threading info
• allow posts w/o oath subscriber key for unsolicited replies
• could do group subs as rough equivalent of user subs
• could do subscriber updates by adding another callback

Using existing techs

• #OAuth
  • (already using in 0.1 for subscription auth)
• #PuSH
  • would replace part of OMB 0.1's sub setup and the profile/notice pushes
• #Activity Streams
  • atom payload for the PuSH stream w/ notice and profile info
• #WebFinger
  • discovery
• #Salmon
  • sending replies upstream?

PuSH

• Push new events in an Atom feed, using #Activity Streams
  • notice updates
    • include profile info with each notice on a group feed
  • profile updates
    • for individual user, a global <author> on the feed should be ok. [confirm that this repls correctly]
• native unsubscribe notifications
  • if subscriber breaks the relationship, sub sends PuSH unsub to hub
  • if subscribee breaks the relationship, we can send an unsubscribe event through the stream, then drop the subscription on the pub/hub end
• existing infrastructure for hubs to redeliver, expire dead subs

Outgoing feed streams:

• public notices, profile changes (1:M)
• direct messages, unsubscribe/block notifications (1:1)
  • Discovery complications?

Subscriber identification?

• Add a parameter on the PuSH sub request?
  • omb.subscriber=acct:evan@identi.ca [-> WebFinger]

OAuth

OMB uses OAuth to set up authorization. How can we integrate this with PuSH? Using tokens in the URLs?

• PuSH+OAth myspace

Salmon

http://www.salmon-protocol.org/

For sending replies and profile updates of subscribers back upstream...

• include a <link rel="salmon"> on a user/group's Atom feed with the reply endpoint
• based on AtomPub
  • so should be able to format the replies pretty much the same as we format outgoing pub notices
• thr:in-reply-to field for replies

Spam issues?

• subscriber replies can be validated with OAuth tokens
• non-subscriber replies can be checked against WebFinger to at least confirm the origin server

Activity Streams

Atom data format details for social-ish events...

• http://activitystrea.ms/

Also extend profile info w/ poco ?

• http://portablecontacts.net/

Event verbs:

• post
• follow?
• unfollow
• favorite/unfavorite [?]
• delete [?]

WebFinger

http://code.google.com/p/webfinger/

Use acct: URLs for id & discovery?

• acct:evan@identi.ca
  • -> via webfinger lookup -> to profile URL, feed URL, etc

WebFinger requires domain-level control, either DNS or webroot-level files or URL rewriting. This may not be compatible with shared sites or sites running multiple apps; certainly it drops the "just works" that we want. :(

Arch overview

Terms:

• publisher site: software instance sending updates
• publisher user: account on upstream site
• subscriber site: software instance receiving updates
• subscriber user: account on downstream site

• For publisher user, the publisher site provides a PuSH-enabled Atom feed:
  • <author> extended with profile info
  • contains user's public notice stream
    • ActivityStreams/PoCo info extending Atom base
  • new notices or changed author profile trigger a PuSH ping out to subscriber sites
  • block info sent as an activitystrea.ms entry
• PuSH subscription maintained for each (publisher user)<->(subscriber site) relationship
  • Setup/teardown of the PuSH subscription is responsibility of subscriber site
• Replies sent upstream via Salmon
  • publisher site updates subscriber profile data on each Salmon message
  • @-notices
  • repeat/retweet
  • follow/unfollow
  • fave/unfave can be sent
  • empty notice for plain profile update

Subscription walkthrough

• A@identi.ca wants to subscribe to B@jaiku.com
  • first time anyone's made a sub between these servers
• identi.ca goes through PuSH setup to get the public update feed for B@jaiku.com
• identi.ca sends B@jaiku.com a Salmon notice with activitystrea.ms <entry> saying "A@identi.ca subscribes to B@jaiku.com"

later...

• C@identi.ca wants to subscribe to B@jaiku.com
• already have a sub to B@jaiku.com on identi.ca, so don't need to do another PuSH update
• identi.ca sends B@jaiku.com a Salmon notice with activitystrea.ms <entry> saying "C@identi.ca subscribes to B@jaiku.com"

later still...

• A@identi.ca unsubscribes
• identi.ca sends B@jaiku.com a Salmon notice with activitystrea.ms <entry> saying "A@identi.ca unsubscribes from B@jaiku.com"
  • identi.ca decrements the B@jaiku.com subscriber count -- now 1

• C@identi.ca unsubscribes
• identi.ca sends B@jaiku.com a Salmon notice with activitystrea.ms <entry> saying "C@identi.ca unsubscribes from B@jaiku.com"
  • identi.ca decrements the B@jaiku.com subscriber count -- now 0
• identi.ca notices its count of subs to B@jaiku.com is now 0 and sends PuSH unsub request for B@jaiku.com's public update feed

Future

Direct messages:

• could be done with a second PuSH update feed that's 1:1 subscriber:subscribee
  • make sure there's no leakage... have to trust the foreign server to do the right thing, of course

Private updates w/ subscription approval:

• would have to at least limit the outgoing update feed to approved subscribing _sites_
  • then trust the subscribing site to only dole out the updates to approved subscribing _users_
    • [if you don't trust the site but trust one user on it you're doomed already if they're evil, so no huge benefit to making a per-subscribing-user feed]
      • (unless the client uses public key encryption -- in that case you're not doomed -- but in that case there's still no benefit to making a per-subscribing-user feed -- BayleShanks)