Social Web Working Group Teleconference

02 Dec 2014

Attendees

Present: tiborKatelbach, jasnell, Arnaud, evanpro, cwebber2, +1.408.455.aaaa, wilkie, rhiaro, jessica_lily, bblfish, Ann, Doug_Schepers, Sandro, aaronpk, AdamB, +1.703.670.aabb, +1.703.670.aacc, +1.408.455.aadd, dromasca, hhalpin
Regrets Chair: SV_MEETING_CHAIR
Scribe: rhiaro

Summary of Action Items

[NEW] ACTION: Link to OpenSocial extensions to Activity Streams 1.0 [recorded in http://www.w3.org/2014/12/02-social-minutes.html#action01]

[NEW] ACTION: Note about advertising in twitter and facebook apis [1]

Resolutions

RESOLVED: Approve minutes of 25 November 2014

Discussion

<trackbot> Date: 02 December 2014

Approve previous meeting minutes

<evanpro> https://www.w3.org/wiki/Socialwg/2014-11-25-minutes

evanpro: Review minutes from last week
... Objections or corrections?
... Minutes approved

<evanpro> RESOLVED: approved minutes of 25 November

Actions and issues tracker

<evanpro> http://www.w3.org/Social/track/issues/open

evanpro: Checking open issues for any that need to be addressed
... No names on issues, checking actions
... A few for harry, mostly about pubsubhubbub and licensing
... one for me, to update review of Foursquare API. Plan to do for next week.

<jasnell> http://www.w3.org/Social/track/issues/3 is covered by the extended vocabulary proposal ... if we adopt that then this issue will be closed

evanpro: A couple for jasnell
... actions 8 and 9, one about social APIs due today

jasnell: Will have to be pushed back
... Part in the wiki already, but lots of work
... Another week or two

evanpro: Not just opensocial? Link to spec?

jasnell: Connections has its own atom based API, more complex than open social
... In the wiki, linked to developer docs, but needs summarising

evanpro: Presentation about this next week?

jasnell: Tentative
... Could give very high level, would take lots of time for detail

evanpro: jasnell to review next week
... That's it for open actions, still some work to do.

<jasnell> http://www.w3.org/Social/track/actions/9 is covered by the extended vocabulary proposal

evanpro: Any other comment on actions and issues in tracker?

Face-to-face meeting

evanpro: Doodle has been open for a while
... Were close to consensus, but messed it up
... Can't do beginning of Feb, no chairs
... Looking like 10-19 March
... But not everyone has filled out the doodle yet
... sandro, mark, owen, a few others
... Don't know if we should pick a time without tantek on the call

<sandro> sorry, those times are all fine with me

evanpro: Deferring to Arnaud. Should we pick a time today?
... with the risk of losing tantek? Or defer until next week?

Arnaud: We can wait a bit more
... We need a good chance of having as many people as possible
... Could people take the time to update the poll?
... But no reason to rush a decision right now

<wilkie> http://doodle.com/3cfvrfqr6n9cgdzs btw

Arnaud: We need to decide 8 weeks ahead of time
... Shouldn't lose track, need to keep the pressure on

evanpro: Slipping past the 8 week for the end of Feb anyway
... Mid March looks best, we can decide by january

<jasnell> that week would be best for me for sure

<jasnell> (March 17-19)

evanpro: postpone the decision for another week. People, please update the doodle! Or risk being unable to come to the event.

<AdamB> was location discussed yet?

Social API review: OpenSocial Activity Streams API

<AdamB> thanks!

evanpro: We're looking at different APIs for social networks, and doing in-depth analyses with the intention of bringing out requirements
... We did twitter a couple of weeks ago, foursquare and facebook last week
... Today, OpenSocial AS API is one of the inputs for the working group, and because it's very different from the others, will go over it today

<evanpro> https://www.w3.org/wiki/Socialwg/Social_API/OpenSocial_Activity_Streams_API

evanpro: Spend 5 minutes going through it now
... The AS API for OpenSocial is one of the services that's part of the OpenSocial suite of APIs
... Core activities, use other APIs
... Provides a CRUD interface for AS events
... Supports XML representation that's a direct mapping of JSON from AS 1.0 to XML elements
... Not sure about level of support, but interesting
... OpenSocial uses OAuth 1.0; there are other mechanisms for auth too
... complicated, but decoupled auth from API endpoints
... Entities within OS API map directly to AS 1.0
... An activity which is an event, has subject-verb-object
... Activities can reference objects, which are nouns. ie people, images, places, groups

<shepazu> (CRUD: Create Read Update Delete)

evanpro: Or extended, self-defined objects
... API has four endpoints, not all required, two required (create and read)
... Interesting in that they're similar to how atompub manages creation of atom entries
... Create endpoint, that you post a new activity to
... Read endpoint, can be the same as post endpoint, or different
... Can return a stream or a single activity
... Complicated because you can change which activities are returned based on url parameters
... can get back a user's activities or a group's activities, or activities for a particular application (eg a game)
... Can also filter down to an activity ID
... Update endpoint, using PUT
... should update an activity. optional.
... Also Delete
... Introspection endpoint, which returns fields for AS container
... Overall, very different from the other ones we've talked about
... Not a lot of access to other parts of social network like friends or followers list, or getting profile information about a user
... Really about activity lifecycle
... Direct and simple
... Doesn't give a lot of information for reading

<cwebber2> ?q

evanpro: No concept of inbox, to get activities by people you follow or groups
... Really about CRUD lifecycle

cwebber2: Curious about whether supports addressing; privacy aspect of who something is addressed to; public or directed

<jasnell> there is some addressing support included but it's not based on the to/cc/bcc stuff

evanpro: Has extension to AS 1.0 for addressing
... A way within the activity object to say it's to a particular audience

<evanpro> ACTION: Link to OpenSocial extensions to Activity Streams 1.0 [recorded in [[2]|http://www.w3.org/2014/12/02-social-minutes.html#action01]]]

<trackbot> Error finding 'Link'. You can review and register nicknames at <http://www.w3.org/Social/track/users>.

evanpro: Will link to Open Social extensions to AS 1.0

<evanpro> ACTION eprodrom Link to OpenSocial extensions to Activity Streams 1.0

<trackbot> Created ACTION-17 - Link to opensocial extensions to activity streams 1.0 [on Evan Prodromou - due 2014-12-09].

evanpro: Any more questions?

<cwebber2> yup, thumbs up from here

<jasnell> http://opensocial.github.io/spec/2.5.1/Social-Data.xml#ActivityStreamOpenSocialExtensions

bblfish: A lot of APIs, seems like the URLs are hardcoded? Does AS always have to be /activitystreams?
... When we use linked data, we have relations in the documents that point us to different endpoints, and it doesn't really matter what they're called. So we could have Tor URLs for example, that are opaque

<jasnell> http://opensocial.github.io/spec/2.5.1/Core-API-Server.xml#REST-Request

bblfish: How does one find out where an activitystream is, where the user id is?

evanpro: There is a discovery process for OpenSocial

<jasnell> http://opensocial.github.io/spec/2.5.1/Core-API-Server.xml#REST-Request-URI

evanpro: but not 100% sure how it takes place
... but I do think that OpenSocial clients expect these particular url formats

<cwebber2> hei tantek

<tantek> belated regrets for this telcon - out at a meeting today

<tantek> catches up on logs: http://socialwg.indiewebcamp.com/irc/social/2014-12-02

evanpro: So you can say my activitystreams server is this and I support the AS API, but you can't say where your get endpoint, post endpoint etc, are. Doesn't go fine-grained.
... Don't believe there's a follow your nose through the activity itself

<jasnell> http://opensocial.github.io/spec/2.5.1/Core-API-Server.xml#Discovery

bblfish: Are the put, post and get all on the same url or different?

evanpro: Kind of. Read endpoint can have different structures, and accept POST and GET. Not entirely sure.

<jasnell> http://opensocial.github.io/spec/2.5.1/Social-API-Server.xml#ActivityStreams-Service

shepazu: Is it the intent of this group... some limitations, read and discovery isn't great on OpenSocial. Is this group going to extend OpenSocial to improve?

evanpro: Right now we're trying to get an idea of what a social API should look like
... going through the patterns of different proprietary APIs
... OpenSocial is special because it's the only standardised one we've got
... If we choose to standardise, there would probably be some changes
... I would be comfortable with making things as easy as possible for ourselves, and adopting something this simple with potential extensions, but may be some questions around that and fine-tuning
... Don't know if we'd do something that's 100% OpenSocial 2.5 compatible

<tantek> is there any actual active development, implementation, deployment of anything OpenSocial on the open web today? my impression is that it was dying/dead

AnnBassetti: Question about APIs in general. In previous descriptions of twitter and facebook, where does the advertising or the promoted tweet/post come into play?

<tantek> great question AnnBassetti

<sandro> brilliant question Ann :-)

AnnBassetti: I could see in the enterprise scenario where we would use such an element to advertise, to make a corporate announcement

<tantek> AnnBassetti++

<Loqi> AnnBassetti has 4 karma

evanpro: Twitter inserts promoted tweets into the inbox endpoint, they're not different from the people you follow tweets

<aaronpk> they are marked as "promoted" but other than that appear as normal tweets

evanpro: in the twitter ToS, clients aren't allowed to differentiate
... i think that facebook's AS API is similar, but not sure
... Those are the two that have advertisements in streams
... Don't know about FourSquare. Don't think ads are in stream
... Ads separate process, separate endpoint

AnnBassetti: Is that an aspect we should include in our descriptions?

<evanpro> ACTION eprodrom note about advertising in Twitter and Facebook APIs

<trackbot> Created ACTION-18 - Note about advertising in twitter and facebook apis [on Evan Prodromou - due 2014-12-09].

evanpro: Interesting part of it. Going to add an action to note about advertising in twitter and facebook APIs
... Great question!

shepazu: If we're going to talk about that, we should talk about the general case, not advertising specifically but service notifications, any other kind of update that is sent out that is not part of a normal stream
... not generated by people that the user follows. Should be some general case.

AnnBassetti: Something you get that you're not asking for

shepazu: Could be something from emergency services that's required by law

<AnnBassetti> and didn't come from your 'friends'

shepazu: Could be priority or out-of-band mechanism
... A 'class' of notifications

<tantek> I'd push back on "general case" - please document on the #SocialIG wiki page the specific use-cases that are driving "the general case, not advertising specifically but service notifications, any other kind of update that is sent out that is not part of a normal stream"

evanpro: Maybe jasnell could address this: there were some extensions from AS 1.0 to specify priorities
... Did the priority process get into 2.0?

jasnell: Yes
... it's generic, range of 0-1, abstracted
... No clear semantics on top of it
... 1 being highest, 0 being lowest
... Basic form.

<shepazu> (not sure that "priority" is the right mechanism, just threw that out there)

evanpro: Now cwebber2 can overview flickr API

<cwebber2> https://www.w3.org/wiki/Socialwg/Social_API/Flickr_API

cwebber2: Brief overview of Flickr, not finished yet

<cwebber2> https://www.flickr.com/services/api/

cwebber2: General idea with this API is pretty well documented, and in many ways pretty simple

<tantek> just rechecked the Doodle for next f2f - my info is up to date

cwebber2: Uses OAuth 1.0 for auth
... Used to have their own, but deprecated their own. Limited permissions system in place.
... A lot of the APIs we've been reviewing have a lot of different endpoints for every single type of activity
... Which is related to django and rails way of doing urls

<cwebber2> https://www.flickr.com/services/api/

cwebber2: But flickr just has a few
... You can see there are request formats and response formats

<cwebber2> https://api.flickr.com/services/rest/?method=flickr.test.echo&name=value

cwebber2: On the request formats page, a few endpoints, eg. rest

<cwebber2> https://www.flickr.com/services/api/request.xmlrpc.html

cwebber2: Also XML RPC endpoint where you can do the same type of thing but different serialisation
... Lots of different methods for these different endpoints

<bblfish> it's understandable, but lightly choppy

<bblfish> yes

<bblfish> better

<evanpro> Yes

<wilkie> sounds good

<evanpro> Little choppy but OK

cwebber2: Each endpoint requires different params, depending on serialisation format
... Can request different ways of getting information back. So if you wanted to submit via xmlrpc API but get json back, you can
... Although there are different endpoints for manipulating data and getting information back, the payload for these are pretty small

<cwebber2> https://www.flickr.com/services/api/upload.api.html

cwebber2: Except photo uploading. Entirely different endpoint for that
... And if you post to it and it has different params. Well documented.
... Params include what the safety level is (eg family-friendly), title, description, tags
... Does have restrictions around recipients: public or friends/family only
... But that's as fine grained as it gets
... Also has params to say whether it's hidden or global
... If yo uwant to do anything on top of that you use the method API endpoint (?)
... No serialisation formats options for photo POST API
... interesting, because I'm curious about how we're going to handle media submission alongside activity
... Can get Evan's comments? When Jessica was implementing pumpio API support for MediaGoblin, different APIs for uploading a photo, how to give other parameters

evanpro: That is a pattern. OpenSocial defers media upload to separate part of OpenSocial API. We'd need to take a look at that.

<cwebber2> sorry about it cutting in and out

evanpro: It seems to be a pattern that we see in different API, where media upload is a separate process

<cwebber2> I wish I had a better connection :\

evanpro: Not sure if this is optimal

<cwebber2> rhiaro: yes great job!

evanpro: Questions about flickr API
... Size of the API? Did a quick count - something like 200+ services

cwebber2: Didn't count
... Didn't get to that

evanpro: It is a huge API
... Another question: Don't see anything about adding/removing members of social network

cwebber2: Didn't get to that yet

evanpro: Flickr may be one of the oldest social APIs out there. Flickr is a decade old.
... Any questions for Chris about the Flickr API?

bblfish: Didn't understand whether there were a lot of endpoints, or a lot of messages to one endpoint? Seem to be a lot of different ways of accessing the data. How RESTful is this?
... Can you use the DELETE verb on the URL so it works with caching?

<evanpro> https://www.flickr.com/services/api/request.rest.html

bblfish: One could ask this for every API.
... To facilitate linking between resources and caching of them.

<cwebber2> https://api.flickr.com/services/rest/

cwebber2: In terms of RESTfulness of it, and number of endpoints, just a couple of different endpoints

<bblfish> so this is more SOAPY

cwebber2: Literally a single endpoint called /rest/
... simple HTTP GET and POST
... more SOAPy, but with a different variety of layers
... Multiple RPC serialisations, which all look very similar, but just adapt to a particular method

<tantek> Now that's pretty funny. A single endpoint called /rest/ - that's ironically not even remotely close to a "RESTful" API.

cwebber2: If you want to use REST or XMLRPC or SOAP, mostly the same but with different serialisation formats. Three separate URLs.

<bblfish> ah ok. Just 3 different end points, with many different messages to it.

cwebber2: Just specify method=flickr.blogs.getlist (eg)

<bblfish> thanks

<cwebber2> yup

evanpro: Any other questions for Chris?

<tantek> Do any existing *real-world* (i.e. at least one company supporting it) social web APIs do ANYTHING with any HTTP verbs other than GET, POST?

<tantek> I.e. I would claim that NONE of them (i.e. nobody) use(s) DELETE.

<bblfish> Here for AnnBassetti, Roy's thesis http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm :-)

<cwebber2> I could possibly organize it, I'm not sure how you would want it organized

evanpro: Thanks Chris! A thing that might be useful to cluster methods to inform the rest of our process

<evanpro> https://www.w3.org/wiki/Socialwg/Social_API <-- roadmap

evanpro: Set aside last few mintues to discuss where we are with our process on social APIs

<cwebber2> I could try to follow the flickr/twitter api patterns

evanpro: See roadmap link

<tantek> And thus would pushback on RESTians that keep bringing up using PUT, DELETE, etc. because in practice, they are dead ends.

<bblfish> :-)

evanpro: 1) identify APIs, 2) identify functionalities, 3) assemble requirements

