15:04:40 <RRSAgent> RRSAgent has joined #social
15:04:40 <RRSAgent> logging to http://www.w3.org/2017/08/16-social-irc
15:04:42 <trackbot> RRSAgent, make logs public
15:04:42 <Zakim> Zakim has joined #social
15:04:44 <trackbot> Meeting: Social Web Working Group Teleconference
15:04:44 <trackbot> Date: 16 August 2017
15:04:47 <aaronpk> good morning bots
15:04:50 <cwebber2> present+
15:04:52 <aaronpk> present+
15:04:55 <Azure> Good morning.
15:04:56 <nightpool> present+
15:05:08 <ben_thatmustbeme> present+
15:05:22 <Azure> I can't join on Mumble at the moment since I'm at work, but I shall be present here
15:05:27 <cwebber2> Azure: cool
15:05:46 <cwebber2> #topic SocialWG updates
15:05:56 <nightpool> cwebber2: First topic is update from the social working group
15:06:08 <nightpool> ... starting with updates from aaron about WebSub
15:06:28 <nightpool> aaronpk: got an implmentation report from Google for their implementation
15:06:51 <nightpool> .... they've been running a public PuSH hub for a long time, and they ran the websub tests on it and everything passed
15:07:17 <nightpool> ... the group decided to request the transition to PR yesterday, and I'll be taking care of that and preparing the paperwork for it
15:07:23 <nightpool> scribenick: nightpool
15:08:02 <nightpool> aaronpk: after PR there are no real changes to a spec, but it's a chance for other member companies to review the spec and give a thumbsup/thumbsdown
15:08:10 <cwebber2> https://test.activitypub.rocks/
15:08:19 <nightpool> cwebber2: on my side, the first third of the test suite went live
15:08:53 <nightpool> cwebber2: so far only the middle checkbox is working (client-to-server server)
15:09:43 <nightpool> cwebber2: The other update is that we approved a couple of non-normative changes to ActivityPub, but they don't require implementation changes
15:09:48 <cwebber2> #topic Introducing new members (broid.ai?)
15:09:52 <nightpool> ... there may be a couple of those coming down the pipe though
15:10:07 <cwebber2> Azure, would you like to introduce yourself to the group?  (Also, did you join the SocialCG?)
15:10:31 <nightpool> cwebber2: The next topic is introducing new members. Azure on irc is new, and maybe they could introduce themselves? I don't recognize the username, but they might be one of the people from broid.ai
15:11:13 <nightpool> ... I had a call with the people from broid.ai, they've been using AS2 very heavily for their messaging system, and they're excited to take part in the group
15:12:09 <nightpool> cwebber2: We can wait for Azure to give an update asynchrnously b/c they're on IRC. Let's move on to follower liveness for now
15:12:17 <cwebber2> topic: follower liveness https://github.com/swicg/general/issues/17
15:12:18 <Loqi> [Gargron] #17 Follower liveness
15:12:52 <timbl> timbl has joined #social
15:13:22 <aaronpk> q+
15:13:27 <cwebber2> ack aaronpk
15:13:33 <nightpool> cwebber2: This was a ticket Gargron filed this week. The gist is that in websub there's an expiration on follows, and you have to renew the follow every so often. The idea is to maybe consider adding this to AP in some way. Any comments?
15:14:32 <cwebber2> q?
15:14:43 <nightpool> aaronpk: Looking at websub, the important thing that websub does well is separate the subscription itself from whether someone is following someone. I don't know exactly what the right answer is for activitypub, but having a seperate concept for "subscriptions" is important, and does seem to be missing from AP right now
15:14:53 <nightpool> ... One is a user-visible feature, the other is plumbing.
15:14:55 <nightpool> q+
15:15:07 <cwebber2> scribenick: cwebber2
15:16:08 <cwebber2> nightpool: just underscoring the perceived need or story here is that in the past 4-5 months there have been N mastodon instances created, and N/4 of them have dropped out.  Right now there's lots and lots of trying to push updates or re-subscribe, and trying to figure out at what point you don't need to figure out what kind of point you don't need to push things out seems like a network health thing we need to take care of
15:16:18 <cwebber2> scribenick: nightpool
15:16:24 <cwebber2> q+
15:16:27 <cwebber2> ack nightpool
15:16:29 <cwebber2> ack cwebber
15:16:54 <nightpool> cwebber2: Personally I wonder whether or not it makes sense to put this into ActivityPub as the protocol itself. I'm not against it, but maybe this is more implementation advice.
15:17:11 <nightpool> ... I have a feeling that the best practices for this might change over time, and it might not make sense to codify specifically
15:17:35 <nightpool> ... but we probably do want to give some advice (maybe in Security Considerations) and leave it more open-ended
15:17:56 <ajordan> q+
15:17:59 <cwebber2> ack ajordan
15:18:08 <nightpool> ... The lease maybe seems not to be the core of the issue--you generally notice when subscriptions stop happening. That seems more like advisement? I'm not completely sure
15:19:06 <nightpool> ajordan: I dont' think we want to do something like having a lease, due to complexity, spec time, etc. I do seem a room in the spec for determing when a server is "definitely dead" (they return 410 Gone for a while, or similar)
15:19:11 <cwebber2> q+
15:19:13 <cwebber2> ack cwebber
15:19:15 <nightpool> s/dont'/don't/
15:19:28 <ajordan> s/spec time/spec incubation time/
15:19:58 <nightpool> cwebber2: Does anyone have a problem with having it be advisory text, instead of normative?
15:20:08 <ajordan> q+
15:20:13 <cwebber2> scribenick: cwebber2
15:20:23 <cwebber2> nightpool: can't entirely speak for gargron but believe that would satisfy us
15:20:27 <cwebber2> scribenick: nightpool
15:20:37 <nightpool> ajordan: I guess that makes sense, yeah.
15:20:49 <nightpool> ack ajordan
15:21:45 <nightpool> cwebber2: It doesn't seem like anybody has a problem with that. I think this is probably a good way to move forward then, to get some non-normative text into the spec. We should get some advice on what that is, though.
15:21:51 <ajordan> q+
15:21:58 <cwebber2> ack ajordan
15:22:13 <nightpool> ... maybe something like drop subscriptions after some arbitrary time? 6 months, or a different arbitrary time?
15:22:20 <cwebber2> q?
15:22:32 <cwebber2> q+
15:22:36 <cwebber2> ack cwebber2
15:22:39 <nightpool> ajordan: what happens to the followers collection? do you prune ones you're not delivering to? Or just flag? Pruning makes more sense but seems kinda dirty
15:22:42 <nightpool> q+
15:23:24 <nightpool> cwebber2: My thoughts are that you'd maybe prune them. ? pointed out that some people disappeared from the Diaspora network for some time, and then re-appeared.
15:23:26 <cwebber2> ack cwebber
15:23:27 <cwebber2> ack nightpool
15:23:32 <cwebber2> scribenick: cwebber2
15:23:41 <nightpool> ... You could maybe drop them, and then check again, but that seems like a goofy way to deal with network fragmentation.
15:24:24 <cwebber2> nightpool: the thing that having it in the spec does allow for, and what I think websub kind of solves in this area, is there's an opt-in way to come back.  I don't think it works super well, there's a problem where people drop a lot and then ask super re-subscribe
15:24:34 <cwebber2> nightpool: but having re-subscribe is a useful part of the spec as a tool
15:24:36 <cwebber2> q+
15:24:40 <cwebber2> scribenick: nightpool
15:24:44 <cwebber2> ack cwebber
15:24:51 <nightpool> To clarify; Websub solves this uni-directionally
15:25:35 <nightpool> cwebber2: Now that you've pointed out that, it seems like the right thing to do is push an Unfollow notification (?) which the user might not get?
15:25:56 <ajordan> q+
15:26:01 <cwebber2> ack ajordan
15:26:14 <nightpool> ajordan: to clarify, are you saying that if your server goes down, you would push Unfollows?
15:26:33 <nightpool> cwebber2: No, i'm suggesting the opposite--you re-send follow requests if your follow is not already in place.
15:26:52 <nightpool> cwebber2: That might not be easy to do if you can't see if youre in the other persons follow collection.
15:27:22 <nightpool> cwebber2: I can see the merits of the websub route but I don't think we're going to get anything in in this time-period
15:27:33 <nightpool> ... so I think the disconnecting after a period of time, or advisement of the same, seems better.
15:28:14 <nightpool> cwebber2: It seems like we've exhausted the ideas on this. Do we have a resolution to get something about this into the spec, but what exactly is still TBD?
15:28:36 <nightpool> cwebber2: I'll file an issue after this meeting then.
15:29:27 <nightpool> cwebber2: We already talked a bit about tests.activitypub.rocks, and I didn't have enough time to prepare for the mediaUpload discussion
15:29:48 <nightpool> ... but we can talk about it if people still want to, although that has it's own risks
15:29:55 <nightpool> ... Or if people have other topics?
15:30:03 <nightpool> q+
15:30:12 <aaronpk> ack nightpool
15:30:17 <aaronpk> scribenick: aaronpk
15:30:29 <aaronpk> nightpool: i can talk about how mastodon's implementation has been going
15:31:19 <aaronpk> ... right now, 3 servers are running the activitypub code. most of the issues we've run into are around migrating ostatus identifiers and what happens when we have a reaslly old status someone wants to boost or fave
15:31:27 <aaronpk> ... and figuring out how to bridge that in a way that makes sense
15:31:39 <aaronpk> ... we considered different things like generating URIs for the remote server
15:31:53 <aaronpk> ... you might not know what the activitypub URI is or even if the server supports activitypub
15:32:16 <aaronpk> ... the other suggestion was generating local URIs for statuses that were remote. or just giving up and not federating old statuses via activitypub
15:32:27 <aaronpk> ... if anyone has advice that would be appreciated
15:32:50 <aaronpk> ... we also ran into issues around how to federate delete objects. if you try to do best-effort deletion on a status it can easily not go to all the people the original status went to
15:33:13 <aaronpk> ... for example if person A sends out a status and person B boosts it, then person A deletes it. the deletion reaches person B but not all the followers of person B
15:33:20 <cwebber2> q?
15:33:21 <aaronpk> ... so wer'e looking for implementation advice or discussion of the spec
15:33:26 <cwebber2> q+
15:33:28 <cwebber2> ack cwebber2
15:33:46 <nightpool> scribenick: nightpool
15:33:54 <nightpool> cwebber2: that was a lot of things! the last one in particular is very interesting.
15:34:15 <nightpool> ... Because you're following the kind of forwarding mechanism, and I can see how the delete wouldn't be federated.
15:34:49 <cwebber2> scribenick: cwebber2
15:35:06 <nightpool> ... I can't think of a good solution at the moment, was this a problem in Ostatus as well?
15:35:08 <cwebber2> nightpool: I think this problem was extant in ostatus as in activitypub; hope that in a new spec we could have a solution but I think the hole was in both specs
15:35:14 <cwebber2> scribenick: nightpool
15:36:31 <nightpool> cwebber2: I'm open to considering solutions but I don't know what they would be. If you're forwarding to followers you don't know of, it seems like you would have to extend the forwarding mechanism so that if you saw a Delete, that was about an object at a future point, you would have to forward that delete as well
15:36:54 <nightpool> ... And it seems confusing and somewhat hard to code correctly or specify.
15:37:32 <nightpool> cwebber2: This seems like maybe this is a more general social issue, and deserves an issue on the socialcg activity tracker
15:37:52 <nightpool> cwebber2: nightpool, would you be willing to write up an issue for this?
15:37:54 <nightpool> (ack'd)
15:38:08 <nightpool> cwebber2: One of the other things you brought up was the old-style tag URIs
15:38:53 <nightpool> cwebber2: Maybe a new URI should be generated, if you own the post. For other posts, I'm not sure
15:39:07 <nightpool> ... but there should maybe be an extension for this and that would definitely be a welcome extension
15:40:17 <nightpool> cwebber2: would you be interested in that?
15:40:31 <nightpool> nightpool: I think it would be a useful extension to have but i'm not sure who has time to write it up
15:41:00 <nightpool> ... Right now we're using blank nodes (_:atomUri) to avoid conflicts/as a workaround.
15:41:16 <nightpool> cwebber2: would you be willing to write up a ticket about this?
15:41:18 <nightpool> (ack'd)
15:42:06 <cwebber2> q?
15:42:10 <cwebber2> ack cwebber
15:42:29 <ajordan> q+
15:42:35 <cwebber2> ack ajordan
15:42:35 <nightpool> cwebber2: we could talk about the media endpoint thing, but we could hold that off to the next meeting
15:42:49 <nightpool> ... nevermind, go ahead aj.
15:43:07 <nightpool> ajordan: If you're going to look into (?), can you compile a list of references of how people do this?
15:43:25 <nightpool> cwebber2: Yeah, maybe I should provide a summary for people who aren't familiar.
15:43:51 <nightpool> cwebber2: Right now on the mediaEndpoint as described, you upload both an object shell and the media you want uploaded at the same time
15:44:22 <nightpool> cwebber2: and you get a 201 for where that object will actually be, but maybe not whether its ready, etc.
15:44:46 <nightpool> cwebber2: the problem is that when you want to upload multiple images, or multiple videos, etc.
15:45:33 <nightpool> cwebber2: So what we originally had was a 2-phase submission, adopted from pump.io, mediagoblin, etc. where you upload media and then an object relating to it.
15:46:13 <nightpool> cwebber2: the issues with that are two-fold, in that you can't upload metadata for an individual media object, and you need a garbage collection routine.
15:46:54 <nightpool> cwebber2: If you don't wrap the object in Create, you're uploading it to wrap it in another object. If you *do* wrap it in Create ?
15:47:06 <nightpool> (cut out, I assume the original behavior)
15:47:24 <cwebber2> https://github.com/w3c/activitypub/issues/239
15:47:25 <Loqi> [puckipedia] #239 mediaUpload: only post to outbox if it's a Create activity?
15:47:43 <nightpool> cwebber2: But one problem is that most sites do still do this two-phase kind of solution, including twitter and micropub, so maybe we want to do it that way still
15:48:04 <cwebber2> q?
15:48:11 <nightpool> cwebber2: I haven't had time to do enough research, and this does seems somewhat hacky to overload the Create activity, but that's the state of that.
15:49:00 <nightpool> cwebber2: How does mastodon do it, nightpool, for reference?
15:49:17 <ajordan> nightpool++
15:49:17 <Loqi> nightpool has 8 karma
15:49:19 <nightpool> nightpool: can't say for certain, but I *believe* we do the same 2-phase submission
15:49:36 <ajordan> https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#media
15:49:41 <nightpool> cwebber2: the mediaUpload endpoint is currently "at-risk", so it's possible we punt this until extensinos
15:49:50 <cwebber2> q?
15:49:56 <nightpool> cwebber2: but I think it's important enough to get right in ActivityPub
15:50:21 <nightpool> cwebber2: would people want their 10 minutes of life back or are there other things to bring up?
15:50:59 <nightpool> cwebber2: thanks everybody, sounds like things are going well. Look forward to seeing you all 2 weeks from now.
15:51:15 <nightpool> ... things are going well in federated social web world.
15:51:15 <cwebber2> trackbot, end meeting
15:51:15 <trackbot> Zakim, list attendees
15:51:15 <Zakim> As of this point the attendees have been cwebber, aaronpk, nightpool, ben_thatmustbeme
15:51:20 <cwebber2> nightpool++
15:51:21 <Loqi> nightpool has 9 karma
15:51:23 <trackbot> RRSAgent, please draft minutes
15:51:23 <RRSAgent> I have made the request to generate http://www.w3.org/2017/08/16-social-minutes.html trackbot
15:51:24 <trackbot> RRSAgent, bye
15:51:24 <RRSAgent> I see no action items