Social Web Community Group Teleconference

16 Aug 2017

Attendees

Present: cwebber, aaronpk, nightpool, ben_thatmustbeme, cwebber2
Regrets Chair: Chris Webber
Scribe: nightpool, cwebber2, aaronpk

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
... 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
... 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

follower liveness https://github.com/swicg/general/issues/17

<Loqi> [Gargron] #17 Follower liveness

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?

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
... One is a user-visible feature, the other is plumbing.

<cwebber2> scribenick: 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

<scribe> scribenick: 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.
... I have a feeling that the best practices for this might change over time, and it might not make sense to codify specifically
... but we probably do want to give some advice (maybe in Security Considerations) and leave it more open-ended
... 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

ajordan: I don't think we want to do something like having a lease, due to complexity, spec incubation 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)

cwebber2: Does anyone have a problem with having it be advisory text, instead of normative?

<cwebber2> scribenick: cwebber2

nightpool: can't entirely speak for gargron but believe that would satisfy us

<scribe> scribenick: nightpool

ajordan: I guess that makes sense, yeah.

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.
... maybe something like drop subscriptions after some arbitrary time? 6 months, or a different arbitrary time?

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

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.

<cwebber2> scribenick: cwebber2

<nightpool> ... You could maybe drop them, and then check again, but that seems like a goofy way to deal with network fragmentation.

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
... but having re-subscribe is a useful part of the spec as a tool

<scribe> scribenick: nightpool

To clarify; Websub solves this uni-directionally

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?

ajordan: to clarify, are you saying that if your server goes down, you would push Unfollows?

cwebber2: No, i'm suggesting the opposite--you re-send follow requests if your follow is not already in place.
... That might not be easy to do if you can't see if youre in the other persons follow collection.
... 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
... so I think the disconnecting after a period of time, or advisement of the same, seems better.
... 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?
... I'll file an issue after this meeting then.
... We already talked a bit about tests.activitypub.rocks, and I didn't have enough time to prepare for the mediaUpload discussion
... but we can talk about it if people still want to, although that has it's own risks
... Or if people have other topics?

<aaronpk> scribenick: aaronpk

nightpool: i can talk about how mastodon's implementation has been going
... 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
... and figuring out how to bridge that in a way that makes sense
... we considered different things like generating URIs for the remote server
... you might not know what the activitypub URI is or even if the server supports activitypub
... the other suggestion was generating local URIs for statuses that were remote. or just giving up and not federating old statuses via activitypub
... if anyone has advice that would be appreciated
... 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
... 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
... so wer'e looking for implementation advice or discussion of the spec

<nightpool> scribenick: nightpool

cwebber2: that was a lot of things! the last one in particular is very interesting.
... Because you're following the kind of forwarding mechanism, and I can see how the delete wouldn't be federated.

<cwebber2> scribenick: cwebber2

<nightpool> ... I can't think of a good solution at the moment, was this a problem in Ostatus as well?

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

<scribe> scribenick: 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
... And it seems confusing and somewhat hard to code correctly or specify.
... This seems like maybe this is a more general social issue, and deserves an issue on the socialcg activity tracker
... nightpool, would you be willing to write up an issue for this?

(ack'd)

cwebber2: One of the other things you brought up was the old-style tag URIs
... Maybe a new URI should be generated, if you own the post. For other posts, I'm not sure
... but there should maybe be an extension for this and that would definitely be a welcome extension
... would you be interested in that?

nightpool: I think it would be a useful extension to have but i'm not sure who has time to write it up
... Right now we're using blank nodes (_:atomUri) to avoid conflicts/as a workaround.

cwebber2: would you be willing to write up a ticket about this?

(ack'd)

cwebber2: we could talk about the media endpoint thing, but we could hold that off to the next meeting
... nevermind, go ahead aj.

ajordan: If you're going to look into (?), can you compile a list of references of how people do this?

cwebber2: Yeah, maybe I should provide a summary for people who aren't familiar.
... Right now on the mediaEndpoint as described, you upload both an object shell and the media you want uploaded at the same time
... and you get a 201 for where that object will actually be, but maybe not whether its ready, etc.
... the problem is that when you want to upload multiple images, or multiple videos, etc.
... 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.
... 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.
... 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 ?

(cut out, I assume the original behavior)

<cwebber2> https://github.com/w3c/activitypub/issues/239

<Loqi> [puckipedia] #239 mediaUpload: only post to outbox if it's a Create activity?

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
... 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.
... How does mastodon do it, nightpool, for reference?

<ajordan> nightpool++

<Loqi> nightpool has 8 karma

nightpool: can't say for certain, but I *believe* we do the same 2-phase submission

<ajordan> https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#media

cwebber2: the mediaUpload endpoint is currently "at-risk", so it's possible we punt this until extensinos
... but I think it's important enough to get right in ActivityPub
... would people want their 10 minutes of life back or are there other things to bring up?
... thanks everybody, sounds like things are going well. Look forward to seeing you all 2 weeks from now.
... things are going well in federated social web world.

<cwebber2> trackbot, end meeting

<cwebber2> nightpool++

<Loqi> nightpool has 9 karma

Summary of Action Items

Summary of Resolutions

[End of minutes]

SocialCG/2017-08-16/minutes

Social Web Community Group Teleconference

16 Aug 2017

Attendees

Contents

follower liveness https://github.com/swicg/general/issues/17

Summary of Action Items

Summary of Resolutions