BridgesArchitecture

Bridge Architecture

pump.io has to connect and interact with other social networks. Those can either provide activity streams or use their own format.

When relevant, we have to convert incoming foreign streams into activities before importing them into pump.io, as we have to convert outgoing pump.io activies into relevant format before pushing into foreign network.

Target networks

• StatusNet (activity stream)
• Facebook (use activity stream ?)
• Twitter (use internal format)
• Github (use activity stream ?)
• Foursquare (use internal format ?)
• OExchange? http://www.oexchange.org/guide/#developers
• ... to be continued ...

Bridge architecture

Global idea is to keep bridges outside of pump.io scope so that they can be developped as separate projects. Also, there should not be any need to release a new pump.io version just because a foreign service changed something on its API

Possible scenarios

Remote Delivery

Uses existing API

• Register a web app as new client
• Receive stuff from Twitter
• Convert it into activity
  • Actor is Twitter account
• Push in into user's inbox with oAuth & actor's check
• Outgoing activities are sent via "remote delivery" to web app
• Convert into tweets
• Sent to Twitter

Pro: simple

Cons:

• need to deal with pump.io oAuth for each Twitter account.
• Or we could have a single client ID for the bridge itself, and it uses a "share" verb to share the upstream tweet. --evanp
• no simple way to handle outgoing activities (do we really need a web app ?)
• We may need a way to do this kind of thing automatically, either with authenticated PubSubHubbub or with a bespoke webhook.

"Proxy" delivery

Uses existing "remote delivery" API without oAuth checks

• Register a new "proxy" client (allowed to post activities for a given domain name. Example: twitter.com)
• User authorize the application on pump.io
• Receive stuff from Twitter
• Convert it into activity
  • Actor is Twitter account
• Push in into user's inbox
• Outgoing activities are delivered remotely to proxy
• Convert into tweets
• Sent to Twitter

Pro: no need to deal with oAuth per Twitter account Cons:

• security concerns (spoofing ?)
• needs modifications on pump.io side to disable actor check if a specific domain is found.

Remote Delivery as a local pump.io user

• Register a new client

• Associate client credential to a local user like twitterbridge@domain.tld

• Receive stuff from Twitter

• Convert it into activity

  • Actor is twitterbridge@domain.tld
  • activities are shared by this user

• Push in into user's inbox

• Outgoing activities are pushed into twitterbridge@domain.tld inbox

• Poll inbox (firehose, PubSub, somethin else ?)

• Convert activities into Tweets

• send them to Twitter

Pro: handle outgoing activities

Cons:

• add a (useless ?) complexity level.
• lost (part of) integration: in reality, activities are not shared
• add confusion as twitterbridge@domain.tld is not a real user (how to handle replies, share, ... ?)
• use different ways for incoming & outgoing streams

"Direct" delivery

• Register application for specific domain (example: all activities from and to twitter.com must be given to me)
• Receive stuff from Twitter
• Convert it into activity
  • Actor is Twitter account
• Push into a queueing system
• Pump.io listen to that queue, poll incoming activities and deliver it into inboxes, bypassing actor checks.
• Outgoing pump.io activities are pushed into a queueing system could be the same queue server, but shouldn't be the same queue
• Poll activities from that queue, convert activities to Tweets
• Send them to Twitter

Pro:

• no need to deal with oAuth
• can restrict access to queuing system from localhost or specific IP address(es)
• can be used for other bridges (providing different queue/channel for maximum isolation: if a remote service goes down (Twitter, Facebook, ...), other are still working
• allow bridges to be separate projects.
• allow easy evolution. For example, Twitter bridge could use Userstream if single user or Sitestream if many users (using "bto" or "bcc" ?).

Cons:

• add (little ?) complexity to pump.io
• add daemons on pump.io side to check queueing system
• have to keep track of foreign profile mapping with local ones on daemon side