<evanpro> https://www.w3.org/wiki/Socialwg/API_requirements

evanpro: We have a beginning of that (see link)
... Would like to know from the group if it makes sense to continue with more reviews?
... More idea about micropub? Indieweb API

<bblfish> I'd like to talk about LDP based API

evanpro: Would like to talk about pump.io API, similar to OpenSocial AS
... Main question is, do we continue with these reviews for another week or so?
... Or start to collect requirements?

<jasnell> personally, I'd like to see a minimal baseline proposal soon. even if just a strawman to get started

shepazu: Useful to hear about different features etc of each. I would like to hear about more. But moving on to other things might be useful. But main thing I think would be useful is to have a matrix; a list of features and APIs
... And break it down that way
... Qualified checkmark sort of thing with an explanation
... So we know what we're comparing in terms of features, and what gaps might be

<wilkie> even if we had a basic API started, we could still review other APIs and use it to critique our design

shepazu: Useful when addressing use cases and requirements, because you can say which APIs support required features
... If that's useful, who is willing to compile such a feature list?
... And the people who presented the review on an API can fill it in on the matrix

<bblfish> I like the Matrix

shepazu: Just a suggestion, but seems useful

evanpro: Makes a lot of sense
... Main downside is tables on mediawiki is an exercise in patience...

