From W3C Wiki

Social Web Working Group Teleconference

20 Jun 2017

See also: IRC log


eprodrom, ben_thatmustbeme, sandro, cwebber, rhiaro, cwebber2


<sandro> cwebber2 ? aaronpk ?

i am on, just as i said, through hurts

no problem

<eprodrom> We'll wait for people to join until 5 min past the hour

its not really worth it

I do it from the web

under firefox i never have an issue

<cwebber2> hi

<cwebber2> I'm dialing

<cwebber2> in

yes, on linux

it used to let you rename the callers, which was helpful when i was learning names

the web app doesn't let you do that any more


<cwebber2> I could scribe during the non-AP parts

defaultscribenick: ben_thatmustbeme

yeah, i noticed that sandro



<scribe> scribenick: ben_thatmustbeme

eprodrom: we have 4 on the call, its enough to have a call, but I don't want to do binding resolutions
... cwebber2 are you in need of any?

cwebber2: its okay to not have a resolution, just need group input

eprodrom: i'd be ok with doing things like closing issues, i think thats fine

review of minutes from last week

<eprodrom> PROPOSAL accept as minutes for 13 Jun 2017 meeting

<cwebber2> oh yay rhiaro

<eprodrom> PROPOSED: accept as minutes for 13 Jun 2017 meeting

<cwebber2> +1


<Loqi> woot

<eprodrom> +1

<sandro> +1

RESOLUTION: accept as minutes for 13 Jun 2017 meeting

confirm next telcon

eprodrom: we are moving in to the summer months, so i'd like to have a meeting on the 27th, and then discuss if we are going to have an abbreviated schedule after that

<sandro> +1 meeting on 27t

<cwebber2> +1

<ben_thatmustbeme> +1

eprodrom: then I as chair, unilaterally say we are having a meeting next week

i think i owe tantek one, so I may chair that too

extension update

sandro: what i can say is that voting period ended friday, we don't know the official answer yet
... we should find out tomorrow

eprodrom: well i'm glad that we are meeting next week then


cwebber2: my estimate last week was that we would have the test suite up 2 weeks from then, and i hink i'm on track for that. We have a number of new issues i'd like to discuss, they partly came up from mastodon being very active on their implementation right now


cwebber2: we also have another implementation in progress by puckipedia, a dotnet implementation

<Loqi> [cwebber] #233 Move "do not overload" and "don't trust submitted content" to Security Considerations?

cwebber2: first lets look at issue 233
... there are 2 parts, they are SHOULD so they should be in the test suite, but they are hard to test, but the feel like they should be part of the security consideration section things

eprodrom: for me the second one is clearly a security consideration
... trusting client submitted content is an interesting way to get to it, but ...

cwebber2: yeah, the server should definitely should verify the embedded object

eprodrom: if cwebber2 submits "cwebber likes eprodrom's photo" that should be checked, but if its his own photo, thats probably okay
... there is a balance to be struck there
... but existance is definitely an issue

sandro: what about the date field?

eprodrom: thats an interesting one, we do a bunch of things like that in

sandro: there is an issue on mastodon about bulk uploading posts

if they do that, then they are backdating things, so are they falsly claiming published date?

cwebber2: you could have an updated field, but i don't think that reflects the real meaning

eprodrom: in and you mark it as a share.

<ben_thatmustbeme> getting back to what cwebber2 asked...

scribe: the first thing is not really testable

the second i feel, while security questions, is VERY testable

and i would argue should be tested

eprodrom: there is a lot in there that could be tested
... do you accept something with an actor that is not the authenticated person

cwebber2: the second can be tested to some degree, maybe we should enumerate some ways in which it should be tested

<ben_thatmustbeme> even just a few tests is fine

cwebber2: it might be some things where it intentionally does leaves parts out and replaces it with its own data
... i agree we could certainly do some tests

as to the exponential backoff is it security of is it just a note in the doc?

eprodrom: is there some other doc we could just reference?

sandro: the security consideration is that most restful apis force backoff

cwebber2: you can only force it to some degree, you could reject the requests, but you can still get ddos'ed

sandro: you should be able to handle a single dos though
... i think there is an appropriate security consideration here though

rhiaro: we don't need 100% automated test coverage, a test can be something as simple as having a checkbox and we take their word for it

cwebber2: that was the original way i was doing it, but i was getting some pushback from it being too prompty

rhiaro: whatever the shortest way is

cwebber2: the former one i would like to ...

being rewritten as proposal

<eprodrom> PROPOSED: move section on exponential backoff to security considerations, section on trusting content to security consideration with tests to close

<Loqi> [cwebber] #233 Move "do not overload" and "don't trust submitted content" to Security Considerations?

<cwebber2> +1

<sandro> +1

<rhiaro> +1

<eprodrom> +1


is this a normative change?

RESOLUTION: move section on exponential backoff to security considerations, section on trusting content to security consideration with tests to close

<Loqi> [cwebber] #233 Move "do not overload" and "don't trust submitted content" to Security Considerations?

cwebber2: it sounds like we have been agreeing that relaxing requirements is more ok than adding requirements

sandro: i don't think it matters either given our schedule
... we can't go to PR next week since we don't have the test suite out

cwebber2: next one is , mastodon has been trying pretty hard to be respectful of what people are and aren't willing to see


<Loqi> [cwebber] #232 Content Warnings

these two are interrellated

<saranix> my view on this is tags are appropriate

if you haven't seen it in mastodon, you see 'content warning explicit", etc

<saranix> ... handling as tags

