IRC log of social on 2017-08-30

Timestamps are in UTC.

15:31:05 [RRSAgent]
RRSAgent has joined #social
15:31:05 [RRSAgent]
logging to http://www.w3.org/2017/08/30-social-irc
15:31:07 [trackbot]
RRSAgent, make logs public
15:31:07 [Zakim]
Zakim has joined #social
15:31:09 [trackbot]
Meeting: Social Web Working Group Teleconference
15:31:09 [trackbot]
Date: 30 August 2017
15:31:12 [tsyesika]
I can scribe
15:31:25 [cwebber2]
scribe: tsyesika
15:31:26 [tsyesika]
now, how do i do this scribenick thing
15:31:28 [tsyesika]
ah!
15:31:29 [cwebber2]
scribenick: tsyesika
15:32:01 [tantek]
present+
15:32:11 [tsyesika]
cwebber2: The first thing on the agenda is updating what happened in the Social WG
15:32:11 [Gargron]
present+
15:32:12 [tsyesika]
present+
15:32:15 [cwebber2]
present+
15:32:26 [jaywink]
present+
15:32:39 [jaywink]
(kind of, watching over kids at the same time)
15:32:54 [Gargron]
unarist: type "present+"
15:32:55 [tsyesika]
cwebber2: this week we agreed to push another ActivityPub CR
15:33:08 [unarist]
present+
15:33:11 [tsyesika]
cwebber2: it has some of the changes we've discussed in the group, specifically around follow having explicit accept and reject
15:33:19 [tsyesika]
cwebber2: as well as moving the publicInbox over to the sharedInbox
15:34:06 [tsyesika]
cwebber2: Another thing we discussed, we need aaronpk to come to a conclusion is discussing extensions
15:34:50 [tsyesika]
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 [tsyesika]
cwebber2: the other extension is the tag type
15:34:59 [cwebber2]
https://github.com/w3c/activitypub/issues/231
15:35:00 [Loqi]
[cwebber] #231 "Sensitive Media" tag
15:35:07 [cwebber2]
https://github.com/w3c/activitypub/issues/235
15:35:07 [Loqi]
[cwebber] #235 Add a Tag type
15:35:54 [tsyesika]
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 [tantek]
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 [Gargron]
same
15:36:15 [tsyesika]
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 [tsyesika]
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 [tsyesika]
cwebber2: those places on the wiki should be updated to "hashtag"
15:37:09 [cwebber2]
https://www.w3.org/wiki/Activity_Streams_extensions#sensitive_property
15:37:14 [tsyesika]
cwebber2: I fleshed out the wikipages, linked above
15:37:14 [tantek]
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 [cwebber2]
https://www.w3.org/wiki/Activity_Streams_extensions#Hashag_type
15:37:52 [Gargron]
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 [tsyesika]
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 [sandro]
(that makes no sense to me)
15:39:07 [tsyesika]
cwebber2: mastodon is using linked data signatures
15:39:57 [tsyesika]
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 [tsyesika]
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 [tantek]
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 [tsyesika]
Gargron: the problem with the context changing is the signatures will change if the context changes
15:41:18 [tantek]
wow Sandro sounds so much better on Mumble than on Webex. so much more human
15:41:35 [tsyesika]
sandro: we only add terms to the context, (terms may be deprecated but they'll still exist)
15:42:01 [tsyesika]
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 [tsyesika]
Gargron: the problem is that it'll invalidate the signature
15:42:34 [tsyesika]
sandro: systems ought to if there is an invalid context - they should reload the context
15:42:34 [cwebber2]
cwebber2 has joined #social
15:42:51 [cwebber2]
{"@context": ["https://www.w3.org/ns/activitystreams",
15:42:52 [cwebber2]
{"sensitive": "as:sensitive"}]}
15:42:52 [Loqi]
[Amy Guy] ActivityStreams 2.0 Terms
15:42:54 [tantek]
"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 [tsyesika]
cwebber2: I've got one suggestion: it might mitigate the issue (paste coming on IRC)
15:43:16 [tsyesika]
cwebber2: you could have a transitional version when a new property is added to inform older versions of the software
15:43:45 [tsyesika]
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 [tsyesika]
cwebber2: then when you're 3 versions ahead you can drop it
15:44:28 [tsyesika]
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 [tsyesika]
sandro: if it started to become a problem w3c could change the cache header
15:45:12 [tsyesika]
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 [tsyesika]
Gargron: it's a central point of failure. caching for 6 hours is a solution but it's not perfect
15:46:13 [tsyesika]
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 [tsyesika]
sandro: a practical solution is we'll add the terms weeks before it'll be expected to be used
15:46:52 [tantek]
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 [tsyesika]
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 [cwebber2]
q+
15:47:28 [tsyesika]
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 [tsyesika]
Gargron: yes that'd still be a problem
15:48:02 [Gargron]
jaywink: thats what we do right now
15:48:11 [tsyesika]
cwebber2: I think the centralisation problem can't be totally solved with something which relies on DNS authority.
15:48:20 [tsyesika]
sandro: what if we do it expanded all the time
15:48:46 [tsyesika]
cwebber2: it'd be a big payload
15:49:22 [tsyesika]
cwebber2: also if someone is using more naive tooling which might only assume it's just JSON
15:49:58 [tsyesika]
Gargron: We're not actually obligated to use the conicalize algorithm included in the linked data document
15:50:29 [tsyesika]
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 [Gargron]
canonicalize
15:50:43 [sandro]
+1 verbatim signature approach sounds promising
15:50:55 [tsyesika]
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 [xmpp-social]
[ajordan] s/json snell/jason snell/
15:51:18 [tsyesika]
Gargron: the problem is I don't know everything about every JSON implementation out there
15:51:50 [tsyesika]
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 [tsyesika]
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 [sandro]
q?
15:52:45 [cwebber2]
q-
15:52:57 [tsyesika]
Gargron: I'm not against sorting the keys, it shouldn't be an issue. Someone got annoyed by doing (soemthing?).
15:53:35 [tsyesika]
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 [jaywink]
it is for diaspora and zot protos
15:54:00 [tsyesika]
cwebber2: it also has problems embedding objects.
15:54:23 [tsyesika]
cwebber2: it doesn't mesh very well with AS and you'd have to unpack the b64 encoded obj everytime
15:54:42 [tsyesika]
sandro: it seems the linked data signatures are broken
15:54:51 [tsyesika]
Gargron: it might not just be broken for us, it might be broken in general
15:55:05 [tantek]
Is LDS a W3C REC?
15:55:12 [sandro]
no
15:55:26 [tantek]
a-ha! so no requirement of test suite, impl interop, CR exit etc.
15:55:26 [tsyesika]
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 [sandro]
i think it's a CG draft
15:55:44 [tsyesika]
sandro: that sounds great
15:55:47 [tantek]
oh boy
15:55:52 [tsyesika]
sandro: going back to extensions... do we want to switch back to them?
15:56:11 [tsyesika]
cwebber2: yes! that was a long tangent but hopefully will contextualize why adding things is hard
15:56:21 [tsyesika]
cwebber2: I don't think we can agree on a process until aaronpk is here
15:56:33 [tsyesika]
cwebber2: it seems everyone on the call agrees that we shouldn't add things willy nilly
15:57:03 [tsyesika]
cwebber2: I'd like to hear feedback on what the process should be. There are some challenges with adding things
15:57:18 [tantek]
like how do you experiment / incubate a term/feature?
15:57:27 [tsyesika]
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 [tsyesika]
cwebber2: and how to vet things (?)
15:58:00 [tsyesika]
sandro: we could add things which are experimental e.g. it goes away after 6 months
15:58:17 [tantek]
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 [tsyesika]
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 [tsyesika]
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 [tsyesika]
sandro: I much prefer that way so we don't have people blocking things
16:00:17 [tantek]
+1 to Gargron standard follows real life implementations
16:00:30 [tsyesika]
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 [sandro]
gargron ?
16:00:40 [sandro]
you went silent
16:00:47 [tsyesika]
cwebber2: Gargron you cut out
16:01:07 [tsyesika]
cwebber2: does everyone feel okay with an extension of 15 minutes - 30 minutes
16:01:13 [tantek]
oh that kind of extension
16:01:14 [sandro]
+1 extension
16:01:14 [tsyesika]
cwebber2: I'd be fine with 30 minutes extension
16:01:29 [tantek]
I have to switch to #css telcon but y'all go ahead!
16:01:47 [tsyesika]
cwebber2: lets agree on a 15 minute extension
16:01:51 [tsyesika]
cwebber2: maybe i'll scribe?
16:02:16 [tsyesika]
cwebber2: we need someone to scribe, I could but it'd be a bit goofy
16:02:28 [tsyesika]
cwebber2: sandro & cwebber2 tag team
16:02:30 [cwebber2]
scribe:cwebber2
16:02:32 [tsyesika]
:)
16:02:33 [cwebber2]
scribenick: cwebber2
16:02:35 [cwebber2]
scribe: cwebber2
16:02:45 [tsyesika]
hokay, later folks! have a good meeting
16:03:24 [cwebber2]
sandro: I think there's a distinction between allocating the name and specifying exactly what it is
16:03:49 [cwebber2]
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 [cwebber2]
sandro: name allocation is what I suggest we do easily
16:04:11 [cwebber2]
sandro: you could do that through the standards process, but we don't have to in extension/name allocation
16:05:05 [cwebber2]
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 [cwebber2]
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 [cwebber2]
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 [cwebber2]
Gargron: that's the main problem with keeping federated protocols changing
16:06:40 [sandro]
scribe: sandro
16:06:51 [sandro]
cwebber2: I agree it's challenging to change after release
16:07:04 [sandro]
.. we can make changes if there's a reasonably graceful fallback
16:07:24 [sandro]
.. like render with minimal understanding, you know what name propertuy means, what content property means. A
16:07:37 [sandro]
.. a new type, that's not understaood, but fallback works
16:07:47 [sandro]
.. we've talked about this a lot in the WG
16:07:58 [sandro]
.. that's one way in which extensions can be possible while having reasonable fallback
16:08:08 [sandro]
.. one way to pull that off, with allocating terms temporarilty
16:08:12 [cwebber2]
{"@context": ["https://www.w3.org/ns/activitystreams",
16:08:12 [cwebber2]
{"sensitive": "as:sensitive"}]}
16:08:13 [Loqi]
[Amy Guy] ActivityStreams 2.0 Terms
16:08:37 [sandro]
.. so when eg sensitive is being played with by mastodon
16:08:50 [sandro]
.. so mastodon could include that bit
16:09:05 [sandro]
.. that's one way to possibly provide it
16:09:12 [sandro]
.. to avoid bugging W3C staff every time
16:09:22 [cwebber2]
scribe: cwebber
16:09:26 [cwebber2]
scribe: cwebber2
16:09:39 [cwebber2]
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 [cwebber2]
sandro: if Mastodon wants to play with sensitive, Gargron can play with it until defined
16:10:42 [cwebber2]
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 [cwebber2]
cwebber: what about use the wiki and the hack I described
16:11:30 [cwebber2]
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 [xmpp-social]
[ajordan] Knowing nothing about LDS, can't you create signatures which drop e.g. properties prefixed with mastodon_?
16:11:53 [cwebber2]
cwebber: one advantage would be to not grow vocab with things you don't need
16:12:05 [cwebber2]
sandro: is there any reason not to add sensitive and Hashtag to context?
16:12:20 [sandro]
scribe: sandro
16:12:40 [sandro]
cwebber2: I think they're happening, and seem like clear sells,
16:13:11 [jaywink]
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 [cwebber2]
jaywink: go ahead and describe :)
16:13:40 [cwebber2]
scribe: cwebber2
16:13:45 [jaywink]
https://diaspora.github.io/diaspora_federation/federation/magicsig.html <--- there :)
16:13:54 [cwebber2]
Gargron: I think that there's no way Hashtag and sensitive aren't going to be used
16:14:33 [cwebber2]
sandro: what terms are there that need to be written down?
16:14:51 [xmpp-social]
[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 [jaywink]
ah no sorry, I meant the relayables signature part: https://diaspora.github.io/diaspora_federation/federation/relayable.html
16:15:14 [jaywink]
any unknown properties you just ignore
16:15:16 [tantek]
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 [xmpp-social]
[ajordan] Other implementations would drop anything not in the Mastodon context and verify the AS2 context signature
16:15:47 [tantek]
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 [tantek]
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 [xmpp-social]
[ajordan] tantek: who are you responding to?
16:17:46 [tantek]
ajordan, the previous 45 lines
16:18:04 [tantek]
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 [tantek]
(not theoretical, FB has this, and there's been some #indieweb discussion about how would we do this)
16:19:22 [cwebber2]
Gargron: <bad transcription> 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 [tantek]
isn
16:19:41 [Gargron]
(sorry)
16:20:04 [tantek]
't this also for "spoilers" like stuff too? like if you post about GoT finale right away?
16:20:20 [cwebber2]
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 [Gargron]
we do spoilers by using summary vs content
16:20:49 [tantek]
does 'sensitive' mean the summary is sensitive or the content or both?
16:21:04 [Gargron]
usually it means the attached media should not be displayed straight away
16:21:16 [Gargron]
clients can implement this differently though.
16:21:26 [cwebber2]
cwebber: I'm not saying that we're not doing sensitive as an extension, just trying to clarify
16:21:32 [tantek]
just media? not just potentially abusive / profane / sacrilegious text¿
16:21:47 [cwebber2]
https://www.w3.org/wiki/Activity_Streams_extensions#sensitive_property
16:22:21 [tantek]
"viewing its content" so content, not summary. and could also be text, not just media
16:22:30 [tantek]
is that the intention of this feature?
16:22:53 [cwebber2]
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 [cwebber2]
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 [tantek]
does it mean the author has marked the content as sensitive? the provider/server? or other users?
16:23:56 [sandro]
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 [Gargron]
tantek: it doesn't carry that sorta information. only how, not why.
16:24:19 [sandro]
sandro: I agree that's important
16:24:22 [tantek]
do any systems have a "mark sensitive" button?
16:24:34 [tantek]
for a reader to mark someone else's post as 'sensitive' ?
16:24:40 [tantek]
or 'trigger-warning' ?
16:24:49 [Gargron]
for a reader - no. admins can enforce it however.
16:25:00 [tantek]
I agree with Gargron of dropping "NSFW" from the sensitive description
16:25:22 [tantek]
would you consider adding "trigger warning" to the "due to ... " list?
16:25:47 [tantek]
I feel like I've seen that used enough in practice that it's worthy of mentioning
16:25:54 [tantek]
and shows sensitivity (so to speak) to that use-case
16:25:56 [cwebber2]
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 [cwebber2]
tag
16:25:59 [Gargron]
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 [cwebber2]
trackbot, end meeting
16:26:07 [trackbot]
Zakim, list attendees
16:26:07 [Zakim]
As of this point the attendees have been tantek, Gargron, tsyesika, cwebber, jaywink, unarist
16:26:15 [trackbot]
RRSAgent, please draft minutes
16:26:15 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/08/30-social-minutes.html trackbot
16:26:16 [trackbot]
RRSAgent, bye
16:26:16 [RRSAgent]
I see no action items