Social Software For Robots

Post on 28-Jan-2015

108 views 0 download

Tags:

description

Paris XTech 2007 on real time data APIs in social software.

Transcript of Social Software For Robots

Social Software for Robots

Social Software for Robots

Kellan Elliott-McCrea

Flickr I work for Flickr

Blaine CookI'm Blaine,

Twitter I work for Twitter

Social Software

Social Software is

People talking to people?

Sometimes.

Usually its people talking to computers talking to people.

Social Software is

•social software is made of people

People talking to people?

Sometimes.

Usually its people talking to computers talking to people.

Social Software is

•social software is made of people

•people talking to people?

People talking to people?

Sometimes.

Usually its people talking to computers talking to people.

Social Software is

•social software is made of people

•people talking to people?

•people talking to computers, talking to people.

People talking to people?

Sometimes.

Usually its people talking to computers talking to people.

I tell Twitter what I'm doing, and it tells you about it along withthe rest of your friends.I uploaded a photo, and you get a list of all the photos from all your friends.I'm attending an event, and Upcoming shows you popular events amongyour contacts.I even something as personal as leaving a message for you on MySpace,but really I'm sending a message to the computer to notify you thatyou've been messaged (by me, and whomever else fell into the window)

Software to collect and share

individuals’ actionsin a

social context.

this is an old viz.maybe tom can do an updated one?

# Characteristics- Did I just define social software as somehow unique because computersare acting on our behalf? No I didn't.- The key characteristic is individual's actions being aggregated andre-distributed in a social context.

# Exponential Explosion- Big numbers, lots of activity, busy busy busy

Client

Server

are we there yet?

are we there yet?

are we there yet?

distracted

distracted

distracted

no.

no.

no.

bored bored bored

# Feeds and APIs.

Feeds are worse is better polling architectures, with one-waysemantics over a comparatively low level protocol, withoutidentification, notification, or an event loop. (and REST is prettymuch the same)

Client

Web

are we there yet?

distracted

no.

bored

are we there yet?

distracted

no.

bored

are we there yet?

distractedno

.

bored

are we there yet?

distracted

no.

bored

?

no. ?

no. ?

no. ?

no.

DB

# Why is it important?

"aggregating attention streams high enough volume that current modelsare breaking down"

We'll come back to that.

are we there yet?

# Is there a better metaphor?

Yeah there is. its message passing

# visualizing request/response

# visualizing send/recieve

Client

Server

let me know

when w

e’re therew

e’re

the

re

arrival

# Let's be clear

Message passing means many things. We're talking specifically about:

* asynchronous, but real-time communication* non-blocking event loop driven processing* share nothing architectures

# Web meet the event loop!

# The Switch

Response/ResponseSend/Recieve

Social SoftwareFor Robots

Robots do it with Message Passing

• aggregation

• re-distribution

• building services and apis?

• # Social software for robots

Or rather bots for social software. Bots to handle the socialaggregation and re-distribution.

How do we build services and APIs for social software?

Where it Works.

•real time data

•wire-level data (no db interaction)

•shift from access-past to notify-future

•very long running queries

Good for: real time data, good for data where being able to push it onwire without going to the database is a huge win.

moving away from "What have you seen in the past" to "let me know whensomething happens in the future"

Where it Doesn’t.

•historical and static content

•interactive searches

# What is it good for:

Isn't for everything.

Isn't for: querying historical data

New Patterns(how else can you use it?)

Realtime Craigslist

time

# Some New Patterns

1. New data, right now

who is that useful for Craigslist

time

# Some New Patterns

1. New data, right now

who is that useful for Craigslist

Flickr TMI Addiction2. Tooooo much data for a feed

today's uploads on Flickr

Spontaneity

3. Real time API makes collaboration possible

You're tell upcoming you're going to Manu Chao! You're friend saysdon't buy that ticket, I've got an extra.

Fishing

•Put a net out, and get notified when you catch something.

•When real-time data is more important that knowing in advance or researching the future.

•Who’s going for lunch NOW?

4. Fishing in the real time stream

everybody's updating on Twitter, but whose going to lunch? Cause I'm hungry.

