RE: Social API: Scope

From: Goix Laurent Walter [mailto:laurentwalter.goix@telecomitalia.it] 
Sent: 31 July 2014 17:20
To: Owen Shepherd; public-socialweb@w3.org
Subject: 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.

 

[Owen] Pump.io, as you possibly know, pretty much just defines one API for
both uses. Its’ nice, simple, and elegant, other than a few workarounds for
the limitations of OAuth 1.0 (“proxyURLs” among them)

 

Dialback is a purely inter-domain authentication mechanism, for the
Server2Server API. Authentication is probably the least elegant part of the
Pump API; we could do better. While I have my reservations about OAuth 2.0
(being a “framework”, not a protocol, among them), I do think that actually
it provides the right set of building blocks here (Or: the framework is
fine; they should have just defined a baseline profile as well!)

 

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

[Owen] ActivityStreams 1.0 defines “collections”; Pump.io models your
relationships (followers, following, plus any collections of people you
might add, e.g. ‘family’) purely as collections of people.

 

If we are rebasing AS 2 on JSON-LD, then I’m inclined to day that we should
map this to FOAF, such that people can use FOAF properties to more richly
describe themselves.

 

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

 

[Owen] I think we should pick a discovery protocol (e.g. WebFinger) and then
permit anything which can successfully be discovered by said protocol. My
preference is WebFinger (its’ simple, it works), and that, for user input,
we should adopt the same normalization scheme as OpenID Connect, as it makes
sense:
http://openid.net/specs/openid-connect-discovery-1_0.html#IdentifierNormaliz
ation
<http://openid.net/specs/openid-connect-discovery-1_0.html%23IdentifierNorma
lization> 

 

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. Non stampare questa mail se non è necessario.