See also: IRC log
<trackbot> Date: 02 December 2014
<cwebber2> oh I'm P0, one sec
<cwebber2> ??P0 is me
<cwebber2> hm, how do I do that again :)
<cwebber2> Zakim: ??P0 is me
<jessica_lily> oh
<jessica_lily> hm :P
<cwebber2> heh, thanks :)
<cwebber2> whaat
<KevinMarks> I'm on the call but muted as I'm driving
I can scribe if my connection stays good
<evanpro> scribenick rhiaro
Can't promise, it's been sketchy lately
<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
<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?
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?
<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 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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/formats/url formats/ Succeeded: s/thta/that/ No ScribeNick specified. Guessing ScribeNick: rhiaro Inferring Scribes: rhiaro Default 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 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 WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Dec 2014 Guessing minutes URL: http://www.w3.org/2014/12/02-social-minutes.html People with action items: link[End of scribe.perl diagnostic output]