15:06:32 <RRSAgent> RRSAgent has joined #social
15:06:32 <RRSAgent> logging to https://www.w3.org/2018/04/11-social-irc
15:06:48 <evanp> evanp has joined #social
15:06:50 <trackbot> trackbot has joined #social
15:06:53 <aaronpk> trackbot, start meeting
15:06:53 <trackbot> Sorry, but no Tracker is associated with this channel.
15:06:55 <aaronpk> huh yeah
15:06:57 <evanp> Huh
15:07:45 <aaronpk> trackbot, we're starting without you
15:07:45 <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.
15:08:33 <aaronpk> TOPIC: OAuth 2
15:08:49 <aaronpk> evanp: pump.io has been implementing OAuth 2
15:08:56 <aaronpk> to get C2S and S2S working
15:09:15 <aaronpk> getting a few tens of thousands more users on activitypub
15:09:19 <puckipedia> oh woops
15:09:20 <puckipedia> one sec
15:09:23 <aaronpk> we did not have scopes in the previous api based on oauth 1.0
15:09:30 <aaronpk> there were some questions around that from users
15:09:44 <aaronpk> you either have the choice of giving total control or no control, which is a stark choice
15:09:57 <aaronpk> for pump.io, with the existing api, there are 4 classes of clients that use the api
15:10:16 <aaronpk> 1) "normal" clients, android/ios, some web clients, that are giving you a full social networking experience
15:10:32 <aaronpk> you read the inbox, post items, post text or files, etc, follow, unfollow, etc
15:10:52 <aaronpk> the pump.io web UI is a client in that way, it requests authorization the same way any other client would
15:11:34 <aaronpk> 2) read-only clients like bridges, pushing your data out to other networks, doing analysis, etc.
15:12:06 <aaronpk> 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
15:12:12 <aaronpk> openfarmgame is the best example
15:12:29 <aaronpk> 4) web browser utilities, a "like" button in your web browser
15:12:36 <aaronpk> focused on one kind of activity but operating across the web
15:12:56 <aaronpk> that doesn't cover everything but those are the kinds we had
15:13:20 <aaronpk> 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
15:13:27 <aaronpk> that remote pump.io site acts just like any other client
15:13:50 <aaronpk> looking at OAuth 2.0 scopes for activitypub and thinking about what scopes we want to support, activitypub doesn't define scopes yet
15:14:01 <aaronpk> which is kind of a bummer because people implementing clients, knowing a fixed group of scopes is useful
15:14:21 <aaronpk> 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
15:14:26 <aaronpk> it seems there are two ways people do scopes
15:14:49 <aaronpk> 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
15:15:05 <aaronpk> that gives a lot of control to the user, but also is a lot of overhead to the user
15:15:15 <aaronpk> there is some cognitive load that has the unfortunate side effect that people just click through
15:15:37 <aaronpk> the other path that other implementers take is a very minimal set of scopes.
15:16:17 <aaronpk> after some discussion in #social with aaron, we worked on a first version of scopes, a fairly minimal set of scopes
15:16:43 <aaronpk> we want to put these up and say hey everyone should implement these scopes
15:16:49 <aaronpk> we took a look at our existing clients and came up with four scopes
15:17:07 <aaronpk> 1) login authorization. no read or write access, just identification
15:17:22 <aaronpk> 2) "read": gives full read access to your account
15:17:28 <aaronpk> anything that the user can read the application can read
15:17:36 <aaronpk> user profile, user social graph, user's inbox feed, and outbox feed
15:18:05 <jankusanagi_> jankusanagi_ has joined #social
15:18:08 <aaronpk> 3) "writeown": the client can post activities that are related to the client's own server
15:18:35 <aaronpk> so if it's a game, the targets of the activities are on the same domain as the game
15:18:53 <aaronpk> so a game at openfarm.example, the IDs of the targets would be on openfarm.example otherwise refused
15:19:23 <aaronpk> 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
15:19:40 <aaronpk> 4) "writeall": for full-featured client applications, like an android client
15:19:49 <aaronpk> that is implemented in pump.io right now
15:19:55 <aaronpk> in the master branch
15:20:04 <aaronpk> we'll be rolling out 5.2 version in the next few weeks
15:20:16 <aaronpk> so we'll have that implementation available to start testing
15:20:36 <aaronpk> 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
15:20:43 <aaronpk> our hope is that the scopes will be useful for our clients
15:21:05 <aaronpk> 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
15:22:52 <aaronpk> 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
15:24:00 <aaronpk> puckipedia: one question I had was how abusable this could be, like writing a reply to a post on that server... (unintelligible)
15:24:18 <aaronpk> 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
15:24:34 <aaronpk> ... yeah that's a risk of the "writeown" is that there's a lot of flexibility for the third party client to fudge around
15:24:52 <aaronpk> ... 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
15:25:50 <aaronpk> 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
15:26:12 <aaronpk> ... for example when you log in to an app on facebook you can choose whether the app can make public posts
15:27:24 <evanp> Mumble kicked me off
15:27:44 <evanp> I was saying, yes, we could go REALLY fine grained in scopes
15:27:56 <evanp> Which gives much more end user control
15:28:07 <aaronpk> 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
15:28:13 <evanp> At the cost of UI complexity
15:28:36 <aaronpk> ... my point is that a server can implement that limitation without scopes
15:28:42 <evanp> Ah, that's fair!
15:29:10 <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
15:29:35 <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
15:29:46 <evanp> ...or phase them out over time
15:32:04 <aaronpk> aaronpk: has this been written up anywhere besides the pump.io docs yet?
15:32:15 <aaronpk> evanp: not yet, i'll give myself a task to create a wiki page describing this before our next meeting
15:32:47 <aaronpk> TOPIC: Activity Streams context
15:33:04 <aaronpk> evanp: at our last meeting we had discussed updating the context to add some properties that hadn't been caught.
15:33:16 <aaronpk> ... I did an update to the doc and it's in the github repository and sent an email to sandro and amy
15:33:31 <aaronpk> 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
15:34:51 <aaronpk> [end of meeting]
15:35:02 <aaronpk> RRSAgent, end meeting
15:35:02 <RRSAgent> I'm logging. I don't understand 'end meeting', aaronpk.  Try /msg RRSAgent help
15:35:47 <aaronpk> RRSAgent, create minutes
15:35:47 <RRSAgent> I have made the request to generate https://www.w3.org/2018/04/11-social-minutes.html aaronpk
15:36:09 <aaronpk> RRSAgent, bye
15:36:14 <aaronpk> RRSAgent, make minutes public
15:36:14 <RRSAgent> I'm logging. I don't understand 'make minutes public', aaronpk.  Try /msg RRSAgent help
15:36:20 <aaronpk> ffs
15:36:37 <aaronpk> RRSAgent, make logs public
15:37:03 <aaronpk> RRSAgent, bye
15:37:03 <RRSAgent> I see no action items