R: Social API: Scope

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?

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

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

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.