#social 2018-04-02

2018-04-02 UTC
eprodrom_, eprodro18, eprodrom, fr33domlover, timbl, JanKusanagi, xmpp-social, Guest84 and KjetilK joined the channel
#
@rektide ↩️ There's Linked Data Notifications (https://www.w3.org/TR/ldn/) which would be really great too, better imo. Still doable. But things go really off the map if you want to support my favorite, Generic Event Delivery via HTTP2 aka Web Push Protocol (https://tools.ietf.org/html/rfc8030). (twitter.com/_/status/980815369714708485)
#
cwebber2 eprodrom: someone named Joshua Branson might contact you... they're working on implementing an ActivityPub dating system :)
#
ajordan !!!!!!!
#
eprodrom good for them
#
cwebber2 eprodrom: I pointed them to your slides
#
eprodrom cool
fr33domlover, eprodrom_, eprodrom and joshuaBPMan joined the channel
#
joshuaBPMan waves hello
eprodrom joined the channel
#
@downey ↩️ I'm sure @dustyweb would appreciate your help (or that of anyone else) in working on standards, e.g. https://www.w3.org/TR/activitypub/ (twitter.com/_/status/980862053312118784)
eprodrom_, eprodrom, eprodro67, rektide and downey joined the channel
#
@im_dario ↩️ Tras leerme la especificación de ActivityPub [0], que ha salido su versión 1.0 hace poco, pero lleva tres años construyéndose por grandes de los estándares web, debo decir que ya tenemos la base. No hay necesidad de reinventar la rueda. 0: https://www.w3.org/TR/activitypub/ (twitter.com/_/status/980878493042003968)
eprodrom_, eprodrom and evanp joined the channel
#
evanp aaronpk: are you around?
#
aaronpk yes hi
#
evanp Cool!
#
evanp So, I want to put an issue for discussion on the next cg meeting
#
evanp Which is about OAuth 2.0 scopes for ActivityPub
#
aaronpk sweet
#
evanp Yeah
#
evanp but also scary
#
evanp Do you have a couple of minutes to chat about it?
#
aaronpk sure
#
evanp For pump.io, we don't use scopes
#
evanp So it's all-or-nothing
#
evanp Which is pretty scary for people
#
evanp We have ~3-4 profiles of applications for pump.io
#
evanp 1) Mobile or Web client. Read all your feeds, post new stuff, change the social graph, all that jazz. Pretty much your main client.
#
evanp 2) Bridges. Typically they push your content from pump.io into another network.
#
evanp 3) pump.io peers. These are other sites running pump.io. You can log in with your account from *your* pump.io site, and then interact with the other pump.io site like it was your own. Like things, comment on things, share them, follow people, etc.
#
evanp 4) Rando apps. There are a couple of games, browser utilities to like or share stuff on the web, etc.
#
evanp A typical thing that people say, when they're talking about using OAuth on pump.io, is that they might be OK with letting, say, a peer site post comments in reply to stuff on that server, but not on ANYTHING
#
evanp Which I think is the whole point of scopes
#
evanp I think a coarse scope division -- read vs. write, say -- might be too wide-ranging for this kind of app
#
evanp So I see two ways we could do scopes
#
aaronpk i'm a little confused about #3 there
#
evanp OK
eprodrom joined the channel
#
aaronpk if you're logging in to someone else's site, that doesn't really involve granting that site permissions on your site right?
#
evanp Well
#
evanp It does, because you're doing things like "liking" things on that site
#
evanp So those likes go back to your own site
#
aaronpk ah, how do they get back to your site?
#
evanp Hmm
eprodrom_ joined the channel
#
evanp Pronoun problem there
#
evanp Could you be more specific with "they" and "your"
#
aaronpk okay I am site A, and I log in to site B to like a post somewhere on B.
#
aaronpk when I take that action on B, how does my site A find out about the like?
#
evanp The server on site B uses the API on site A to create a "like" action
#
aaronpk aha okay
#
aaronpk so it's acting as a client in that sense
#
evanp Yes exactly
#
aaronpk gotcha
#
evanp A user on Site A could go to the profile page of someone on Site B and click the "Follow" button, and the right thing will happen
#
aaronpk yeah i wouldn't want to grant that site permissions to do arbitrary things on my site
#
evanp Yeah, unfortunately that's the way it works now
#
aaronpk yikes
#
evanp I know right
#
fr33domlover evanp, what if site B didn't send the Like, and instead using browser JS, your browser sends it directly to site A?
#
evanp fr33domlover: that's a great what if, but I'm not asking about redesigning this system to use the browser
#
aaronpk so you're looking for ways to limit what clients can do so it can keep working that way?
#
evanp aaronpk: yes, I'm thinking about it like this
#
evanp First, let's take read-only access. There are a few things you might want to do at a fine-grained level:
#
evanp
#
evanp 1. Know my identity (authentication only)
#
evanp 2. Read my profile
#
evanp 3. Read my outbox (activities I've done)
#
evanp 4. Read my inbox (activities by people I follow)
#
evanp 5. Read my social graph (following, followers, lists)
#
evanp I think there are probably good arguments to do those fine-grained or coarse-grained (READ_ALL_MY_STUFF)
#
evanp For the write-access, it basically comes down to posting activities
#
evanp As you might remember, in ActivityPub, AS2 activities have a type ("Like", "Follow") and an object with an ID
#
evanp So fine grained scopes might be
#
evanp 1. "Like" things with IDs like "https://othersite.example/*"
#
evanp 2. "Follow" things with IDs like "https://othersite.example/*"
#
evanp 3. "Create" new "Note" objects in reply to things with IDs like "https://othersite.example/*"
#
saranix sounds like OCAP/caveats/macaroons
#
evanp So, say, if othersite.example is another pump.io site, when I log in there, I can like and follow things and make comments (notes), but only for stuff that's there
#
aaronpk that's probably a good limitation
#
aaronpk i feel like you could also build in that limitation without using scopes
#
aaronpk just as a part of the token that's issued to the site after authorizing
#
aaronpk since you already will know what site the token is being issued to
Sveta joined the channel
#
evanp OK, but like I said above, we have different kinds of apps
#
evanp For example, there's an app for liking *anything* on the web
#
evanp So it would want a scope like
#
evanp 1. "Like" things with IDs like "*"
#
aaronpk right so *some* apps would get permissions to be able to like any post, so maybe that's the only scope defined for that
#
aaronpk and by default the tokens are limited to interacting with posts on the server the token is issued to
#
evanp Interesting
#
evanp So we could do scopes like this:
#
evanp 1. Read anything.
#
aaronpk this seems like it's going to mainly be a UI problem, letting the user know exactly what permissions the app will have after logging in
#
evanp 2. Make new activities, restricted to the client's site.
#
evanp 3. Make new activities, unrestricted.
#
evanp That's pretty tight, and I think it covers the clients I talked about above
#
aaronpk that's not bad
joshuaBPMan left the channel
#
evanp I'm trying to think through my feelings as a user
#
evanp Like, if I am logging into another site, am I OK with that site posting *any* kind of activity, as long as it's just about stuff on that site?
#
evanp I kind of feel that I am
#
evanp I think I might want more control for apps that work on any kind of objects across the Web
#
evanp I might get queasy with letting them do *anything*, and want to restrict it by verb
#
evanp activity type, I mean
#
aaronpk i might want to limit the site to only posting likes and follows, and not posting replies
#
evanp Right
jankusanagi_ joined the channel
#
evanp I probably should go look at some of the scopes available on FB, Google+, Twitter
#
aaronpk fair warning, FB is a beast
#
aaronpk github went crazy with scopes too
#
evanp Oh yeah?
#
evanp Right, I remember that
#
aaronpk twitter is read/write/dms
#
evanp I find the scopes on GH really intimidating
#
aaronpk yeah and super confusing with all the org permissions
#
evanp Like, does this app need to set webhooks on my projects that I'm working on with W3C? Probably not.
#
evanp I think there's also an anti-pattern in apps that over-ask for permissions because they *might* want to do that thing, and then they barf if you don't give them all the permissions they ask for
#
evanp But anywho
#
evanp Maybe we start with read, write-restricted-to-site, write-unrestricted
#
evanp It covers a lot of territory pretty well
#
evanp All right, this has been helpful
#
aaronpk 👍
#
evanp I'm going to write this up and put it on the agenda for the CG meeting next week
#
evanp aaronpk: thanks for your help!
#
aaronpk np!
cwebber2 and bwn joined the channel; evanp left the channel