15:03:52 RRSAgent has joined #social 15:03:52 logging to http://www.w3.org/2017/10/25-social-irc 15:03:54 RRSAgent, make logs public 15:03:54 Zakim has joined #social 15:03:56 Meeting: Social Web Working Group Teleconference 15:03:56 Date: 25 October 2017 15:03:59 scribenick: aaronpk 15:04:05 present+ 15:04:06 present+ 15:04:06 present+ 15:04:08 present+ 15:04:18 present+ 15:04:34 present+ 15:04:34 cwebber: most of the topics today are a holdover from last week 15:04:43 https://www.w3.org/wiki/SocialCG/2017-10-25 15:04:54 TOPIC: Social WG Updates 15:04:59 cwebber: the activitypub test suite is live 15:05:03 https://test.activitypub.rocks/ 15:05:12 ... but still hammering out the bugs with puckipedia 15:05:27 ... so that will take at least the rest of the day before announcing it publicly 15:05:45 ... we are hoping to go to PR by the 14th of next month 15:06:14 ... that means getting the test suite really done, doing all the planned edits, and getting implementation reports in 15:06:48 ... aaron there was something about websub 15:07:33 aaronpk: we talked about a couple of minor editorial edits, and someone submitted a full review, but also yesterday we got a new implementation in the wild... twitch.tv has a new webhook platform using websub so that's exciting 15:07:57 q+ 15:08:06 ack ajordan 15:08:30 ajordan: ryan barrett launched fed.brid.gy and that has successfully been used to reply from an indieweb site to a mastodon post 15:08:35 so that seems to be working now which is phenomenal 15:08:41 cwebber: https://test.activitypub.rocks/ is a 502 for me. 15:08:43 fed.brid.gy 15:08:50 csarven: oops 15:09:04 nightpool: they haven't quite replied yet because it doesn't show up as in reply to but the post itself did federate 15:09:14 neat 15:09:14 csarven: no idea what happened will look post-meeting 15:09:27 csarven: this version is bridging to my own local testdev instance for just the moment, heh 15:09:54 TOPIC: media upload as extension 15:10:10 cwebber: the mediaUpload is moving to the CG to standardize as an extension 15:10:16 ... we need to start the process 15:10:28 ... iguess that's on me unless someone wants to step up 15:10:34 nightpool: what does the process look like for extensions? 15:10:37 q+ 15:10:42 cwebber: i think it's still somewhat ad hoc 15:11:05 icymi I ripped media upload out and put it on the cg wiki yesterday https://www.w3.org/wiki/SocialCG/ActivityPub/MediaUpload 15:11:07 ... someone ends up writing it up in this group and brings it to a meeting and we discuss it and ratify it as an official document through a vote 15:11:25 ack ajordan 15:11:34 rhiaro, yay 15:11:38 ajordan: i might be willing to work on a document or two in a couple weeks 15:11:38 :D 15:11:51 ... if noone else volunteers i might be able to do that maybe question mark 15:12:02 cwebber: you were also looking at activitypub implementation in pump.io? 15:12:15 ajordan: yeah that's one of the things i need to do in the next couple weeks before i commit to anything else 15:12:26 cwebber: amy on IRC points out she moved the media upload section to the wiki 15:12:48 q+ 15:12:48 q? 15:12:52 ack ajordan 15:13:10 ajordan: what would we need to be prepared to have a discussion on that? 15:13:16 ... we want to look at other implementations like twitter? 15:13:21 basically what are our action items here 15:13:23 cwebber: here's the challenges the media upload endpoint was hitting 15:13:54 ... creating an activitystreams object and uploading the media in one swoop which might be fine but one challenge is you wouldn't want to do the create at the same time if you were going to attach it to something else 15:14:03 er1n has joined #social 15:14:09 ... puckipedia and i came up with something which is whethre you wrap it in create is whether it shows up in your outbox 15:14:14 ... but that didn't take into account chunked uploads 15:14:22 thanks 15:14:26 o/ 15:14:36 q 15:14:37 q? 15:14:49 TOPIC: follower migration 15:14:56 https://github.com/swicg/general/issues/1 15:14:57 [sandhawke] #1 Follower Migration 15:15:11 cwebber: this issue has a lot of discussion 15:15:22 ... a number of different routes have been discussed 15:15:35 ... one would be to have some sort of "move" activity 15:15:39 https://github.com/swicg/general/issues/1#issuecomment-331567958 15:15:39 [Gargron] ```js 15:15:39 { 15:15:39 type: 'Move', 15:15:39 actor: 'uri/to/alice', 15:15:40 object: 'uri/to/alice', 15:15:40 target: 'new_uri/to/alice' 15:15:40 } 15:15:41 ``` 15:15:41 Sent out to followers. 15:15:41 Old server's webfinger would need to redirect to new server's webfinger, and new server's webfinger woul... 15:16:03 ... why not codify it as an AS2 object to move one user to another 15:16:12 ... one downside is it wouldn't preserve the URIs of the old activities 15:16:55 ... one reason mastodon didn't do this is it would allow someone to take a big action all at once. but now mastodon has the option to delete an entire user all at once. 15:16:56 FYI. here is the diaspora protocol account migration entity, for reference: https://diaspora.github.io/diaspora_federation/entities/account_migration.html 15:17:16 cwebber: another route would be to have some sort of decentralized identifier 15:17:21 https://w3c-ccg.github.io/did-spec/ 15:17:51 ... DIDs are a combination of replacing DNS and SSL authorities at the same time 15:18:45 q? 15:18:59 er1n has left #social 15:19:01 https://project.hubzilla.org/help/developer/zot_protocol 15:19:02 ... another option is zot's version of nomadic identity 15:19:31 ... which i don't entirely follow. i did take a look at it at one point and when you boil it down it is namespacing a combination of what's effectively the domain it's posted on and someone's unique key 15:19:47 (to close the loop async: msatodon does parse a Delete { Actor } as deleting an entire actor and all of their content, but doesn't expose this to users in any way)) 15:20:09 ... the goal is if you make a post the post has an ID and even if the server is down the post still is identifiable 15:20:31 er11n has joined #social 15:20:53 cwebber: so, the last one is HTTP redirects 15:20:57 ... which could be combined with a move activity 15:21:05 ... maybe you do the move activity and set up http redirects on the old objects 15:21:09 q+ 15:21:25 ack puckipedia 15:22:49 puckipedia: i've been playing with activitypub, and i was thinking of storing the objects as a hash of the object but then you get immutability. but i did take a look at the decentralized IDs and the question is are one of those enough to find the user or object? 15:23:16 ... if you can't take an object ID and find its data then that's kind of the issue with migration 15:23:21 https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/activitypub-decentralized-distributed/activitypub-decentralized-distributed.md 15:23:37 cwebber: in this paper i effectively show how you end up mapping a decentralized identifier to an activitypub object 15:23:55 https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/activitypub-decentralized-distributed/activitypub-decentralized-distributed.md#distributed-identity 15:24:04 ... you should be able to use DIDs in one of two ways. 15:24:28 ... you can replace the objects with DIDs. for example one uses IPFS, another uses bitcoin blockchain, another uses a specific blockchain 15:24:43 ... but they all provide the mechanism of having a linked data object for someone's key and a way to migrate keys 15:25:07 ... so if you lose your phone, you can say if 2 out of these 3 people say it's okay then you can switch to the new key 15:25:31 ... so the example in there shows an activitypub service, it links you to the activitystreams object for the user. but you can also link to it itself 15:25:38 ... so if the receipient is something like this: 15:25:45 {"to": ["did:example:d20Hg0teN72oFeo0iNYrblwqt#services/ActivityPub"]} 15:25:59 ... you could resolve the object and pull down the activitystreams actor 15:26:14 ... there's also a mechanism to do something like HTTP get and post but that's a bit underspecified 15:26:31 ... so there is a way to be able to resolve the object with the DID itself. 15:26:39 q+ 15:26:40 ... i think there's a way to move to DIDs instead of domain names 15:27:07 ... but there's not a clear path to moving from domain names to DIDs. it's clearer if everything uses DIDs from the start 15:27:37 puckipedia: maybe we could define a property like "alternate IDs" 15:27:59 cwebber: i'd need to think more of the consequences of that 15:27:59 ack nightpool 15:28:15 nightpool: i'm trying to follow along. can you give a 10000 foot overview of how resolution of IDs work? 15:28:34 ... i remember some past discussions there was some concern over how web-like these mechanisms are 15:28:48 cwebber: there are multiple methods of resolution for DIDs, each specifies its own 15:29:13 ... in the main DID protocol we're not sure which of the mechanisms are going to work out. the IPFS is probably the most promising 15:29:33 ... the bitcoin one has a lot of overhead. the other one has probably the least overhead 15:29:56 ... but the different methods need to specify the behavior of how to resolve 15:30:45 can someone link the veris(sp?) protocol? googling doesn't seem to be turning anything up 15:31:41 cwebber: there are multiple DID methods. bitcoin, ipfs, veris. they each provide a create, retrieval and update method. 15:32:01 ... however, some of those may require pulling down a large amount of information, such as bitcoin requiring pulling the whole bitcoin graph 15:32:12 ... so similar to how people don't host the whole DNS database, you can have resolvers doing resolution as a proxy 15:33:11 nightpool: right now existing implementations are based around HTTPS, so moving from that to a system that's more complicated seems to be a hard ask 15:34:13 cwebber: so we're exploring multiple methods of follower migration. HTTPS methods require the previous instance be online 15:34:22 ... if there's no redirects then none of the servers will know the content moved 15:34:32 ... if you have a DID then it's more resilient if a server goes down 15:35:01 ... so how will be implement the resolvers 15:35:07 ... i think you just have a library and point at one or more resolvers 15:35:21 q+ 15:35:26 ... you'd be able to say get this DID and point at the resolver you want 15:35:47 ... so we're presuming that it's unlikely that every mastodon server will host a DID database 15:36:01 ack nightpool 15:36:08 nightpool: that brought some clarity but also raised more questions 15:36:27 ... wer'e talking about these DIDs like they're completely interchangeable. but all of them have vastly different drawbacks and affordances. 15:37:12 ... it seems like from an implementation level we can't just push it to a library and have it do the right thing 15:37:26 cwebber: when i was talking about the hub and resolvers, i was talking about a resolver that handles all the methods for you under the same interface 15:38:11 q? 15:38:39 cwebber: where do we go from here? any comments? 15:38:47 q+ 15:38:52 ack aaronpk 15:38:59 scribenick: aaronpk 15:39:38 aaronpk: this feels like going down quite a rabbit hole... I'm a bit confused because everything going around this point has been based around HTTP and very web-like protocols, and up until this point we've been talking about very web-like things 15:40:30 aaronpk: sounds like kinda what you're saying is, are we making the right tradeoffs? 15:40:31 aaronpk: I realize DNS can go down and you're stuck, but you're very likely to have issues with these other systems and we might not know what this is. one benefit of https is dns is not tied to a server, you can move it to a new server etc without having to change your identity... so it seems like http/dns are very natural fits for this, esp in the context of the web, this is the social web community group 15:40:45 q+ 15:41:09 cwebber: i think you're right, https is well understood and widely implemented. it depends on what definition of the web you're talking about. 15:41:23 ... and you're also right that these are kind of out-there tehcnologies that haven't proven themselves yet 15:41:34 ... i'm not saying these are things we should necessarily do, just trying to look at paths to explore 15:41:46 ... and trying to find patterns that map more closely to the things we use 15:41:57 ack ajordan 15:41:58 ... so i'm saying here are some paths we coud potentially go down 15:42:33 ajordan: obviously we dont want to end up with a bunch of different ways to do follower migration. but it sounds like some of the things we're discussing here are breaking changes anyway. 15:42:54 ... so if we start addressing everything with DIDs then it sounds like that would already be a breaking change in the sense that any server on the network that couldn't resolve those addresses would be screwed 15:43:04 ... so i'm wondering can we do something now, and explore these farther out options later 15:43:28 cwebber: that makes sense, that's what i was hoping to push here. get a discussion of what kind of thing we can do now and what can we look for in the future. 15:43:33 q? 15:44:10 ajordan: so we can do things in parallel too. we can ship a minimum viable solution, like shipping http redirects. 15:44:30 ... with the assumption that the far-out things would take longer since we would have to build more stuff and also wait for underlying specs to mature as well 15:44:51 q? 15:45:23 cwebber: so now it's a matter of what people are interested in implementing right now 15:45:38 q+ PurgeActor 15:45:47 ... it might end up being that the best way to continue this discussion is to coordinate if some of these paths start to get implemented 15:45:58 ack nightpool 15:46:17 ack PurgeActor 15:46:28 nightpool: when we talked about this on the mastodon issue about how to delete a user, you mentioned some kind of extension type that specifies side effects like migrating content 15:46:44 ... and in the case of deleting a user should that delete all of the activities or should it just make the user inaccessible 15:46:57 ... maybe the way forward here is thinking about extensions in that area 15:47:18 ... so you could move an actor and say to also rewrite all the IDs 15:47:26 q+ to talk about rewriting ids 15:47:28 ... or you can move an actor and it will just change the representation of the actor in the system 15:47:42 ack cwebber 15:47:42 cwebber, you wanted to talk about rewriting ids 15:48:11 cwebber: what you brought up of what if the move activity also provided some sort of rule to rewrite IDs. i'm a little worried it will be hard to get right 15:48:41 ... reason 1 is you could imagine someone writes a regex to rewrite from one system to another. regexes are pretty messy 15:49:17 ... but also it could open a vector of attack, you could end up saying move all my posts and also gargron's. so i'm nervous about the template rewriting thing. but you're right that if we get this to work we need to figure out howto get it to work correctly 15:49:24 I don't think you'd need regex-level template rewriting 15:49:32 rewriting IDs from something like https://example.org/ID to something like https://new.server/authority/https://example.org/ID is probably doable 15:49:47 I think we might be able to just get away with specifying a less powerful system and then you avoid all those vulns 15:50:20 cwebber: yes specifying a less powerful system would be good. maybe we can start by writing a wiki page about it 15:51:09 nightpool: if you're thinking about some sort of template thing, you can hold the signed move activity and any server that missed it can verify it using linked data signatures 15:51:26 ... so if you have an authentication protocol like that in place then you dodged the "oh the server has to be up" issue 15:51:34 ... because any server can have a signed activity and send it to another server 15:51:52 cwebber: so if the actor has the same key as they had on the previous server, you can be sure it's the same user? 15:52:15 nightpool: yeah if you have the key for nightpool@cyber.space you could import that into a new server and let me sign things as nightpool@cyber.space 15:52:41 ... so maybe this is a little out of spec since mastodon currently thinks of keys as authoritative and there isn't guidance on that in activitypub, we resolve keys through webfinger and map them to users that way 15:52:54 ... i'm not really sureh ow linked data signatures fit into the spec as written 15:53:08 ... but if i can prove i'm acting on behalf of an actor then i don't need to worry about the decentralized ID tihng 15:53:47 cwebber: so mastodon does attach the public key to actors. so if you have a cached copy of the key on an actor and you're able to demonstrate you have the key, then you can do it even though you can't do webfinger requests anymore 15:54:08 cwebber: also users would have to be able to download the key associated with their profile so that they can upload it to the new server when they move over 15:55:01 +1 for deferring, but maybe give a quick summary? 15:55:04 I cannot extend 15:55:10 can't extend 15:55:22 TOPIC: publishing extensions 15:55:53 cwebber: currently in activitypub, there is an extension mechanism for vocabularies. you can have a way to specify new vocabularies not defined in activitypub, but you don't have a mechanism to be sure that the side effects of the activities will be understood by the other servert. 15:56:10 ... so that's what this proposal is about, defining what type sof activities your server is able to understand the side effects for 15:56:29 ... the extension provides a new endpoint that gives back a list of all the extensions represented by URIs that I know how to handle 15:56:39 I herd u liek extensions 15:56:46 haha 15:56:48 rofl 15:56:50 sgtm 15:56:56 so I put some extensions in your extensions so you can extension while you extension 15:57:27 aaronpk++ for scribing! 15:57:27 aaronpk has 96 karma in this channel (1450 overall) 15:57:31 aaronpk++ 15:57:31 aaronpk has 97 karma in this channel (1451 overall) 15:57:33 aaronpk++ 15:57:33 aaronpk has 98 karma in this channel (1452 overall) 15:57:36 cwebber++ for chairing too 15:57:36 slow down! 15:57:40 trackbot: end meeting 15:57:40 Zakim, list attendees 15:57:40 As of this point the attendees have been cwebber, aaronpk, puckipedia, nightpool, alanz, ajordan 15:57:48 cwebber++ for chairing too 15:57:48 RRSAgent, please draft minutes 15:57:48 I have made the request to generate http://www.w3.org/2017/10/25-social-minutes.html trackbot 15:57:49 RRSAgent, bye 15:57:49 I see no action items