15:31:05 RRSAgent has joined #social 15:31:05 logging to http://www.w3.org/2017/08/30-social-irc 15:31:07 RRSAgent, make logs public 15:31:07 Zakim has joined #social 15:31:09 Meeting: Social Web Working Group Teleconference 15:31:09 Date: 30 August 2017 15:31:12 I can scribe 15:31:25 scribe: tsyesika 15:31:26 now, how do i do this scribenick thing 15:31:28 ah! 15:31:29 scribenick: tsyesika 15:32:01 present+ 15:32:11 cwebber2: The first thing on the agenda is updating what happened in the Social WG 15:32:11 present+ 15:32:12 present+ 15:32:15 present+ 15:32:26 present+ 15:32:39 (kind of, watching over kids at the same time) 15:32:54 unarist: type "present+" 15:32:55 cwebber2: this week we agreed to push another ActivityPub CR 15:33:08 present+ 15:33:11 cwebber2: it has some of the changes we've discussed in the group, specifically around follow having explicit accept and reject 15:33:19 cwebber2: as well as moving the publicInbox over to the sharedInbox 15:34:06 cwebber2: Another thing we discussed, we need aaronpk to come to a conclusion is discussing extensions 15:34:50 cwebber2: the first one is the "sensitive" property - various systems have in place some kind of boolean for NSFW content, mastodon has it and is doing a major roll out of AcitvityPub 15:34:58 cwebber2: the other extension is the tag type 15:34:59 https://github.com/w3c/activitypub/issues/231 15:35:00 [cwebber] #231 "Sensitive Media" tag 15:35:07 https://github.com/w3c/activitypub/issues/235 15:35:07 [cwebber] #235 Add a Tag type 15:35:54 cwebber2: Gargron has mentioned in the past "why not have a hashtag type" so we decided to look into why AS and pump.io didn't have it 15:36:04 I'm still confused on what is the difference between a "tag" type and a "hashtag" type. Or are they the same? 15:36:10 same 15:36:15 cwebber2: we spoke to json snell asking why and he said there probably was one but he doesn't recall and (why not have it?) 15:36:49 cwebber2: tantek yes they're the same, when it was initially written up it was called "tag" but evan thought it was clearer as hashtag and that's also what Gargron implemented 15:36:56 cwebber2: those places on the wiki should be updated to "hashtag" 15:37:09 https://www.w3.org/wiki/Activity_Streams_extensions#sensitive_property 15:37:14 cwebber2: I fleshed out the wikipages, linked above 15:37:14 seems fine to me - bikeshedding I can't care enough about :) - I know we don't care as much about silo prior art here - but FWIW FB calls it "tag" everywhere. E.g. tag someone in a post, tag a location etc. 15:37:18 https://www.w3.org/wiki/Activity_Streams_extensions#Hashag_type 15:37:52 tantek: ActivityPub has "tag" property which, like you say, is an array of mentions, categories, locations, whatever. But FB also has "hashtags" 15:38:09 cwebber2: those are the two suggested extensions. Part of the challenge is we don't have a process yet, the CG does have authority to ? extensions but we shouldn't go willy nilly with this 15:38:40 (that makes no sense to me) 15:39:07 cwebber2: mastodon is using linked data signatures 15:39:57 Gargron: to use linked data signatures, you're required to cononicalize the json. It converts the property names from the short from e.g. "tag" to it's fully qualified name based on what is included in the context 15:40:37 Gargron: to verify signatures you need to download the context so basically you either need to DDOS the single context server or cache it 15:40:48 I think we agreed to only adding to the context document IIRC. Or was it AS2 vocab that we agreed to only grow? 15:41:05 Gargron: the problem with the context changing is the signatures will change if the context changes 15:41:18 wow Sandro sounds so much better on Mumble than on Webex. so much more human 15:41:35 sandro: we only add terms to the context, (terms may be deprecated but they'll still exist) 15:42:01 sandro: this would be a problem when someone uses the new term and sends it to someone who hasn't picked up the new term 15:42:17 Gargron: the problem is that it'll invalidate the signature 15:42:34 sandro: systems ought to if there is an invalid context - they should reload the context 15:42:34 cwebber2 has joined #social 15:42:51 {"@context": ["https://www.w3.org/ns/activitystreams", 15:42:52 {"sensitive": "as:sensitive"}]} 15:42:52 [Amy Guy] ActivityStreams 2.0 Terms 15:42:54 "how is this supposed to work for anybody ever" is kind of my summary thoughts on signatures, but I figure smarter people are figuring it out :) 15:42:56 cwebber2: I've got one suggestion: it might mitigate the issue (paste coming on IRC) 15:43:16 cwebber2: you could have a transitional version when a new property is added to inform older versions of the software 15:43:45 cwebber2: if you look at the context put in IRC it also specifies that the sensitive property is under the AS context 15:44:00 cwebber2: then when you're 3 versions ahead you can drop it 15:44:28 sandro: I think the right thing to do is to cache the context for around 6 hours (good enough to avoid DDOS problem) 15:44:42 sandro: if it started to become a problem w3c could change the cache header 15:45:12 Gargron: the problem isn't just the DDOS of the server, the problem is the context is only on one server and it's crucial for signatures. 15:45:26 Gargron: it's a central point of failure. caching for 6 hours is a solution but it's not perfect 15:46:13 Gargron: maybe we're over thinking the problem. the one rule of thumb which may help - never use properties which are not yet included in the context. If we never remove properties which are deprecated and we use new properties 15:46:35 sandro: a practical solution is we'll add the terms weeks before it'll be expected to be used 15:46:52 I'd expect independent implementations to experiment with new properties before they're even publicly discussed, much less added to a centralized context 15:47:02 Gargron: e.g. right now - I have to wait for chris to release the new context with the sensitive tag, etc. before i can release mastodon 15:47:19 q+ 15:47:28 sandro: it's the first release doing data signatures, but lets assume in 6 months we add new terms. Wouldn't there be a problem there? 15:47:33 Gargron: yes that'd still be a problem 15:48:02 jaywink: thats what we do right now 15:48:11 cwebber2: I think the centralisation problem can't be totally solved with something which relies on DNS authority. 15:48:20 sandro: what if we do it expanded all the time 15:48:46 cwebber2: it'd be a big payload 15:49:22 cwebber2: also if someone is using more naive tooling which might only assume it's just JSON 15:49:58 Gargron: We're not actually obligated to use the conicalize algorithm included in the linked data document 15:50:29 Gargron: we could just say we're going to treat the JSON as verbatum and that we're not going to do any expanded or anything 15:50:37 canonicalize 15:50:43 +1 verbatim signature approach sounds promising 15:50:55 cwebber2: that's an option, i've spoken to some people and they've suggested I try and do it but i've not got around to it yet 15:50:57 [ajordan] s/json snell/jason snell/ 15:51:18 Gargron: the problem is I don't know everything about every JSON implementation out there 15:51:50 Gargron: if we can make an assumption about parsing and dumping of JSON. We could just do a JSON dump to a string and sign that and we'd not have to do key sorting 15:52:18 cwebber2: you would have to do key sorting, if took the JSON into my site and my hashmap re-ordered the keys 15:52:30 q? 15:52:45 q- 15:52:57 Gargron: I'm not against sorting the keys, it shouldn't be an issue. Someone got annoyed by doing (soemthing?). 15:53:35 Gargron: you could take the json payload and encode it as base64 and send it like that but it makes troubleshooting annoying and it doesn't give you security 15:53:40 it is for diaspora and zot protos 15:54:00 cwebber2: it also has problems embedding objects. 15:54:23 cwebber2: it doesn't mesh very well with AS and you'd have to unpack the b64 encoded obj everytime 15:54:42 sandro: it seems the linked data signatures are broken 15:54:51 Gargron: it might not just be broken for us, it might be broken in general 15:55:05 Is LDS a W3C REC? 15:55:12 no 15:55:26 a-ha! so no requirement of test suite, impl interop, CR exit etc. 15:55:26 cwebber2: I was going to file an issue. schema.org grows a bunch too. There should be advice on how to mitigate it. I'll take that to the CG 15:55:28 i think it's a CG draft 15:55:44 sandro: that sounds great 15:55:47 oh boy 15:55:52 sandro: going back to extensions... do we want to switch back to them? 15:56:11 cwebber2: yes! that was a long tangent but hopefully will contextualize why adding things is hard 15:56:21 cwebber2: I don't think we can agree on a process until aaronpk is here 15:56:33 cwebber2: it seems everyone on the call agrees that we shouldn't add things willy nilly 15:57:03 cwebber2: I'd like to hear feedback on what the process should be. There are some challenges with adding things 15:57:18 like how do you experiment / incubate a term/feature? 15:57:27 cwebber2: you have a chicken and egg problem with that if you add it if people use it but then people can't use it until we add it 15:57:36 cwebber2: and how to vet things (?) 15:58:00 sandro: we could add things which are experimental e.g. it goes away after 6 months 15:58:17 I wouldn't expect any "temporary" add to actually be temporary in practice. As soon as even one implementation depends on it across servers, you're kinda stuck with it. 15:58:53 sandro: the IETF has a bunch of media types (and other registries) it has a high bar on what should add. you could add things but it took years 15:59:26 sandro: then they added a lower bar where there is a short window where there is discussion and someone has to have a principal objection or it gets added 15:59:37 sandro: I much prefer that way so we don't have people blocking things 16:00:17 +1 to Gargron standard follows real life implementations 16:00:30 Gargron: I have no experience with formal standards. I feel though that standards should follow real life applications - It seems more natural. In the theoretical environment you probably won't forsee all (?) 16:00:37 gargron ? 16:00:40 you went silent 16:00:47 cwebber2: Gargron you cut out 16:01:07 cwebber2: does everyone feel okay with an extension of 15 minutes - 30 minutes 16:01:13 oh that kind of extension 16:01:14 +1 extension 16:01:14 cwebber2: I'd be fine with 30 minutes extension 16:01:29 I have to switch to #css telcon but y'all go ahead! 16:01:47 cwebber2: lets agree on a 15 minute extension 16:01:51 cwebber2: maybe i'll scribe? 16:02:16 cwebber2: we need someone to scribe, I could but it'd be a bit goofy 16:02:28 cwebber2: sandro & cwebber2 tag team 16:02:30 scribe:cwebber2 16:02:32 :) 16:02:33 scribenick: cwebber2 16:02:35 scribe: cwebber2 16:02:45 hokay, later folks! have a good meeting 16:03:24 sandro: I think there's a distinction between allocating the name and specifying exactly what it is 16:03:49 sandro: we can allocate sharedInbox2 for someone to play around with for a while, and it may not be clear what it means, but we can eventually converge on what it means 16:03:57 sandro: name allocation is what I suggest we do easily 16:04:11 sandro: you could do that through the standards process, but we don't have to in extension/name allocation 16:05:05 Gargron: in a way I question whether the protocol needs much further development, and whether it is even very possible. the devs of signal didn't do it in a federated way because they didn't see a way to keep extending it when centralized. if we do a federated protocol with AP we have to deal with some release date and not have much change. for example I don't think there's much protocol dev with SMTP and IMAP 16:05:52 sandro: I absolutely understand; to oversimplify it I think there's an experimental or dev stage, and someone says "I'm going to play with this, do all the changes, and people should change my lead" and then at some point when they're done it's frozen, which is comperable with going to rec in w3c standard 16:06:22 Gargron: if we're Mastodon and with AP stuff and it changes, there still may be some older versions around. if we can't solve the accountability problem between versions and signatures that's how it's going to be 16:06:37 Gargron: that's the main problem with keeping federated protocols changing 16:06:40 scribe: sandro 16:06:51 cwebber2: I agree it's challenging to change after release 16:07:04 .. we can make changes if there's a reasonably graceful fallback 16:07:24 .. like render with minimal understanding, you know what name propertuy means, what content property means. A 16:07:37 .. a new type, that's not understaood, but fallback works 16:07:47 .. we've talked about this a lot in the WG 16:07:58 .. that's one way in which extensions can be possible while having reasonable fallback 16:08:08 .. one way to pull that off, with allocating terms temporarilty 16:08:12 {"@context": ["https://www.w3.org/ns/activitystreams", 16:08:12 {"sensitive": "as:sensitive"}]} 16:08:13 [Amy Guy] ActivityStreams 2.0 Terms 16:08:37 .. so when eg sensitive is being played with by mastodon 16:08:50 .. so mastodon could include that bit 16:09:05 .. that's one way to possibly provide it 16:09:12 .. to avoid bugging W3C staff every time 16:09:22 scribe: cwebber 16:09:26 scribe: cwebber2 16:09:39 sandro: I don't see much advantage to that, if you have two people picking the same term there may be collision 16:09:51 sandro: if Mastodon wants to play with sensitive, Gargron can play with it until defined 16:10:42 sandro: we may need to do this hack you're describing with signatures but I don't see how its useful otherwise 16:10:53 cwebber: what about use the wiki and the hack I described 16:11:30 sandro: w3c hasn't decided what the action process is, working on it, but if not an issue I don't see the advantage over not adding to the vocab 16:11:48 [ajordan] Knowing nothing about LDS, can't you create signatures which drop e.g. properties prefixed with mastodon_? 16:11:53 cwebber: one advantage would be to not grow vocab with things you don't need 16:12:05 sandro: is there any reason not to add sensitive and Hashtag to context? 16:12:20 scribe: sandro 16:12:40 cwebber2: I think they're happening, and seem like clear sells, 16:13:11 diaspora protocol has a way to keep signatures validating even if someone adds new properties btw, not sure if that would be interesting to compare to 16:13:26 jaywink: go ahead and describe :) 16:13:40 scribe: cwebber2 16:13:45 https://diaspora.github.io/diaspora_federation/federation/magicsig.html <--- there :) 16:13:54 Gargron: I think that there's no way Hashtag and sensitive aren't going to be used 16:14:33 sandro: what terms are there that need to be written down? 16:14:51 [ajordan] To clarify what I said earlier, could you have a system that signed all the properties in a particular context? So Mastodon would generate two signatures, one for the AS2 context and one for its experimental context 16:14:51 ah no sorry, I meant the relayables signature part: https://diaspora.github.io/diaspora_federation/federation/relayable.html 16:15:14 any unknown properties you just ignore 16:15:16 huh - this concern about "updating the protocol" makes it sounds like the separation of protocol vs vocabulary is not working in practice 16:15:27 [ajordan] Other implementations would drop anything not in the Mastodon context and verify the AS2 context signature 16:15:47 that was a key point of separating the vocabulary, so we could more easily keep evolving it while the protocol itself stayed (fairly) static 16:16:55 I see it as pretty important that we continue being able to evolve vocabularies even after widespread federated heterogenous deployment of protocol implementations 16:17:34 [ajordan] tantek: who are you responding to? 16:17:46 ajordan, the previous 45 lines 16:18:04 e.g. someone deciding to post a new "donation drive" post type, to which others respond to with a new "donation" post type 16:18:24 (not theoretical, FB has this, and there's been some #indieweb discussion about how would we do this) 16:19:22 Gargron: we had bad experiences with tagging for sensitive type things, there was a nsfw type category, but if you use the #nsfw tag it's exactly the same as the boolean... this means that comes from the text or the category 16:19:39 isn 16:19:41 (sorry) 16:20:04 't this also for "spoilers" like stuff too? like if you post about GoT finale right away? 16:20:20 sandro: the WG isn't saying it shouldn't be done, and WG doesn't say they know the right solution, saying it's an extension 16:20:21 we do spoilers by using summary vs content 16:20:49 does 'sensitive' mean the summary is sensitive or the content or both? 16:21:04 usually it means the attached media should not be displayed straight away 16:21:16 clients can implement this differently though. 16:21:26 cwebber: I'm not saying that we're not doing sensitive as an extension, just trying to clarify 16:21:32 just media? not just potentially abusive / profane / sacrilegious text¿ 16:21:47 https://www.w3.org/wiki/Activity_Streams_extensions#sensitive_property 16:22:21 "viewing its content" so content, not summary. and could also be text, not just media 16:22:30 is that the intention of this feature? 16:22:53 Gargron: I gave my ok on these. I have gotten some bad feedback from NSFW so maybe exclude the mention of nsfw because it may have some problems. maybe say that it MAY apply to both text and images or just images (media?) 16:23:06 Gargron: the point is that the content doesn't need to be displayed right away is the only core element of this property 16:23:46 does it mean the author has marked the content as sensitive? the provider/server? or other users? 16:23:56 cwebber2: I understand the controversay for NSFW, and agree, but I think some people wont find this unless it's mentioned there. 16:24:16 tantek: it doesn't carry that sorta information. only how, not why. 16:24:19 sandro: I agree that's important 16:24:22 do any systems have a "mark sensitive" button? 16:24:34 for a reader to mark someone else's post as 'sensitive' ? 16:24:40 or 'trigger-warning' ? 16:24:49 for a reader - no. admins can enforce it however. 16:25:00 I agree with Gargron of dropping "NSFW" from the sensitive description 16:25:22 would you consider adding "trigger warning" to the "due to ... " list? 16:25:47 I feel like I've seen that used enough in practice that it's worthy of mentioning 16:25:54 and shows sensitivity (so to speak) to that use-case 16:25:56 cwebber2: tantek: what I said on the call is I agree with not having it be the name, I added it because NSFW is so common someone might not know they should use sensitive instead and invent a nsfw tab 16:25:57 tag 16:25:59 i believe that being so specific is not necessary. with a bit of abstraction, "summary" can be the trigger warning/spoiler warning/actual summary of the content 16:26:07 trackbot, end meeting 16:26:07 Zakim, list attendees 16:26:07 As of this point the attendees have been tantek, Gargron, tsyesika, cwebber, jaywink, unarist 16:26:15 RRSAgent, please draft minutes 16:26:15 I have made the request to generate http://www.w3.org/2017/08/30-social-minutes.html trackbot 16:26:16 RRSAgent, bye 16:26:16 I see no action items