Social Web Working Group Teleconference -- 30 Aug 2017

<tsyesika> I can scribe

<cwebber2> scribe: tsyesika

now, how do i do this scribenick thing

ah!

<cwebber2> scribenick: tsyesika

cwebber2: The first thing on the agenda is updating what happened in the Social WG

<jaywink> (kind of, watching over kids at the same time)

<Gargron> unarist: type "present+"

cwebber2: this week we agreed to push another ActivityPub CR
... it has some of the changes we've discussed in the group, specifically around follow having explicit accept and reject
... as well as moving the publicInbox over to the sharedInbox
... Another thing we discussed, we need aaronpk to come to a conclusion is discussing extensions
... 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
... the other extension is the tag type

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

<Loqi> [cwebber] #231 "Sensitive Media" tag

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

<Loqi> [cwebber] #235 Add a Tag type

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

<tantek> I'm still confused on what is the difference between a "tag" type and a "hashtag" type. Or are they the same?

<Gargron> same

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?)
... 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
... those places on the wiki should be updated to "hashtag"

<cwebber2> https://www.w3.org/wiki/Activity_Streams_extensions#sensitive_property

cwebber2: I fleshed out the wikipages, linked above

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

<cwebber2> https://www.w3.org/wiki/Activity_Streams_extensions#Hashag_type

<Gargron> tantek: ActivityPub has "tag" property which, like you say, is an array of mentions, categories, locations, whatever. But FB also has "hashtags"

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

<sandro> (that makes no sense to me)

cwebber2: mastodon is using linked data signatures

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
... to verify signatures you need to download the context so basically you either need to DDOS the single context server or cache it

<tantek> I think we agreed to only adding to the context document IIRC. Or was it AS2 vocab that we agreed to only grow?

Gargron: the problem with the context changing is the signatures will change if the context changes

<tantek> wow Sandro sounds so much better on Mumble than on Webex. so much more human

sandro: we only add terms to the context, (terms may be deprecated but they'll still exist)
... this would be a problem when someone uses the new term and sends it to someone who hasn't picked up the new term

Gargron: the problem is that it'll invalidate the signature

sandro: systems ought to if there is an invalid context - they should reload the context

<cwebber2> {"@context": ["https://www.w3.org/ns/activitystreams",

<cwebber2> {"sensitive": "as:sensitive"}]}

<Loqi> [Amy Guy] ActivityStreams 2.0 Terms

<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 :)

cwebber2: I've got one suggestion: it might mitigate the issue (paste coming on IRC)
... you could have a transitional version when a new property is added to inform older versions of the software
... if you look at the context put in IRC it also specifies that the sensitive property is under the AS context
... then when you're 3 versions ahead you can drop it

sandro: I think the right thing to do is to cache the context for around 6 hours (good enough to avoid DDOS problem)
... if it started to become a problem w3c could change the cache header

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.
... it's a central point of failure. caching for 6 hours is a solution but it's not perfect
... 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

sandro: a practical solution is we'll add the terms weeks before it'll be expected to be used

<tantek> I'd expect independent implementations to experiment with new properties before they're even publicly discussed, much less added to a centralized context

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

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?

Gargron: yes that'd still be a problem

<Gargron> jaywink: thats what we do right now

cwebber2: I think the centralisation problem can't be totally solved with something which relies on DNS authority.

sandro: what if we do it expanded all the time

cwebber2: it'd be a big payload
... also if someone is using more naive tooling which might only assume it's just JSON

Gargron: We're not actually obligated to use the conicalize algorithm included in the linked data document
... 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

<Gargron> canonicalize

<sandro> +1 verbatim signature approach sounds promising

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

<xmpp-social> [ajordan] s/json snell/jason snell/

Gargron: the problem is I don't know everything about every JSON implementation out there
... 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

cwebber2: you would have to do key sorting, if took the JSON into my site and my hashmap re-ordered the keys

Gargron: I'm not against sorting the keys, it shouldn't be an issue. Someone got annoyed by doing (soemthing?).
... 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

<jaywink> it is for diaspora and zot protos

cwebber2: it also has problems embedding objects.
... it doesn't mesh very well with AS and you'd have to unpack the b64 encoded obj everytime

sandro: it seems the linked data signatures are broken

Gargron: it might not just be broken for us, it might be broken in general

<tantek> Is LDS a W3C REC?

<sandro> no

<tantek> a-ha! so no requirement of test suite, impl interop, CR exit etc.

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

<sandro> i think it's a CG draft

sandro: that sounds great

<tantek> oh boy

sandro: going back to extensions... do we want to switch back to them?

cwebber2: yes! that was a long tangent but hopefully will contextualize why adding things is hard
... I don't think we can agree on a process until aaronpk is here
... it seems everyone on the call agrees that we shouldn't add things willy nilly
... I'd like to hear feedback on what the process should be. There are some challenges with adding things

<tantek> like how do you experiment / incubate a term/feature?

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
... and how to vet things (?)

sandro: we could add things which are experimental e.g. it goes away after 6 months

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

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
... 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
... I much prefer that way so we don't have people blocking things

<tantek> +1 to Gargron standard follows real life implementations

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 (?)

<sandro> gargron ?

<sandro> you went silent

cwebber2: Gargron you cut out
... does everyone feel okay with an extension of 15 minutes - 30 minutes

