SocialCG/2018-04-11/minutes

W3C

Social CG

Attendees

Present

aaronpk

evanpro

puckipedia

melody

Regrets

Chair

aaronpk

Scribe

aaronpk

Contents

• Topics
  1. OAuth 2
  2. Activity Streams context

---

trackbot, start meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

huh yeah

<evanp> Huh

trackbot, we're starting without you

<trackbot> Sorry, aaronpk, I don't understand 'trackbot, we're starting without you'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

OAuth 2

evanp: pump.io has been implementing OAuth 2

to get C2S and S2S working

getting a few tens of thousands more users on activitypub

<puckipedia> oh woops

<puckipedia> one sec

we did not have scopes in the previous api based on oauth 1.0

there were some questions around that from users

you either have the choice of giving total control or no control, which is a stark choice

for pump.io, with the existing api, there are 4 classes of clients that use the api

1) "normal" clients, android/ios, some web clients, that are giving you a full social networking experience

you read the inbox, post items, post text or files, etc, follow, unfollow, etc

the pump.io web UI is a client in that way, it requests authorization the same way any other client would

2) read-only clients like bridges, pushing your data out to other networks, doing analysis, etc.

3) a group of projects that operate on their own data, play a game and generate activities where all the data is related to that game

openfarmgame is the best example

4) web browser utilities, a "like" button in your web browser

focused on one kind of activity but operating across the web

that doesn't cover everything but those are the kinds we had

another that operates only on its own data, you can log into a pump.io site from another pump.io site and then follow people and comment and share

that remote pump.io site acts just like any other client

looking at OAuth 2.0 scopes for activitypub and thinking about what scopes we want to support, activitypub doesn't define scopes yet

which is kind of a bummer because people implementing clients, knowing a fixed group of scopes is useful

if I direct my android client at something that supports activitypub it would be nice if it understood when I askf or certain types of access

it seems there are two ways people do scopes

one is in super fine grained detail. other companies do this down to giving access to certain parts of your account, who you're following, post this kind of activity, etc

that gives a lot of control to the user, but also is a lot of overhead to the user

there is some cognitive load that has the unfortunate side effect that people just click through

the other path that other implementers take is a very minimal set of scopes.

after some discussion in #social with aaron, we worked on a first version of scopes, a fairly minimal set of scopes

we want to put these up and say hey everyone should implement these scopes

we took a look at our existing clients and came up with four scopes

1) login authorization. no read or write access, just identification

2) "read": gives full read access to your account

anything that the user can read the application can read

user profile, user social graph, user's inbox feed, and outbox feed

3) "writeown": the client can post activities that are related to the client's own server

so if it's a game, the targets of the activities are on the same domain as the game

so a game at openfarm.example, the IDs of the targets would be on openfarm.example otherwise refused

activitystreams objects are kind of complex, so we're imagining a little flexibility, but the general expectation is things like "reply to" "like" "follow" the activity would be closely related to the originating client

4) "writeall": for full-featured client applications, like an android client

that is implemented in pump.io right now

in the master branch

we'll be rolling out 5.2 version in the next few weeks

so we'll have that implementation available to start testing

the question is will clients say it's too much hassle to ask for certain types of scope and ask for maximum and expect people to click through

our hope is that the scopes will be useful for our clients

my goal is to write this up as a wiki page or note for the CG so as other folks are implementing C2S for activitypub they can use similar scopes

aaronpk: that sounds great. i'd love to see this documented on the wiki, and once there is one or more client implementations, publish as whatever report format the community group can publish

puckipedia: one question I had was how abusable this could be, like writing a reply to a post on that server... (unintelligible)

evanp: are you saying we have a hostile client that attempts to write posts in reply to IDs that it knows it has access to
... yeah that's a risk of the "writeown" is that there's a lot of flexibility for the third party client to fudge around
... I don't think it's an iron-clad security system, that's not the goal here, it's to set a scope for what's okay and not okay

puckipedia: it might also be possible to be able to pre-set some scope, like all the posts this client makes can be public or private, etc
... for example when you log in to an app on facebook you can choose whether the app can make public posts

<evanp> Mumble kicked me off

<evanp> I was saying, yes, we could go REALLY fine grained in scopes

<evanp> Which gives much more end user control

aaronpk: that mechanism is different from scopes. scope is an agreement between clients and servers, and for that example you actually don't want the client to know that they've been limited so the posts are only visible to the user

<evanp> At the cost of UI complexity

aaronpk: my point is that a server can implement that limitation without scopes

<evanp> Ah, that's fair!

<evanp> So, for pump.io, we're going to go with a coarse-grained set of scopes out of the box, which reflects the actual use we've seen from third-party clients

<evanp> And if the community goes more down the path of fine-grained scopes, we'll probably still support our high-level ones for developers who've come to depend on them

<evanp> ...or phase them out over time

aaronpk: has this been written up anywhere besides the pump.io docs yet?

evanp: not yet, i'll give myself a task to create a wiki page describing this before our next meeting

Activity Streams context

evanp: at our last meeting we had discussed updating the context to add some properties that hadn't been caught.
... I did an update to the doc and it's in the github repository and sent an email to sandro and amy

I haven't heard from either of them about it, I was hoping they'd be on the call, since it'd be useful to get that finished up

[end of meeting]

Summary of Resolutions

[End of minutes]