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.

> 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.

> -          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 16:24:25 UTC