RE: R: Social API: Scope

> -----Original Message-----
> From: Harry Halpin [mailto:hhalpin@w3.org]
> Sent: 31 July 2014 17:24
> To: public-socialweb@w3.org
> Subject: Re: R: Social API: Scope
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> On 07/31/2014 06:20 PM, Goix Laurent Walter wrote:
> > Hi owen, all,
> >
> > [snip]
> >
> > My second point/question: If we are to develop both a federation
> > protocol and a client API, there is liable to be considerable overlap
> > in functionality and surface area, and significant interactions.
> > Should we not consider both together, as a single holistic whole?
> >
> 
> Note that there will be some interactions. However, one can imagine a
> standardized social JS client API sharing social data from a single origin
> embedded via an iframe without any open standards for federation.

[Owen] Of course. We can consider three layers: Server-to-Server,
Client-to-Server, and a JavaScript rich content API (which might be
implemented by the "container" in terms of the Client-to-Server API.

I think that the former two are one specification (in which the
Client-to-Server portion and Server-to-Server portions might be overlapping
subsets), and the latter a separate specification. It certainly shouldn't be
*required* for every implementation of the spec to implement the rich
content API. 

> > Examples of my reasoning for the above:
> >
> > *         I click on a user's avatar in my client. This should
> > bring up a page showing information about the user, and their recent
> > activities (as per my permissions to their activities, e.g.
> > I should see anything addressed directly at me on that page). A
> > consequence of this is that I need authenticated access as myself to
> > that user's server. In order to support this use case, my client needs
> > to be able to authenticate against the remote server with its' own
> > credentials
> >
> > *         My friend posts a video to just his friends. My client
> > should be able to download that video straight from his server,
> > without needing for it to be proxied through my server as an
> > intermediate (a waste of bandwidth for my server, and a function which
> > greatly complicates my server's code)
> >
> > *         I play an online game. This creates activities in my
> > stream for things I do (i.e. acts as a client). It also posts
> > activities to me to notify me of events (i.e. acts as a server).
> > The game should be able to do both without needing to speak two
> > different protocols
> >
> > [walter] I would indeed try to think at a unified Social API capable
> > of addressing both intra-domain (client-server) and inter-domain
> > (server-server federation), and distinct them as a matter of authn/z &
> > security. once we had opensocial (client api) vs ostatus (federation),
> > both using AS for example, but one using json and the other atom/xml.
> > In the meantime pubsubhubbub has evolved to remove dependency from
> > atom, and salmon concepts may be applied to json... Now opensocial (or
> > pump.io) API could actually be used for server-server communication as
> > well. I also remember the dialback authn mechanism proposed by evanp:
> > such type of technique could be useful in a federated context in
> > alternative to
> > oauth2 for intra-domain whilst the basic api remains the same.
> >
> > I would also add an additional question on the scope of the WG
> > regarding social data: we're now talking quite a lot about AS2.0 as
> > candidate to represent social activities.
> >
> > -          Is the representation of social profile and
> > relationships also in scope? We use to have PortableContacts
> > referenced by ostatus and opensocial for this. But of course other
> > alternatives exists (foaf etc). This is imo fully part of "social
> > data" in general, but I'd like to know the opinion of the group
> >
> 
> We imagine those will be application-defined. Vocabularies (ala
> FOAF/PortableContacts/vCard/etc.) then happen in Social IG.

[Owen] To certain degrees these matters are implicit in the client to server
and server to server protocols, however (the act of following somebody is
clearly an action which should be performed through the C2S protocol, whilst
it is core to the operation of the S2S protocol)

We should quite clearly define some baseline portions (as part of either AS2
or the API), whilst part of the remit of the IG might be to define best
practices for "richer" profiles?

> 
> > -          Furthermore, what about social identity? E.g. define
> > common recommendation (or something more impelling) about identifiers
> > to be used in a federated context. I am thinking in particular of
> > specific URI schemes such as the acct: URI or similar. To which extent
> > is this group willing to discuss and "agree" on URI schemes to be used
> > as identifiers?
> 
> URIs will definitely be supported. Emails can be turned into URIs, as can
> accounts via the accnt URI scheme. What else do you want in detail?
> 
> 
> >
> > walter Questo messaggio e i suoi allegati sono indirizzati
> > esclusivamente alle persone indicate. La diffusione, copia o qualsiasi
> > altra azione derivante dalla conoscenza di queste informazioni sono
> > rigorosamente vietate. Qualora abbiate ricevuto questo documento per
> > errore siete cortesemente pregati di darne immediata comunicazione al
> > mittente e di provvedere alla sua distruzione, Grazie.
> >
> > This e-mail and any attachments is confidential and may contain
> > privileged information intended for the addressee(s) only.
> > Dissemination, copying, printing or use by anybody else is
> > unauthorised. If you are not the intended recipient, please delete
> > this message and any attachments and advise the sender by return
> > e-mail, Thanks.
> >
> > [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se
> > non ? necessario.
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJT2m2xAAoJEPgwUoSfMzqcyOsQAKVJiSQCmKENNtkBKBh04vdv
> QHZFLkUB3JSTgiPtZkJc+r8+Gsn2U/upb6je88vFml7P20at2Hy+R0tZEYfn1W9n
> ydWzKOc1maWdp8Ay3pDjkfPrQtGINvB3y9mjUyE0cSuCdMMDIm8pFJN3WTZSJpOf
> Bxuxh2IvIC9r1cg3bfD7WzPp01ydD8Ey72q2GQapHLZFnup+0uDrOS0SbaF7/12r
> 9fFgtuRCBMmYyhF8U4VK1tq1jyKKcAE72Pbx6f2UQT1Q/6SSDiXlfux8aXDi2nar
> 4tzHloZZ0DXRKkxgboKDTSQGpk/Q4T5wTkvQ2aPqDANm99Pyv3M+FaDLEuR//2az
> gyZ8ZUZlH/19FZCNfvztYkDIkSo5SbfDaPwiPgPf4jQm+8oaKspfVX4KzqpnIMD0
> 1GaCaE0qbRnp5BnxUILU/k6SI8VxRHjh3ADXms+D0nDWG1NPpNYRTfTEzD4R6uAf
> TFWutYERDrp9RtX2apJ+63+0EnaS2cs06qMCSjR37vW6DXrDO2ZvSpsmVcvXXWQh
> nfZyVlzrlEoOvQX/yPOViaLQNGNi2al/+iG6+cGMsEh772qO53oH8B+LlDVh8rO4
> 8/lI58wyScvfjjc9x9/ch+yNpEfAl9VQqwFxzVDnfinDv47PXdgDwIN0TWVy2e4D
> k0+o0W9l4IVV4YDR2heq
> =dTUy
> -----END PGP SIGNATURE-----

Received on Thursday, 31 July 2014 17:24:21 UTC