Re: Social API: Scope

FWIW, AS2 does not *re-base* itself on JSON-LD, it aligns with
JSON-LD. It's a critical difference. That said, however, it makes
perfect sense to leverage as much of the existing semantic
vocabularies as we can. VCard, FOAF, the Org Ontology... the current
AS2 draft lists a minimal set [1] that ought to work with or without
JSON-LD processing.

[1] http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#jsonld

- James

On Thu, Jul 31, 2014 at 10:15 AM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> 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#IdentifierNormalization
>
>
>
> 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.
>
>

Received on Thursday, 31 July 2014 17:33:12 UTC