cwebber2: the way it is done now using the summary field
... this is like reading a short blog post you see the shortened version of it, but expand to see the full version

<saranix> I agree with the comment that said that summary is meant for different screen realestate / UI concerns

cwebber2: i have a little bit of a concern that its a little bit of an abuse of that property
... if you have those two distinct contexts, if two servers are using them in different ways, someone might see things that they hadn't intended to see
... i had original envisioned it as a tag , but this works, but i think it still should be wrapped in another type

eprodrom: i don't understand why a tag or the context wouldn't work here
... there is no need to have backward compatibility with ostatus

cwebber2: it does need to give a clear indication that it should not be exposed by default, so i think it should have its own type on the tag
... i agree that it makes more sense to me at the moment to use a tag
... i think it would be more useful to tag multiple things at once

if you lump them all in one big text box, you can lose them

sandro: a tag should default to being show, don't show, or prompt

eprodrom: that is between you and your user agent ..
... the sender should not have to decide how the content is receieved

sandro: well thats what the tagging is
... before my client has ever seen one of these tags, ... the person who is inventing the tag, the creator would have to say 'when a server sees this for the first time' what do they do

<saranix> the tagging is semantic

<saranix> is that bad?

<saranix> sandro, is that bad?

sandro: while we are doing this, i want a 3rd option, that is an opt-in tags
... what i want to be able to do is scribe meetings on mastodon, i am going to be posting 4-500 things in an hour, i don't want them to be prompted at all

cwebber2: that is quite a bit different

sandro: but it comes into the same implementation territory

eprodrom: the way of doing that is setting up a list and limiting it to only a specific audience

sandro: and thats something people can join later?

eprodrom: exactly

cwebber2: it could apply to more things than we initially thought about.

eprodrom: movie ratings, appropriate for children, trigger warnings, there is a lot that goes in to this area, and people do a lot of non-semantic stuff, like stuffing things in to the summary. or people make the post much longer than the default wrap, like "spoiler warning" then a bunch of extra lines, etc
... finding a good way to do this is good, is good to add

cwebber2: i am in favor of tags, but if we want to get others in to it, we should get like Gargron and evenminto on the CG call and bring it up there
... i'll try to get them on tomorrow or next week to discuss this

<eprodrom> tag, warning, freetext, id

eprodrom: ideally i'd like to see something where 'this is a tag' and a warning
... either a url or some text that indicates what we are warning about

cwebber2: there are 2 issues related to this


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

cwebber2: that might be a good solution to one of them
... i think there might be a good solution for this, a specific content warning one that is just 'NSFW'

<rhiaro> do they use nsfw on japanese mastodon?

maybe 'senative media' or something like that

cwebber2: people on mastodon don't want to use NSFW anymore

but a more accurate 'sensative media'

eprodrom: .... YES
... so they don't want to use that term because for some people sex work is WORK, but...


<Loqi> [cwebber] We're thinking related to #232 there would be a common Content Warning type tag for sensitive media.

cwebber2: they seem pretty related to me, so using the same mechanism seems to make sense to me

eprodrom: where the concern comes from for me, is when we start dictating what people want to see, but its pretty useful to have that people will want to see different things
... i wonder if just having a 'content warning' tag and then the other tags after that describe what it is

sandro: i don't see how that would work

eprodrom: if i had a post on 'stephen universe', i put in a tag of type content warning,

or 'here is the content warning' and here is the other tag related to it

sandro: i don't see how i could read that as a spoiler vs trigger warning, etc

eprodrom: going in to the ontology of what content makes people uncomfortable ...

cwebber2: i think there are 2 things beeing suggested

one is marking certain tags as content warning,

sandro: spoiler warnings are definitely a thing

cwebber2: you could still handle it all with eprodrom proposal

eprodrom: do you put up police tape or police tape that says quatentine, murder, etc

cwebber2: i feel like its good for this to go to the CG as well

sandro: and some hundreds of thousands of users may have opinions about it as well

cwebber2: plus changing people over who may not like it, they may have some complaints about it

sandro: exactly why i would want to add functionality

<ben_thatmustbeme> my hands can't take much more though


<Loqi> [Gargron] #6 Hashtag representation


<Loqi> [Eugen] @cwebber i had another concern: OStatus URIs of the type;12345;foobar are not represented in ActivityPub, but present in Mastodon. How to avoid duplicates between things Mastodon sees via AP vs what it sees via OStatus?

cwebber2: the basic question is 'how you represent tags'
... what the id of a tag


cwebber2: does each server have its own tag id?


cwebber2: the way ostatus does this, is there are tag status URIs

eprodrom: there is a big section on this in the AS2 vocab
... it sounds like 'what are the identities' is the question

cwebber2: i'll bring this to the CG as well

sandro: is this 'aspect' part actually implemented yet?

cwebber2: i'm about to

sandro: they are very different from groups

cwebber2: they are just a collection of people

sandro: does that work if the server is down?

cwebber2: well, you can't do that with mailing lists

sandro: no, but you can with hashtags
... its never going to be anything more than another twitter if there is context collapse
... i don't want the person sending it to say who it goes to , but the subscriber has to opt in to it

eprodrom: i think you should probably write this up as an issue

<eprodrom> trackbot, end meeting

eprodrom: lets wrap this up

<cwebber2> ben_thatmustbeme++ for scribing YET AGAIN

<Loqi> ben_thatmustbeme has 74 karma in this channel (233 overall)

Summary of Action Items

Summary of Resolutions

  1. accept as minutes for 13 Jun 2017 meeting
  2. move section on exponential backoff to security considerations, section on trusting content to security consideration with tests to close