<message from=”driver@local” to=”car@local”>forward 40

right 65</message>

(btw. if you were building real robots this is how you'd do it! you're toy cars aren't going to pool every few seconds for new instructions)

Jabber

# So how do you do it?

You use Jabber (and you use Ruby!)

#### Jabber! (or XMPP for purists)

# Jabber, the History of

Jabber is actually XMPP. IETF standard for instant messaging.

* Open* XML-based* near real-time* extensible

Invented by Jeremie Miller in 1998. XMPP working group formed in 2002,approved as IETF standard in 2004.

(p.s. Google launched GoogleTalk on top of Jabber August, 2005)

What’s in it for me?•asynchronous, low latency (realtime)

•flexible & extensible

•security & identity baked in

•delegated

•presence

•standardized

# Sure, But What's in it for me (as an api developer)?

- asynchronous, but real time. - extensible - security and identity at the protocol level - delegated delivery - standardized - presence enabled

It’s Just XML

<message to="horatio@denmark" from="hamlet@denmark"> <body>Angels and Ministers of Grace, defend us!</body> <foo xmlns="http://www.foo.org/"> <bar>ab<fb/>cd</bar> </foo></message>

even dicaprio can do it! whilst playing hamlet!(straight from the spec!)

It Scaleslossa messages

trust usno really

erm. how? you ask...next slide!

Asynchronous<message from="xena@gmail.com" to="sparql@w3c.org">meow!</message>

<message from="sparql@w3c.org" to= "xena@gmail.com">meow!</message>

Sending is fire and forget. Get sends up early in your flow and younever need to scan your database looking for updates. (anyone whodoesn't shudder on the word "scan" isn't thinking big enough)

Meanwhile receiver can focus on other things and be automaticallynotified of new data.

Client and server have different priorities and constraints, and canadapt appropriately - decoupled.

gmail.com

w3c.org

# Delegated Delivery

<pic goes here>

Messages are deliverable to externally unroutable destinations.

Delegated Delivery

I CAN HASCALLBACKS

# I can has callbacks!

Async + unspoofable(-ish) + delegated delivery means callbacks to the client!

Upload a process intensive file - a really big photo (RAW?) oraudio/video. Rather then polling constantly for uploadStatus, get anotification back when its done! (remember a second is like 7 years incomputer times)

Open Sourcerrific•ejabberd

•djabberd

•wildfire

•lmnop-jabberd

•twisted suite

•ruby

•php

•java

•perl

•python

•firefox

APP over Jabber

Security

•dialback server authentication (dns)

•s2s encrypted

•c2s encrypted

•from address set by server (no spoofing!)

•globally unique jids (like email)

Standardised

# Standardized

core hasn't changed in 6 years, and its well thought out large installs small installs IETF standard

Presence!

# Presence ... is neat

When your offline, we don't have to send. Reduces cost of fan out.(Or don't bother tracking presence! Its a trade off) UDP style. Ok to miss a few. (buffering is also an option)

Decentralized

•Smarts on the Edge-1 is what you want for ubicomp / device saturated world.

# Decentralized ... But Server-based

Smarts on the Edge-1 is what you want for ubicomp/device saturated world.

(because the quad-core G5 in your pocket is going to burn)

that was a lot.•async, real-time.

•extensible

•secure w/identity

•delegated

•i can has callbacks!

•standardized

•presence

•decentralized, but not p2p*

# Wouzers! That was a lot

But it really is easy. Lets just review that.

- asynchronous, but real time. - extensible - security and identity at the protocol level - delegated - I can has postbacks! - standardized - presence enabled - Decentralized ... But Server-based

What can •what the heck you

gonna do with it?

# Neat, so now what? What can we build.

