15:01:44 <RRSAgent> RRSAgent has joined #social
15:01:44 <RRSAgent> logging to http://www.w3.org/2017/04/18-social-irc
15:01:44 <cwebber> o/
15:01:46 <trackbot> RRSAgent, make logs public
15:01:46 <Zakim> Zakim has joined #social
15:01:48 <trackbot> Zakim, this will be SOCL
15:01:48 <Zakim> ok, trackbot
15:01:49 <trackbot> Meeting: Social Web Working Group Teleconference
15:01:49 <trackbot> Date: 18 April 2017
15:01:55 <cwebber> present+
15:01:55 <aaronpk> present+
15:01:59 <rhiaro> present+
15:02:01 <Loqi> meeting time
15:02:02 <Loqi> Countdown set by ben_thatmustbeme on 2017-04-18 at 2:27pm UTC
15:02:06 <sandro> present+
15:02:07 <ajordan> present+
15:02:30 <cwebber> agenda is at https://www.w3.org/wiki/Socialwg/2017-04-18
15:02:31 <timbl> timbl has joined #social
15:02:32 <sandro> sandro has changed the topic to: Next telcon: https://www.w3.org/wiki/Socialwg/2017-04-18 IRC logs: http://socialwg.indiewebcamp.com/irc/social/today
15:02:53 <cwebber> ajordan, np
15:03:08 <eprodrom> present+
15:03:30 <sandro> Agenda: https://www.w3.org/wiki/Socialwg/2017-04-18
15:03:39 <rhiaro> o/
15:04:02 <aaronpk> scribenick: aaronpk
15:04:11 <eprodrom> chair: eprodrom
15:04:20 <KevinMarks> Present+
15:04:30 <KevinMarks> May be irc only
15:04:49 <eprodrom> https://www.w3.org/wiki/Socialwg/2017-04-11-minutes
15:04:51 <aaronpk> TOPIC: last week's minutes
15:05:03 <eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-04-11-minutes as minutes for previous telecon
15:05:15 <cwebber> +1
15:05:16 <sandro> +1
15:05:23 <rhiaro> +1
15:05:23 <eprodrom> +1
15:05:27 <aaronpk> <aaronpk> +1
15:05:39 <eprodrom> RESOLVED: Accept https://www.w3.org/wiki/Socialwg/2017-04-11-minutes as minutes for previous telecon
15:06:18 <aaronpk> TOPIC: ActivityPub
15:06:41 <aaronpk> cwebber: a new tutorial for activitypub, i threw it together after sketching it out on paper. i was thinking about adding something like this to the introduction to the activitypub document
15:07:01 <aaronpk> eprodrom: i need an update on why we have a meeting today, since we had a scheduled meeting next week
15:07:12 <aaronpk> ... i understand there is a crucial deadline for activitypub?
15:07:17 <aaronpk> TOPIC: why are we here
15:07:21 <csarven> present+
15:07:37 <aaronpk> sandro: i wouldn't characterize it as quite that urgent. but it seems like activity is picking up on activitypub and we have a lot to do.
15:07:57 <aaronpk> ... i sent an email that there's a process loophole that gives us more time than we thought. we just have to get to PR by the charter, not REC by the charter.
15:08:05 <aaronpk> ... so we have until May 13th to make any normative changes if we really push the line.
15:08:34 <aaronpk> ... but given we have all this external interest, it seems like keeping the discussion going quickly is good. like if it turns out mastodon says you really need to make this change then we need to know this as soon as possible
15:09:00 <aaronpk> eprodrom: the thing i want to avoid is doing a deep dive on the tutorial for examle and then we have 5 minutes to do the important things
15:09:05 <aaronpk> ... do we have a vote we need to take by the end of the day?
15:09:08 <aaronpk> cwebber: no
15:09:31 <aaronpk> sandro: lets' focus on the things that are going to get the community together on an interoperable implementation
15:09:48 <aaronpk> eprodrom: so we're going to be going through some of the issues on activitypub and make sure we move things forward
15:09:52 <aaronpk> TOPIC: ActivityPub
15:10:33 <aaronpk> cwebber: we had an open item to include an introduction with clear diagrams and examples. i had sketched out on paper how to make it clear what's happening with the inbox and outbox. i turned that into the ascii art tutorial.
15:10:43 <aaronpk> ... a lot of people responded positively especially in the ostatus sphere
15:11:15 <aaronpk> ... i'd encourage people to read it and see what they think. one of the pieces of feedback we got before was "oh this seems like a lot" but now with the tutorial it's more "this is pretty straightforward"
15:11:20 <ben_thatmustbeme> present+
15:11:35 <aaronpk> eprodrom: i've seen tutorials as separate documents. is it normal to have a tutorial in a spec document?
15:11:56 <aaronpk> sandro: if it goes through every feature then it makes sense separate, but this seems more like a hello world so it's fine in the spec
15:12:37 <aaronpk> eprodrom: the only thing i'm worried about putting such a large text in the spec is it asks for some definitions, but that's probably okay. getting the text right is non-normative so we don't have to worry about getting it perfect the first time out.
15:12:41 <aaronpk> TOPIC: Implementation Updates
15:12:52 <aaronpk> cwebber: there's been a lot of discussion. the most interesting is probably with mastodon.
15:13:16 <aaronpk> ... there's been a lot of questions, the leader seems supportive of exploring things. people seem to want activitypub because they want a better private distribution support.
15:13:51 <aaronpk> ... evanminto is making progress on it. we've got open issues elsewhere like diaspora, but that seems more like conversation right now. tho one person seems to think diaspora might move forward with it.
15:14:16 <aaronpk> ... other projects like postActiv and gnusocial are considering it. postActiv has someone assigned to it.
15:14:33 <aaronpk> .... for pump.io, they plan to do a branch soon as a feature branch but won't merge it until PR
15:14:43 <ajordan> so for pump.io
15:14:54 <ajordan> we will probably ship it preffed off July 1
15:15:10 <eprodrom> ajordan: can we get an implementation report and test results sooner?
15:15:17 <ajordan> eprodrom: absolutely
15:15:21 <eprodrom> +1
15:15:33 <eprodrom> Implementation reports are what get us out the door
15:15:48 <ajordan> I'm planning on submitting an implementation report as soon as the code is written, which should be this week or the next week
15:16:04 <eprodrom> https://www.w3.org/wiki/Socialwg/ActivityPub_network
15:16:18 <aaronpk> eprodrom: there is a page which links to all the known open issues on different projects
15:17:16 <aaronpk> ... we are talking about getting implmeentations of server-to-server and client-to-server as separate things. mastodon was only interested in server-to-server for example.
15:17:56 <aaronpk> eprodrom: sounds like a lot of activity. pushing it through from open issues to online implementations will be the big move over the next few weeks.
15:18:02 <aaronpk> TOPIC: test suite
15:18:28 <aaronpk> cwebber: i know i said i'd have it earlier. it took me a while toget the interface stuff done, and have some initial test done, but i need to document it so you don't go insane looking at the code
15:18:38 <aaronpk> ... i'm feeling very optimistic about it. by next week we should have a much more exciting update.
15:19:06 <aaronpk> cwebber: evan would you want to schedule time this week to do an overview of the code? or just email
15:19:18 <aaronpk> eprodrom: yeah i'm happy to sit down and talk about it
15:19:57 <aaronpk> eprodrom: i volunteered to help out with the test code, if anyone else wants to help then you're welcome to come otherwise it's not a helpful meeting to be at
15:20:41 <aaronpk> TOPIC: activitypub issues
15:20:51 <ajordan> which meeting? next WG meeting?
15:21:13 <aaronpk> cwebber: i put the issues that need more heavy discussion first
15:21:15 <cwebber> https://github.com/w3c/activitypub/issues/185
15:21:36 <aaronpk> ... there are two sides for this. pump.io has this and we somehow omitted it.
15:21:57 <aaronpk> ... every object can be favorited and liked and shared around, and you want to track that.
15:22:05 <aaronpk> ... pump.io has two names for this, "likes" and "shares"
15:22:12 <aaronpk> ... and we don't have those
15:22:26 <aaronpk> ... hilariously we've clobbered the namespace. we use "likes" to be what pump.io calls "favorites"
15:22:56 <aaronpk> ... i think what we need to do is add these two properties "shares" and "likes" and possibly rename the "actors" collection to "favorites" to avoid a naming collision
15:23:04 <ajordan> I believe favorites and likes are the same thing in pump.io? eprodrom?
15:23:33 <aaronpk> eprodrom: that seems reasonable
15:24:02 <eprodrom> {totalItems: 30, url: "..."}
15:24:10 <aaronpk> ... this would be a valid collection
15:24:19 <eprodrom> {type: "Collection", totalItems: 30, ...}
15:24:20 <rhiaro> q+ to comment on rename of actor's likes
15:24:35 <aaronpk> ... there's a way to link to the collection with the number and url for the collection
15:24:39 <aaronpk> ... the big thing is getting the number out
15:24:57 <aaronpk> ... there's synchronization issues when you include numbers like this across boundaries, but i think that's a reasonable mechanism
15:25:40 <aaronpk> cwebber: i think one advantage of using the collection is it could be someone included just the number but hopefully they included all the objects as well
15:26:00 <aaronpk> ... you can't really trust a number you get across a federated boundary anyway
15:26:22 <aaronpk> ... i think it's useful to have it be a number and also a collection
15:26:53 <aaronpk> sandro: i was worried about the security there. if you get all the objects, you can dereference as many as you like, and see that they check out. if you get a number, you can't verify it, an attractive nuicance.
15:27:04 <aaronpk> cwebber: that's why having it be a collection with a number as a cache is the best route
15:27:20 <aaronpk> sandro: what would you do with the number? if you display it, then you've propagated the attractive nuisance to the user.
15:27:32 <aaronpk> cwebber: all the federated implementations have that problem anyway. you either trust that number or you don't
15:28:01 <aaronpk> sandro: we should at least say something in the security considerations.
15:28:10 <aaronpk> ... is there also some sort of security checks you should or must do before passing the number on?
15:28:25 <aaronpk> cwebber: i'm hesitant to suggest that because i don't think we'd get that completely right
15:28:58 <aaronpk> rhiaro: i wanted to comment on renaming the collection
15:29:06 <aaronpk> ... favorites bugs me because there are two spellings of it
15:29:14 <aaronpk> ... could we call it something more precise like "things liked"?
15:29:25 <aaronpk> cwebber: we could call it 'liked' instead of 'likes'
15:30:38 <aaronpk> eprodrom: 'likes' is a link to a collection of objects this actor has liked
15:31:13 <aaronpk> cwebber: okay i think that will be a normative change so we've already entered that territory.
15:31:29 <rhiaro> yep
15:31:31 <aaronpk> ... given the comments sandro has made then we should just do normative changes instead of trying to work around that
15:31:36 <cwebber> https://github.com/w3c/activitypub/issues/192
15:32:08 <aaronpk> cwebber: i wanted amy's feedback on this. we mention that you can discover an actor's profile at one point in the exit criteria and then it's never mentioned again.
15:32:48 <aaronpk> ... shoudl we allow the profile to be used as an actor. it allows people to have multiple identities.
15:33:14 <aaronpk> Zakim: who is on the call?
15:33:20 <aaronpk> Zakim: who is here?
15:33:26 <sandro> Zakim, who is on the call?
15:33:27 <Zakim> Present: cwebber, aaronpk, rhiaro, sandro, ajordan, eprodrom, KevinMarks, csarven, ben_thatmustbeme
15:33:31 <eprodrom> Please mute you mic
15:33:42 <cwebber> muted
15:33:44 <eprodrom> Muted
15:33:49 <csarven> Muted when joined
15:33:50 <ajordan> already muted
15:33:53 <aaronpk> <aaronpk> muted
15:33:55 <eprodrom> Thank you
15:33:55 <rhiaro> always muted when I'm not talking
15:34:05 <eprodrom> KevinMarks: ?
15:34:10 <ben_thatmustbeme> oops
15:34:14 <csarven> ^^^ that guy
15:34:19 <ajordan> lol
15:34:35 <aaronpk> cwebber: it looks like amy made a suggestion on this issue already
15:34:49 <aaronpk> ... that would allow people to create sub-identities for themselves. does that seem like ar easonable thing to add?
15:34:51 <rhiaro> q+
15:35:00 <aaronpk> ... does that mean the new profiles would have their own inbox and outbox?
15:35:05 <eprodrom> q+
15:35:22 <aaronpk> rhiaro: i feel like making it clear that it's allow, then let the implementations decide how it's allowed
15:35:54 <cwebber> q+
15:36:03 <aaronpk> ... i think all we need for activitypub is to make it clear you can use it
15:36:19 <aaronpk> eprodrom: this feels like a lot of complication without a lot of payoff
15:36:36 <ajordan> q+
15:36:42 <aaronpk> ... having multiple profiles with multiple endpoints, i don't see a lot of reason to not just use multiple accounts in that case
15:36:52 <rhiaro> q+
15:37:14 <cwebber> cwebber-
15:37:15 <aaronpk> ... it seems like we're using it because it got into activitystreams and i'm not a fan of how it got there either. so unless there's a clear use case we need this then i feel very -1 on this
15:37:24 <eprodrom> ack cwebber
15:37:45 <aaronpk> cwebber: i'm okay with it existing as long as we treat it exactly like an actor object anyway
15:37:47 <rhiaro> right
15:38:15 <aaronpk> ... but i agree if we start doing the thing where the implementation needs to traverse and find the relationship between it and the actor then it will add more complexity
15:38:23 <aaronpk> ... i'm okay with including it but i dont feel strongly about it
15:38:45 <rhiaro> Talkinga bout different personas was the use case. Not something I think should be in the spec.
15:38:51 <rhiaro> I don't want to add ANY of this stuff to the spec.
15:39:03 <aaronpk> eprodrom: once we're talking about different identities, like evan as w3c chair, or evan as fuzzy.io ceo, or evan as father of children, those are all different aspects to my personality. i think diaspora calls that aspects event.
15:39:16 <aaronpk> ... what we do for that is lists in pump.io and direct things to different follower lists
15:39:24 <ajordan> ajordan-
15:40:05 <aaronpk> cwebber: i might have a quick way to resolve this.
15:40:31 <rhiaro> but Profile isn't listed in AS2 as an actor type
15:40:37 <rhiaro> just under objects
15:40:37 <aaronpk> ... to drop all the language about the profile object. since activitypub says these are generally activitystreams actor types then it's expected you're probably producing one of the existing ones. if someone wants to go crazy they can.
15:40:45 <rhiaro> q
15:40:47 <rhiaro> q?
15:40:54 <ajordan> q-
15:41:05 <eprodrom> ack rhiaro
15:41:05 <Zakim> rhiaro, you wanted to comment on rename of actor's likes and to  and to
15:41:08 <eprodrom> ack eprodrom
15:41:35 <aaronpk> rhiaro: i said it was an implementation detail, so we leave it open for implementations but we don't add anything to the spec
15:41:50 <aaronpk> ... that's whyu i suggested adding the "or a profile object" because profiles aren't actors
15:42:01 <aaronpk> ... but i wouldn't try to figure out implemnentation details in the spec
15:42:36 <ajordan> q+
15:42:55 <aaronpk> eprodrom: i feel like this is important but complex. if an implementation has a Profile as one of the things that has inbox/outbox etc then that's up to the implementation
15:43:07 <eprodrom> ack ajordan
15:43:28 <aaronpk> ajordan: since we're talking about complexity, it's worth noting that getting the privacy right on this is difficult.
15:43:44 <cwebber> I agree re: privacy w/ these use cases
15:43:46 <cwebber> q+
15:44:10 <sandro> q+
15:44:24 <aaronpk> eprodrom: adding a privacy note to the security considerations is probably important.
15:45:02 <aaronpk> sandro: so far this has been too loosey-goosey to know what the argument is. so maybe we can look at this as what will the test suite have different based on the resolution of this
15:45:04 <ajordan> so we talkd earlier about treating Profiles as Actors so they didn't share inboxes or anything, but assuming that wasn't the case there's this issue of identity correlation based on inbox URLs
15:45:13 <aaronpk> cwebber: i don't think the test suite would do anything differently
15:45:22 <ajordan> no nono
15:45:50 <aaronpk> eprodrom: let's focus on profiles as actors
15:46:09 <aaronpk> ... it seems like we could add that to the test suite
15:46:18 <aaronpk> ... have a Profile that you can follow as if it were an Actor
15:46:48 <aaronpk> cwebber: are people fine with adding the Profile object then?
15:47:05 <aaronpk> ... my suggestion for how to close this out is to just not mention it and it wouldn't specifically be blocked it would just be not mentioned
15:47:27 <aaronpk> ... would people prefer to include it as an option? or just be never mentioned?
15:47:31 <aaronpk> sandro: we need test cases either way
15:47:45 <aaronpk> ... otherwise we don't have interoperability
15:47:54 <aaronpk> cwebber: i suggest we include it and add a test case
15:48:20 <aaronpk> ... adopting the language amy added, and mentioning it in the security section, and adding it as a test case
15:48:42 <eprodrom> PROPOSED: Accept rhiaro's edit to close https://github.com/w3c/activitypub/issues/192
15:48:51 <cwebber> +1
15:49:03 <eprodrom> +1
15:49:07 <rhiaro> +1
15:49:11 <ajordan> +1
15:49:13 <sandro> +1 with new test case
15:49:15 <KevinMarks> KevinMarks has joined #social
15:49:25 <ben_thatmustbeme> +1 sounds reasonable
15:49:54 <eprodrom> RESOLVED: Accept rhiaro's edit to close https://github.com/w3c/activitypub/issues/192
15:50:55 <cwebber> https://github.com/w3c/activitypub/issues/198
15:51:25 <cwebber> https://github.com/w3c/activitypub/issues/185
15:51:34 <aaronpk> cwebber: actually if we only have 10 minutes let's go back to the previous issue
15:51:39 <aaronpk> ... we never ended up saying what the "share" object was
15:51:49 <aaronpk> ... we used to have a "share" object in AS2 but it was dropped
15:51:59 <aaronpk> ... now we have an "announce" object which is ambiguous and doesn't mean "share"
15:52:12 <cwebber> https://github.com/w3c/activitypub/issues/186
15:52:54 <aaronpk> eprodrom: this is sharing
15:53:00 <aaronpk> cwebber: we're going to agree that this is sharing and i'll add the side effects to the document then?
15:53:14 <cwebber> https://github.com/w3c/activitypub/issues/194
15:53:22 <aaronpk> cwebber: one challenging thing is the webfinger side of things. this came up from mastodon
15:53:49 <aaronpk> ... how do people migrate from using webfinger identity into a https identifiers rather than webfinger
15:53:55 <aaronpk> ... i have a suggestion for how to do this
15:53:57 <cwebber> https://github.com/tootsuite/mastodon/issues/1557#issuecomment-294529696
15:54:28 <aaronpk> ... in this mastodon thread, sandro pointed out that we can use the acct uri, it could create problems by using both a mixture of https and acct URIs
15:54:37 <aaronpk> ... so my suggestion is to add an informative section as follows
15:55:03 <aaronpk> ... you'd end up saying okay if you have a post that uses a webfinger ID in the UI somewhere, you look up the webfinger ID and look up their https address to send it via activitypub
15:55:27 <aaronpk> ... the other thing is you have an actor's profile, how do you look up what the webfinger ID is. my suggestion is you take the "preferred username" slot and append @ the domain name
15:55:48 <aaronpk> ... however there's a possibly problem. there's the possibility that preferredusername is not unique
15:55:58 <aaronpk> ... eprodrom do you have comments on this?
15:56:10 <eprodrom> webfinger: "evan@e14n.com"
15:56:18 <aaronpk> eprodrom: it seems to me like a property "webfinger" would solve the problem
15:56:39 <aaronpk> ... i agree that doing webfinger lookup to get the activitypub ID is good, we may need to define a link type to make that happen
15:57:07 <aaronpk> ... i'm not sure this is core to activitypub though, this might need to be an extension
15:57:26 <aaronpk> cwebber: i think your suggestion of adding a webfinger property is good especially since this is coming up now
15:57:35 <aaronpk> eprodrom: my suggestion is to make it an extension
15:57:57 <aaronpk> ... a bridge between webfinger and actiivtypub. it's only important right now because there are people using webfinger but that might drop off
15:58:32 <aaronpk> cwebber: i don't know what to say to the mastodon people then, if we don't have any extension process now.
15:58:46 <aaronpk> sandro: i think it would be great to see how lightweight we can make the extension process then
15:58:51 <aaronpk> eprodrom: could it be a wiki page?
15:59:06 <KevinMarks> What is the webfinger use case? Give me the profile url for $username at $domain?
15:59:22 <aaronpk> ... anyone doing a new implementation of activitypub would look at that section and say why do i need to support webfinger?
15:59:25 <ajordan> KevinMarks: basically
15:59:36 <ajordan> we're discussing transitioning legacy Webfinger systems
15:59:37 <aaronpk> ... i think just because mastodon wants it now, isn't a good reason to include it for the people reading this 10 years from now
15:59:56 <aaronpk> cwebber: i guess we're out of time so iw on't bring up any more issues
16:00:48 <aaronpk> cwebber: the spec didn't permit federation without client to server but last week we talked about allowing that
16:00:52 <KevinMarks> I think there is a much simpler way to do that.
16:00:55 <aaronpk> eprodrom: do we need fto have a discussion about that
16:01:29 <aaronpk> cwebber: there's nothing that jumps out to me as long as people are okay with ......
16:01:53 <aaronpk> eprodrom: i'm going to ask to extend for 10 minutes
16:01:54 <sandro> +1 extending whatever's useful
16:02:17 <aaronpk> eprodrom: i don't udnerstand your question. do you want us to look through the list and see if anything else needs to be addressed today?
16:02:28 <aaronpk> cwebber: i'm just getting confused by process i guess
16:03:31 <eprodrom> PROPOSED: Extend meeting by 30 minutes
16:03:34 <sandro> +1
16:03:35 <cwebber> +1
16:03:35 <ajordan> +1
16:03:37 <wilkie> do we have a wiki for activity pub for cwebber and my own notes on the webfinger/identity legacy stuff? because it should go there, not in the spec itself, I'd think
16:03:37 <rhiaro> +1
16:03:39 <eprodrom> +1
16:03:55 <sandro> wilkie, sure, the group wiki is the w3c wiki which is fine
16:03:56 <eprodrom> RESOLVED: Extend meeting by 30 minutes
16:04:09 <eprodrom> wilkie: agreed!
16:04:23 <KevinMarks> +1 for Wiki about webfinger replacement
16:04:36 <aaronpk> sandro: if it's going to affect the test suite, change implementations, or make someone mad, then bring it to the group. otherwise you don't need to.
16:04:50 <cwebber> https://github.com/w3c/activitypub/issues/189
16:05:07 <aaronpk> cwebber: inboxes. this is a conversation that amy and i went through already.
16:05:41 <KevinMarks> Wilkie: I have some ideas on replacing webfinger to contribute as well.
16:05:52 <aaronpk> rhiaro: this is basically a clarification but turns out to be a normative clarification
16:05:58 <eprodrom> https://github.com/w3c/activitypub/issues/189#issuecomment-294332336
16:06:09 <wilkie> we don't need to *replace* webfinger, I mean... that's a little bit extreme
16:06:37 <aaronpk> ... whenever we say "inboxes must accept post request" we caveat that with "federated implementations" because some implementations may not accept post requsts and still be valid
16:07:48 <eprodrom> PROPOSED: close issue 189 by adding text from https://github.com/w3c/activitypub/issues/189#issuecomment-294332336
16:07:53 <KevinMarks> Implementing webmention is extreme, I think we can do something much simpler.
16:07:53 <cwebber> +1
16:07:57 <ajordan> +1
16:07:59 <eprodrom> +1
16:08:00 <wilkie> +1
16:08:35 <rhiaro> +1
16:08:39 <KevinMarks> (I meant replace in the mastodon codebase/ostatus stack)
16:08:43 <eprodrom> RESOLVED: close issue 189 by adding text from https://github.com/w3c/activitypub/issues/189#issuecomment-294332336
16:08:45 <sandro> +1
16:09:01 <cwebber> https://github.com/w3c/activitypub/issues/191
16:09:21 <aaronpk> cwebber: we have endpoints for OAuth authorize, but never added an endpoint for getting an access token
16:09:28 <aaronpk> ... this person suggested adding it to the endpoint section
16:09:38 <aaronpk> ... i haven't thought what the best name for it is
16:09:58 <aaronpk> sandro: everyone has to do this? or only if you're doing oauth?
16:10:02 <aaronpk> cwebber: only if you're doing oauth
16:10:16 <aaronpk> ... it doesn't make anyone reverse anything they already did.
16:10:22 <aaronpk> q+
16:10:55 <aaronpk> eprodrom: i'd like to push this to the end of the call
16:13:15 <eprodrom> PROPOSED: close https://github.com/w3c/activitypub/issues/191 by adding properties with names from OAuth2 spec and revising current oauthClientAuthorize property name
16:13:18 <cwebber> +1
16:13:19 <ajordan> +1
16:13:24 <eprodrom> +1
16:13:36 <sandro> +1
16:13:41 <aaronpk> <aaronpk> +1
16:13:57 <eprodrom> RESOLVED: close https://github.com/w3c/activitypub/issues/191 by adding properties with names from OAuth2 spec and revising current oauthClientAuthorize property name
16:14:00 <rhiaro> +1
16:14:11 <cwebber> https://github.com/w3c/activitypub/issues/198
16:15:43 <aaronpk> cwebber: there's some ambiguity around what ambiguity means. it sounds fine but it makes it sound like the only way to do delivery is HTTP post
16:15:51 <aaronpk> .. but there's an obvious exception which is that you don't have to do this if you're on the same server
16:16:10 <aaronpk> ... so i don't want to make it sound like iuf you're on the same server you have to do a POST to yourself
16:16:21 <eprodrom> https://github.com/w3c/activitypub/issues/198#issuecomment-294855618
16:16:29 <aaronpk> eprodrom: amy gave some proposed text in a comment
16:16:47 <eprodrom> PROPOSED: close issue 198 by including text from https://github.com/w3c/activitypub/issues/198#issuecomment-294855618
16:17:08 <eprodrom> +1
16:17:09 <rhiaro> +1
16:17:10 <ajordan> +1
16:17:10 <sandro> +1
16:17:17 <cwebber> +1
16:18:02 <wilkie> +1
16:18:04 <eprodrom> RESOLVED: close issue 198 by including text from https://github.com/w3c/activitypub/issues/198#issuecomment-294855618
16:18:07 <cwebber> https://github.com/w3c/activitypub/issues/188
16:19:11 <aaronpk> cwebber: this person has experience around distributed database things. they suggested including revision IDs to avoid accidentally clobbering things
16:19:42 <aaronpk> eprodrom: you know there's an updated timestamp on activities, so the ID plus the updated timestamp should be unique enough to say what revision it is
16:19:48 <aaronpk> ... that's what we used for pump.io
16:20:00 <ajordan> q+
16:20:14 <aaronpk> aaronpk-
16:20:15 <cwebber> q-
16:20:17 <eprodrom> ack cwebber
16:20:20 <aaronpk> q-
16:20:22 <eprodrom> ack sandro
16:20:33 <eprodrom> ack ajordan
16:20:49 <aaronpk> ajordan: using the timestamp assumes everyone's clock is reasonably synchronized
16:21:22 <aaronpk> eprodrom: i don't think it's as much as a big deal being synchronized as it is having your clock stay current.
16:21:34 <aaronpk> ... as long as i'm talking to you, we go by your clock.
16:21:55 <KevinMarks> This is how Google's protocol ended up mandating atomic clocks
16:21:59 <cwebber> q+
16:22:04 <eprodrom> ack cwebber
16:22:33 <aaronpk> sandro: is this supposed to be aligned in any way with HTTP? if you're doing a GET or PUT then HTTP has last-modified and etags which are all for revision control
16:22:44 <aaronpk> ... it would be nice if this is using URIs for things then to just use those
16:23:15 <aaronpk> eprodrom: there isn't really anything keeping it from being aligned. i think "update" ends up being the same as "last-modified" header. etag would map to this revision ID idea.
16:23:22 <cwebber> q+
16:23:32 <eprodrom> ack cwebber
16:24:04 <cwebber> https://github.com/w3c/activitypub/issues/155
16:24:07 <aaronpk> cwebber: one reason to explore this in future efforts... as for adding anything new, we should wait for the future
16:24:56 <aaronpk> sandro: one simple thing we could do is to say that the time counter MUST increment. you try to make it an accurate time, but you at least never use the same timestamp twice.
16:25:23 <KevinMarks> https://xoxo.zone/@KevinMarks/71212
16:25:24 <Loqi> [Kevin Marks] @maiyannah can you just use etag/lastmodified for this? if the etag is a hash of the profile then it should do what you want.
16:26:06 <KevinMarks> So fuzz leapseconds
16:26:41 <cwebber> https://github.com/w3c/activitypub/issues/196
16:27:09 <aaronpk> cwebber: if you imagine you're using any of these social networks, you might have your stream of posts and a different 1-1 conversation thread with someone
16:27:50 <aaronpk> ... the commenter said they want the private message flagged differently and not just the things streaming through the inbox
16:28:00 <aaronpk> ... there were a number of directions to go with this, a "priority" flag property
16:28:01 <wilkie> I don't think you need to spec how the revision or tag is generated, just that it may be used to reject updates
16:28:49 <aaronpk> cwebber: i have a hard time thinking that we're going to make any sensible change to the spec within the timeframe we have
16:29:09 <aaronpk> ... but we're seeing that they're insistent we hvae some sort of flag, otherwise they will use an extension
16:29:14 <aaronpk> ... my feeling is to do this as an extension
16:29:33 <wilkie> I don't understand the distinction they want and how audience tracking doesn't just solve this
16:29:47 <wilkie> what is the difference between a message sent to only you and an important message sent to only you
16:30:07 <rhiaro> I don't really understand why clients can't figure this out from the addressing and any other context they want to take into account
16:30:20 <rhiaro> and different clients might handle it differently which is fine..
16:30:24 <wilkie> exactly
16:31:07 <wilkie> clients will either ignore some measure of priority or publishers will abuse it
16:31:57 <aaronpk> ajordan: it's not clear when you should put individual people in the "to" field, so maybe that's where theconfusion is coming from
16:32:44 <rhiaro> "Clients are responsible for addressing new Activites appropriately. To some extent, this is dependent upon the particular client implementation, but clients must be aware that the server will only forward new Activities to addressees in the to, bto, cc, bcc, and audience fields."
16:32:51 <aaronpk> ... if you're trying to implement a feature that says this is a direct message, then you can say it's a direct message if there is only you in the "to" field
16:33:14 <rhiaro> it actually says you must dereference addressed collections and individually address everything doesn't it? so maybe that's the problem..
16:33:35 <aaronpk> cwebber: one more thought on this. my impression is that one thing pump.io has that activitypub doesn't have is the differentiation between a major feed and minor feed.
16:34:07 <aaronpk> ... it coudl be reasonable to say to the inbox give me all the stuff that's directed just to me
16:34:16 <rhiaro> q+
16:34:21 <wilkie> rhiaro: ah typo there ... apparently "Activites" is in the document twice
16:34:38 <aaronpk> eprodrom: we're over our overtime
16:34:39 <eprodrom> ack rhiaro
16:35:20 <aaronpk> rhiaro: there's a section about client addressing in the spec. whenever you find obects attached to an activity you shoudl follow these links and dereference the collections and put them in the "to" field
16:35:49 <rhiaro> http://w3c.github.io/activitypub/#client-to-server-interactions
16:35:50 <aaronpk> ... maybe we can't solve this now and we need to think about the wording some more
16:36:13 <aaronpk> cwebber: so i should remove the "postponed" flag since it seems like there is more conversation to be had
16:36:36 <aaronpk> eprodrom: let's wrap up the meeting since we're already over time
16:36:42 <eprodrom> trackbot: end meeting
16:36:42 <trackbot> Zakim, list attendees
16:36:42 <Zakim> As of this point the attendees have been cwebber, aaronpk, rhiaro, sandro, ajordan, eprodrom, KevinMarks, csarven, ben_thatmustbeme
16:36:50 <trackbot> RRSAgent, please draft minutes
16:36:50 <RRSAgent> I have made the request to generate http://www.w3.org/2017/04/18-social-minutes.html trackbot
16:36:51 <trackbot> RRSAgent, bye
16:36:51 <RRSAgent> I see no action items