<harry> Tables are terrible on media wiki - you could just email Doug and he could make the table :)

shepazu: Willing to do the table wrangling, then all pepole need to do is fill in checkmarks

evanpro: Great, happy to do that

Sandro: Can just do html
... Another thing useful is a side-by-side comparison, ie what does SWAT0 look like in each of these APIs (or some other simple test case)

evanpro: SWAT0 is specifically done for federation efforts, but there are things that could be captured

sandro: SWAT0 is kind of overkill, but the individual pieces

evanpro: Main thing to avoid becoming the API documentation reading book club
... Can't read documentation forever, we need to use it
... Like Doug's idea of matrix
... Could aaronpk or tantek do a presentation about micropub next week?

<aaronpk> sure, happy to talk about micropub next week

evanpro: And any others?

<tantek> I defer to aaronpk

evanpro: Then we should move out of API documentation

bblfish: Three weeks time I could have something that could show how one could use LDP API to do some of these things
... It might be interesting to let pepole see in comparison what doing the same thing in LDP would be

evanpro: bblfish, would you be willing to review how LDP works next week?

bblfish: Yes but not next week
... Week after is fine

sandro: Is that a matter of looking at candidates?

evanpro: yeah, on the border
... it is an existing structure. Can defer until later

<AnnBassetti> is LDP = Linked Data Platform or ??