<tantek> oh that kind of extension

<sandro> +1 extension

cwebber2: I'd be fine with 30 minutes extension

<tantek> I have to switch to #css telcon but y'all go ahead!

cwebber2: lets agree on a 15 minute extension
... maybe i'll scribe?
... we need someone to scribe, I could but it'd be a bit goofy
... sandro & cwebber2 tag team

<cwebber2> scribe:cwebber2

<tsyesika> :)

<scribe> scribenick: cwebber2

<scribe> scribe: cwebber2

<tsyesika> hokay, later folks! have a good meeting

sandro: I think there's a distinction between allocating the name and specifying exactly what it is
... 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
... name allocation is what I suggest we do easily
... you could do that through the standards process, but we don't have to in extension/name allocation

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

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

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
... that's the main problem with keeping federated protocols changing

<sandro> scribe: sandro

cwebber2: I agree it's challenging to change after release
... we can make changes if there's a reasonably graceful fallback
... like render with minimal understanding, you know what name propertuy means, what content property means. A
... a new type, that's not understaood, but fallback works
... we've talked about this a lot in the WG
... that's one way in which extensions can be possible while having reasonable fallback
... one way to pull that off, with allocating terms temporarilty

<cwebber2> {"@context": ["https://www.w3.org/ns/activitystreams",

<cwebber2> {"sensitive": "as:sensitive"}]}

<Loqi> [Amy Guy] ActivityStreams 2.0 Terms

cwebber2: so when eg sensitive is being played with by mastodon
... so mastodon could include that bit
... that's one way to possibly provide it
... to avoid bugging W3C staff every time

<cwebber2> scribe: cwebber

<cwebber2> scribe: cwebber2

sandro: I don't see much advantage to that, if you have two people picking the same term there may be collision
... if Mastodon wants to play with sensitive, Gargron can play with it until defined
... we may need to do this hack you're describing with signatures but I don't see how its useful otherwise

cwebber: what about use the wiki and the hack I described

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

<xmpp-social> [ajordan] Knowing nothing about LDS, can't you create signatures which drop e.g. properties prefixed with mastodon_?

cwebber: one advantage would be to not grow vocab with things you don't need

sandro: is there any reason not to add sensitive and Hashtag to context?

<sandro> scribe: sandro

cwebber2: I think they're happening, and seem like clear sells,

<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

<cwebber2> jaywink: go ahead and describe :)

<cwebber2> scribe: cwebber2

<jaywink> https://diaspora.github.io/diaspora_federation/federation/magicsig.html <--- there :)

Gargron: I think that there's no way Hashtag and sensitive aren't going to be used

sandro: what terms are there that need to be written down?

<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

<jaywink> ah no sorry, I meant the relayables signature part: https://diaspora.github.io/diaspora_federation/federation/relayable.html

<jaywink> any unknown properties you just ignore

<tantek> huh - this concern about "updating the protocol" makes it sounds like the separation of protocol vs vocabulary is not working in practice

<xmpp-social> [ajordan] Other implementations would drop anything not in the Mastodon context and verify the AS2 context signature

<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

<tantek> I see it as pretty important that we continue being able to evolve vocabularies even after widespread federated heterogenous deployment of protocol implementations

<xmpp-social> [ajordan] tantek: who are you responding to?

<tantek> ajordan, the previous 45 lines

<tantek> e.g. someone deciding to post a new "donation drive" post type, to which others respond to with a new "donation" post type

<tantek> (not theoretical, FB has this, and there's been some #indieweb discussion about how would we do this)

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

<tantek> isn

<Gargron> (sorry)

<tantek> 't this also for "spoilers" like stuff too? like if you post about GoT finale right away?

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

<Gargron> we do spoilers by using summary vs content

<tantek> does 'sensitive' mean the summary is sensitive or the content or both?

<Gargron> usually it means the attached media should not be displayed straight away

<Gargron> clients can implement this differently though.

cwebber: I'm not saying that we're not doing sensitive as an extension, just trying to clarify

<tantek> just media? not just potentially abusive / profane / sacrilegious text¿

https://www.w3.org/wiki/Activity_Streams_extensions#sensitive_property

<tantek> "viewing its content" so content, not summary. and could also be text, not just media

<tantek> is that the intention of this feature?

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?)
... the point is that the content doesn't need to be displayed right away is the only core element of this property

<tantek> does it mean the author has marked the content as sensitive? the provider/server? or other users?

<sandro> cwebber2: I understand the controversay for NSFW, and agree, but I think some people wont find this unless it's mentioned there.

<Gargron> tantek: it doesn't carry that sorta information. only how, not why.

<sandro> sandro: I agree that's important

<tantek> do any systems have a "mark sensitive" button?

<tantek> for a reader to mark someone else's post as 'sensitive' ?

<tantek> or 'trigger-warning' ?

<Gargron> for a reader - no. admins can enforce it however.

<tantek> I agree with Gargron of dropping "NSFW" from the sensitive description

<tantek> would you consider adding "trigger warning" to the "due to ... " list?

<tantek> I feel like I've seen that used enough in practice that it's worthy of mentioning

<tantek> and shows sensitivity (so to speak) to that use-case

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

tag

<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

trackbot, end meeting

- DRAFT -

Social Web Working Group Teleconference

30 Aug 2017

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output