Federated social software? - Twitter is going to first federated social software network(Blaine doesn't know this yet!)

Auto-negoiation based on presence

Real time streams at scale

Message passing clients to server aggregation. - private feed crawler running locally feeding into Google Reader - WeSabe Uploadr is an example of client to server aggreation.(but it doesn't use Jabber)

flickr api•hypothetical (sorry!)

# Flickr over Jabber - HYPOTHETICAL

Ok. But what about APIs? Here are some examples of using Jabber tosolve some Flickr API challenges.

#1. All my contact's photos!

Flickr has a federated architecture. Means its hard to show photosfrom people on different shards. We cheat to show photos fromcontacts. But it wouldn't be hard to generate a XMPP stream ofphotos to contacts.

#1. At photo upload, send to photo to: (don't do it like this) kellanfriends@xmpp.flickr.com kellanfamilys@xmpp.flickr.com kellanff@xmpp.flickr.com kellanpublic@xmpp.flickr.com -> myfriend@talk.google.com

Wins:

These lists are updated when relationships change, must less commonthen photo uploading. Doing it right now saves the cost of tracking the photo down in thedatabase later. We aren't limited by our denormalizations Relationship look up is done once at write/send time vs. for everyfeed reader request or page view.

#2 Stored tag search

Get notified when a new photo tagged 'kittens' gets uploaded.

We have feeds per tag. But so many wasted resources all around. (allthat polling!) And we don't have them for tag combos. And if you'rethe only person who is subscribed to the Flickr tag feed on 'bigfoot'its going to take Bloglines to notify you of new spottings!

We keep a big hashtable of tag to JID mappings. No need to store inthe database, memory is fast, and disks are cheap.

flickr is at scale•for the small stuff, it’s

easy.

#3 Smart clients: Responsive clients, thin device clients,annotating clients

# And thats at scale!

If you're small, its *much* *much* easier. All you need is a Rubydaemon, and you can use Google's Jabber servers and they'll scale itfor you!

Robots

require 'xmpp4r-simple'

CLIENT = Jabber::Simple.new("flickrit@gmail.com", "xtech2007")

def post_photo_update(message) CLIENT.deliver("flickrviz@laughingmeme.org", message)end

def request_flickr_photos(message) CLIENT.deliver("flickrapi@gmail.com", "#{message.from} wants to see photos of #{message.body}")end

loop do CLIENT.received_messages do |message| case message.from.strip.to_s when 'flickrapi@gmail.com': post_photo_update(message.body) else request_flickr_photos(message) end endend

require 'xmpp4r-simple'

CLIENT = Jabber::Simple.new("flickrit@gmail.com", "xtech2007")

def post_photo_update(message) CLIENT.deliver("flickrviz@laughingmeme.org", message)end

def request_flickr_photos(message) CLIENT.deliver("flickrapi@gmail.com", "#{message.from} wants to see photos of #{message.body}")end

loop do CLIENT.received_messages do |message| case message.from.strip.to_s when 'flickrapi@gmail.com': post_photo_update(message.body) else request_flickr_photos(message) end endend

require 'xmpp4r-simple'

CLIENT = Jabber::Simple.new("flickrit@gmail.com", "xtech2007")

def post_photo_update(message) CLIENT.deliver("flickrviz@laughingmeme.org", message)end

def request_flickr_photos(message) CLIENT.deliver("flickrapi@gmail.com", "#{message.from} wants to see photos of #{message.body}")end

loop do CLIENT.received_messages do |message| case message.from.strip.to_s when 'flickrapi@gmail.com': post_photo_update(message.body) else request_flickr_photos(message) end endend

require 'xmpp4r-simple'

CLIENT = Jabber::Simple.new("flickrit@gmail.com", "xtech2007")

def post_photo_update(message) CLIENT.deliver("flickrviz@laughingmeme.org", message)end

def request_flickr_photos(message) CLIENT.deliver("flickrapi@gmail.com", "#{message.from} wants to see photos of #{message.body}")end

loop do CLIENT.received_messages do |message| case message.from.strip.to_s when 'flickrapi@gmail.com': post_photo_update(message.body) else request_flickr_photos(message) end endend

code + implementation of a few robots, using jabber, that do something cool with flickr and flash.

demo

twitter

thanks!

http://www.flickr.com/photos/jayjizzle/205165885/http://www.flickr.com/photos/heather/384134566/http://flickr.com/photos/kevinsteele/473590084/

http://www.flickr.com/photos/exfordy/123370328/