evanpro: if we were talking abot using LDP as a candidate, there would be some clarification

bblfish: There are things missing in LDP
... eg notifications

<jasnell> need to drop

<jasnell> bye all

bblfish: but basic API.. you can already do a post of a picture, add a friend, delete a ... can do a lot of these things already

<evanpro> jasnell: thanks

evanpro: Put it on the agenda for 2 weeks
... We should wrap up
... Another look at doodle poll

There's another event the week after that cwebber2 and Jessica are going to, right?

scribe: Planning for all 3 chairs to make it

<tantek> All APIs we have reviewed so far have active real world deployments, multiple clients, multiple users.

<tantek> That should be a minimum bar for our review

scribe: So we're looking at 10-12 or 17-19
... We'll defer decision to next week
... Thanks everyone!

<cwebber2> later

<AnnBassetti> great job Evan

<Arnaud> thanks, bye

<aaronpk> tantek: agreed

<wilkie> thanks!

<wilkie> rhiaro++

<tiborKatelbach> thanks

<Loqi> rhiaro has 3 karma

<cwebber2> sorry my connection sucks

<tantek> re: review how LDP works - who is using it to publish social web content on their own site today? anybody?

<evanpro> trackbot, end meeting

<bblfish> sandro: we could try to work together on LDP for in a couple of weeks

Socialwg/2014-12-02-minutes