Social Web Working Group Teleconference

14 Feb 2018

Attendees

Present: ajordan, aaronpk, cwebber, eprodrom, ben_thatmustbeme, bengo, rhiaro, sandro, cwebber2
Regrets
Chair: cwebber2
Scribe: bengo, cwebber2

cwebber2: first major topic: ActivityStreams 2.0 @context, specifically the growth of the context
... Why don't I frame the issue as it stands. Others can join in and correct me if I miss something.
... Effectively, AS2 is being used as the primary vocabulary for ActivityPub
... And for extensions. We have a couple extensions so far. In SocialWG we agreed to hand off extension process to the CG>
... To give backstory. One of the discussions in SocialCG awhile ago (not with everyone here), is "How should we handle extensions". What we agreed at the time (sandro to confirm): We'd have a fairly lax process.
... Wiki page to register extensions people want to work on. Discuss in SocailCG. Once the extension is put into use, we'd document it and put in the AS2 @context
... But documentation for that specific term would be on the wiki pages.

sandro: Sounds right

cwebber2: Something else happening around that time... for the sake of preserving the integrity of messages on the network, servers wanted ability to know messages came from who it says. So Linked Data Signatures adopted by Mastodon.
... We were looking at the extensions as append-only. But the challenge was: Mastodon would cache the @context at build time of release, so if there was an older version of mastodon with older @context, and new version comes out with new @context/extension, the challenge was that the old server would actually see the new message and think the sig was invalid
... because when doing the normalization of the document, there would be that extension property in the context, so it wouldn't put it in the normalized linked data
... So at that point, sandro volunteered to freeze the @context at every time we added terms to the vocabulary.

<cwebber2> https://github.com/w3c-dvcg/ld-signatures/issues/9#issuecomment-326720082

<Loqi> [sandhawke] I've now implemented this so people can experiment:

<Loqi> https://www.w3.org/ns/activitystreams-history/

<Loqi> contains all (eight so far) versions of the jsonld version of the namespace document, with cache control max-age 1 year.

<Loqi> It's generated by a s...

sandro: I wrote a tiny script to expose each version in the context at a nice URL

<cwebber2> https://www.w3.org/ns/activitystreams-history/

sandro: CVS. But like any VCS, I just wrote a script to publish each tag in the VCS at a diff URL

cwebber2: There is output of that script. As you can see, there are two optional URLs for each. Via either the semantic-ish version or via the hash
... note we're not the only group thinking about this. JSON-LD mailing list too.
... It's not a problem if you just don't know what a term is. But it is a problem for signatures.

<eprodrom> "context"

cwebber2: So let's fast-forward to last meeting. Versioning got mentioned. Evan?

<ajordan> eprodrom: I was literally JUST thinking that

cwebber2: There may be concern that the vocabulary itself is versioned, but I intended just the @context document to be versioned.
... Do we even want the AS2 @context and vocab to change often? or rare?

<sandro> +1 whole summary cwebber2

<ajordan> eprodrom: link to what you're reading?

eprodrom: Hi! Let me just quote from AS2 spec (reads from spec that says to use a specific string as @context)
... It's a SHOULD
... What we are apparently now recommending is people should use *some other* URL as the @context. I think that that is a bad idea
... Especially if we are going to have multiple @context strings on our networks.
... Developers now have to look for not 1 string, but many. I think that is a problem.

<ajordan> https://www.w3.org/TR/activitystreams-core/#jsonld?

eprodrom: It means that people looking for AS2 documents are now finding other things.
... I am co-author of this document and had no idea about these version strings. They are undocumented things.
... The likely thing is that developers will not do that. They will copy what they find in Mastodon. I think we ahve a few different options here
... one is documenting this versioning process. And do so in a way that minimizes chaos on the network
... Or we can not do version strings, and commit to doing single @context strings, with the problems that that might cause.
... And figure out something else [for signatures?]
... I do not think that generating multiple @context strings based on version with minor additive changes is an effective way to do this.

sandro: I agree with what Evan said, makes sense. When I set this up it was as an urgent experiment for Mastodon.
... It was just to try it out. So far, it's working, it seems. I don't know first-hand. Maybe cwebber2 knows.

<ajordan> sandro: by what definition of working

sandro: In some ways this is a truce between just-JSON and LD folks.
... And just-JSON people won't be doing Linked Data Signatures
... In the LD world you would never just compare strings, you would dereference things first

eprodrom: Yeah but this is a SHOULD, and we're sort of saying 'ignore that SHOULD' because now we're doing this new thing to support LDS
... It seems to me like we can do 1 of 3 things
... 1) Throw out this SHOULD
... 2) Throw out supporting LDS
... 3) Throw out adding extensions to @context

+1 3

<cwebber2> there's one more, which is something ajordan suggested last meeting

eprodrom: I would vastly support throwing out LDS
... After that, the next best option is #3 since we have production code that would not like #2

sandro: SHOULD is 'do this unless you have a good reason to do something else'.
... I see LDS as a good reason. LDS trumps the SHOUDL

<eprodrom> HODL

smh

cwebber2: It might be worth looking at what Mastodon is actually doing

<eprodrom> +1

<cwebber2> http://sebsauvage.net/paste/?0e250b0818ce23ad#XdHVaPzEzdU0WgBrNZKi4IR3VG3p7Axj0f4u9JcX2OI=

cwebber2: Here is a paste of an actual AS2 option
... In Mastodon
... Mastodon not even using these versioned strings for @context

<ajordan> ping Gargron

cwebber2: They've just been adding to the context themselves.
... They've been adding their own extensions in the @context *object*, not string.
... I don't think it's a good long term option
... ajordan has another option
... As I understand it, option #4 is that we recommend @contexts are shipped and have an effective time-to-live before we recommend they update them
... We can do via HTTP Headers
... It adds one more thing that applications might have to put on a scheduler. And that may be too much

<ajordan> I'd like to respond, I have a lot of comments

cwebber2: option #5: If it's distasteful to put extensions in the AS2 @context, maybe we could have an extensions-specific vocabulary.
... (and @context). And if you want to hang out in extension world, use that, or respect the TTL

ajordan: awesome static

<ajordan> hold on

<ajordan> IRC it is

<ajordan> so

<ajordan> 1) sandro's remark about only LD people caring about LDS strikes me as incorrect

<ajordan> because you can still have plain JSON consumers on the AP network who basically shove all the LD/LDS stuff into a corner and never touch it because there are Grues

sandro: I was oversimplifying slightly. My main point was you can't do LDS without a JSON-LD parser

<ajordan> sandro: yes that's true BUT

<ajordan> if you're relying on recognizing AS2 documents by the @context in plain JSON

<ajordan> your LDS will work fine

<ajordan> but it may never reach that part of the code because you don't recognize the @context!

<ajordan> yeah

<ajordan> sorry I'm slow typing

<ajordan> anyway 2)

<ajordan> you don't need a scheduler to require refreshes of the AS2 context

<ajordan> because you only need to refresh it if LDS validation fails

good point

<ajordan> who cares if you have an out-of-date context if the signature matches

<ajordan> so all you have to do is refetch *if* the signature fails AND *if* your cache is out of date

<ajordan> you can just do that in-band during a request-response cycle

<sandro> *AND* if the CG adds things quickly whenever anyone needs them

<ajordan> yeah

<ajordan> sure

<ajordan> whatever works

eprodrom: The advantage of adding extensions to same @context that we keep using is that it's always the same 'thing'. 'thing' means same URL.
... If we produce different URls, there is not the same advantage of adding to same context
... By doing versioned context strings, we lose any advantage of adding extensions to that @context
... It would be nice if mastodon did things differently (no versioned context strings?).

<ajordan> btw my third thing was a strawman proposal that I think might make everyone happy

<cwebber2> ajordan: make that proposal!

eprodrom: I don't think we should recommend versioned context strings

sandro: I'm just suggesting in the rare case you are doing LDS

<ajordan> cwebber2: you want me to just dump it while other people are talking?

eprodrom: MAYBE if we did it with downsides called out

<cwebber2> ajordan: yes

<sandro> +1

<cwebber2> ajordan: I'll read it out

<ajordan_> cwebber2: great

eprodrom: We're in a bad place if we stray into folk specifications

<ajordan_> okay so basically here it is:

cwebber2: Let's see what aj has

<sandro> PROPOSED: add to https://www.w3.org/ns/activitystreams-history/ an explanation that this is pretty much only for LDS

eprodrom: So far aj seems like his proposals will just change mastodon. Do we have power/levers to do that?
... e.g. members here could give PRs to mastodon

<ajordan_> extensions go into individual @context documents that are pushed out pretty quick by the CG and considered experimental. everyone gets to reference those in their @contexts to ensure that LDS works. once things stabilize we can add that into the AS2 context

sandro: It would be great to find what works for mastodon. What would largely address your concern if the history document to say it's required for LDS

<BanjoFox> Well... Aardwolf is going to be doing a Mastodon-like implementation. I imagine that Rustodon will be doing the same.

<ajordan_> but people can keep referencing the old "individual" @context while the network refreshes the main @context

<ajordan_> so LDS always works

<ajordan_> but eventually you can drop the "individual" extension @context

sandro: As soon as they do change, LDS breaks.

<ajordan_> wut

<cwebber2> scribe: bengo

<ajordan_> sandro: are you telling me that you can't append to the @context without breaking LDS?

<cwebber2> scribe: cwebber2

<ajordan_> not modify, append

<eprodrom> +1

<sandro> -1 that's an anti-pattern

bengo: I was going to mostly suggest what ajordan_ has done, though I think let's look at what Mastodon has done which is add their own context items, do extensions at other URLs, that's what linked data is all about IMO. If an extension is used for a year or two years, that can fold into AS2 extensions
... I like the idea that this is what linked data is for, and the cost is mostly larger documents which there are ways to get around things, and I want to support what ajordan_ is saying. I also am coming from a place of my own implementation, and I don't think versioned contexts is the way to go
... I do have an implementation that does linked data things for certain things but not for others

sandro: so you're consuming content which has signatures you're supposed to check, but you aren't checking them?

bengo: true but I'm not sure you're supposed to check the signature

sandro: I'm not sure but I think if there are signatures and others aren't checking them that opens vulnerabilities

bengo: it doesn't apply much to my mostly-anonymous implementation, but it's a good check I'll review

sandro: going back to your previous point of develop extensions elsewhere, then eventually pull things in to vocabularies... that was the original vision for the semantic web and it didn't happen. the reason it failed is you move it into another place then people become dependent on *that* namespace, then you can't move it. You can't move things in RDF, you can't move a vocabulary. so the solution seems to be having fairly appendable vocabularies

bengo: or don't move things

<bengo> scribenick: bengo

<cwebber2> sandro: yes but then you end up with like 20 namespaces at the top of the document, which seems not what you want... we want one AS2 context and keep it simple. this happens in turtle documents for instance and it's a pain

<cwebber2> acj

eprodrom: I'd liek to propose that we document the versioned context strings, how they can be used, and what the downsides are
... if we see a lot of implementations using those version strings, and there are a lot of those strings, then we can address that problem

<sandro> +1

cwebber2: I agree with document what we're doing. But in a certain sense we don't know what we're doing.
... We made these URLs for one reason, and they aren't even being used.
... And the current thing being done by Mastodon is different. We don't know what they want.
... Let's look at the proposals
... #1) Keep extending AS2 document. And publish versioned URLs alongside.

<eprodrom> Expires: header?

cwebber2: #2) Extend @context and vocabulary, but we suggest a TTL. And to refresh during conditions ajordan_ described: when signature failed and your context is old

<ajordan_> actually I'll just ask now since I'm IRC anyway

cwebber2: #3) Let's add extensions outside of AS2 @context. Put them in as sandro said 'the original semantic web vision' which sandro says is a pain point. And later we can maybe fold things in

<sandro> PROPOSAL-1: keep extending AS2 document and have versioned snapshots

<sandro> PROPOSAL-2: extend context/vocab, and use TTL or sig-failing as a trigger to refresh

<sandro> PROPOSAL-3: put extensions at at other URLs

cwebber2: Am I missing something?
... Any corrections?

<Zakim> sandro, you wanted to say yes let's document, can we brainstorm all the places that documentation needs to mentioned?

sandro: I don't think proposal #2 works. It still breaks.

(can you verify old signatures with #2)?

<cwebber2> bengo, you should be able to, if it's append only

<ajordan_> I was assuming we would encourage the TTL thing. since consumers would be refetching the main AS2 context we'd be able to drop "individual" contexts eventually

cwebber2: Anything other than append-only would be bad.

<ajordan_> ^^^ about my strawman

<ajordan_> "since consumers would be refetching" meaning LD consumers

<ajordan_> and plain JSON consumers wouldn't care

sandro: Does signature include namespace doc or @context?

cwebber2: expanded to URIs first. Full-quads.

sandro: But the only things signed are the triples sent to you

cwebber2: So let's say you have a fresh AS2 doc before any of this was added. It should work because you're not using any next context terms.

sandro: So why didn't mastodon do it? (refresh when you get a bad signature)

cwebber2: It might not have been suggested

sandro: I think we did, but don't remember what happened

cwebber2: For mastodon specifically they were bundling at build-time.
... idk if they would be willing to change their behavior. They have new opinions since they've had a growing @context
... reads ajordan last few chats

<eprodrom> I'm -1 on #2 also

<ajordan_> thx cwebber2 :P

<eprodrom> Do we need to keep discussing it?

<Zakim> ajordan_, you wanted to clarify sandro's issue with my strawman

<ajordan_> that was it

<eprodrom> https://gitlab.com/snippets/1698865

eprodrom: First of all, I want to make sure I absolutely understand the problem.
... I want to make sure, cwebber2, are you saying if the document at that @context URL changes, would the signature be different?

cwebber2: No because it doesn't use an extension

eprodrom: Will you make an example where the sigs would change?

cwebber2: yes I'll do in IRC

<cwebber2> {"@context": "https://www.w3.org/ns/activitystreams", "id": "https://example.com/evanp", "type": "Person", "noBots": true}

<Loqi> [Amy Guy] ActivityStreams 2.0 Terms

cwebber2: So let's say you wanted to use the extension to disallow bots. That's a new term. And let's say two versions of mastodon et al that use AS2
... New version of smilodon comes out after `noBots` was added. Old version on server A, new on server B.
... Old server tries to expand above document using it's old context, so it drops noBots. So when the graph is signed, it doesn't have the noBots term in it
... If sig is generated with context that DOES have nobots, the signature would be different

eprodrom: Wouldn't it resolve to _:noBots?
... Not omitted

cwebber2: oh yes
... Because AS2 has default context

eprodrom: If we used a versioned context. Then they'd get the correct expansion for noBots?

cwebber2: correct

sandro: No one should ever sign a document that is not in the context

cwebber2: It would fail previously, but maybe not the case now that we have an '_' in there.

(I failed to scribe the details there)

eprodrom: It seems like best practice is to update the @context document. Shipping past @contexts that never get updates is a bad idea. That's great guidance!
... It's also something completely out of our control

+1

eprodrom: yes I -1'd propsal #2 earlier since it's out of our control
... They aren't using caching correctly. That's why they get this problem. They're just not doing it right

cwebber2: An alternate suggestion: when this happens, is it severe?
... Next agenda item might help with this. If might not be that severe, or implementers may change their behavior.

eprodrom: You can always validate something that's shared by going to the `id` URL for that item and seeing if it's there.
... Private networks, things that are not accessible, TOR. There are possibilities of not being able to get it, but it's a good first step to try.
... And if you're doing LDS, you'll probably still be requesting something to get a public key
... So we may also want to publish "ways of validating things" suggestions.

<ajordan_> eprodrom: would you feel the same about us not having control if we published an official CG spec-like thing that said "this is how you do signatures on AP"? and made refetching a MUST?

<ajordan_> the point being that it would be some kind of spec we could point at instead of just a best practices thing in a wiki page or whatever

sandro: We're caught where we don't belong between LDS and Mastodon. There was failing in communication between them.

<eprodrom> sandro++

<Loqi> sandro has 56 karma in this channel (63 overall)

sandro: Seems like LDS should say "you must fetch context before failing a signature". And if Mastodon respected that, we wouldn't have this problem.
... Maybe there is a good reason to do that (e.g. embedded offline devices), but we can't know that.

<Zakim> cwebber, you wanted to do straw poll

cwebber2: Straw poll?

<sandro> PROPOSAL-1: keep extending AS2 document and have versioned snapshots

<sandro> PROPOSAL-2: extend context/vocab, and use TTL or sig-failing as a trigger to refresh

<sandro> PROPOSAL-3: put extensions at at other URLs

<eprodrom> +1

+1 it doesn't hurt to have URLs

<sandro> assume everything is well documented

<cwebber2> +1

eprodrom: (with documentation)

<sandro> PROPOSAL-1: keep extending AS2 document and have versioned snapshots

cwebber2: Let's vote on Proposal 1

(sry scribe fail)

<eprodrom> +1

+1

<sandro> +1

<cwebber2> +0.5 / +1

<sandro> (assuming it works for Mastodon, etc)

cwebber2: 0.5 because not all implementers here

<sandro> PROPOSAL-2: extend context/vocab, and use TTL or sig-failing as a trigger to refresh

cwebber2 P2

<eprodrom> -1

cwebber2 Proposal 2

<cwebber2> +0

<sandro> +1 if it works

-1

<cwebber2> +0.5

<cwebber2> scribenick: cwebber2

bengo: I'm more like a +0, I just don't think it's a whole solution

<bengo> +0 - I don't know enough about LDS

sandro: can you explain explicitly?

eprodrom: if people are doing this correctly already we wouldn't have a problem, I don't see any value in trying to have even more prescriptive mechanisms they won'tt follow

<sandro> eprodrom: people arent doing this already, can't guarantee they will in the future

<ajordan_> also I don't think we can say people aren't doing this "correctly"

<ajordan_> nobody said to refetch contexts so why would people think to do that

<bengo> -1: I dont' like mutating the document. It can lead to ambiguity when adding terms that someone was using intentionally undefined

cwebber2: just to point out I'm not sure that askign for hashes is less prescriptive

<bengo> I don't think "One context URL" is actually more gain than pain

<sandro> why would someone use an intentionally undefined term...?

<bengo> retrofitting old JSON APIs

<bengo> cwebber2: One propsal, a little goofy: We could have content-addressed @contexts. And with special #fragments with SHA-sigs of the @context

<sandro> PROPOSAL-3: put extensions at at other URLs

<bengo> cwebber2 Proposal 3

-0.5

<bengo> +1

<bengo> (this is automatically what will happen with 'beta' extensions)

-0

<sandro> -0.9 would make everyone use a messy list of URLs at the top of every document

<eprodrom> +0

<ajordan_> -0 for the proposal as listed because of sandro's ballooning @context concerns

PROPOSAL-4: {"as:noBots": true}

<ajordan_> but I think we could solve that by "migrating" stuff to the AS2 context

<ajordan_> by telling people to refetch

0

<sandro> cwebber2: Just use the CURIE approach

<bengo> -1 don't claim things in a namespace you don't govern

<eprodrom> -0 implementers can do this already

<sandro> -0.9 gives up much of niceness of AS2

<bengo> cwebber2: Most enthusiasm for versioned thing

<ajordan_> -1 breaks plain JSON if you try to change it

<bengo> eprodrom: If we talk about adding to this @context, should that be in Issues on GitHub?

<bengo> cwebber2: I have an action item saying that a git repository would be better than wiki for extensions, because issues/PRs/everything. In a way that matches other things we're doing.

<bengo> cwebber2: Only W3C members can edit w3 wikis, not all community members

<bengo> eprodrom: Can we just use existing repo for activitystreams?

<bengo> cwebber2: I'm okay with that

<bengo> sandro: I think there should be a repo per extension

<bengo> cwebber2: Sounds like similar problems to Proposal #3

<bengo> sandro: This isn't for machine-readable @context, but for discussing a new extension (human readable)

<ajordan_> cwebber2: sandro means instead of having swicg/as2-extensions we'd have swicg/as2-nobot, swicg/as2-follower-migration, etc. on GitHub

<bengo> eprodrom: I strongly feel it should be in same repo. That's where the document you're extending is.

<BanjoFox> Perhaps same repo but different branches?

<eprodrom> https://github.com/w3c/activitystreams/issues/459 <-- for example

<Loqi> [evanp] #459 Add vcard to @context

<bengo> cwebber2: I'm sold on evans suggestion. We do need one repo for discoverability reasons.

<bengo> cwebber2: If we're changing the context anyway, it might as well be in that repo

<bengo> folks can fork AS2 to develop/edit an extension, then PR back in

<ajordan_> can we give people collaborator access to the AS2 repo?

<bengo> sandro: How do I propos an extension? What are the steps?

<bengo> sandro: Make a PR? And revise my PR based on issues?

<bengo> cwebber2: Sounds like a process that implementors would already be familiar with

<bengo> eprodrom: Yeah a single property would start as an issue, then PR, discussion on PR.

<bengo> eprodrom: A whole repo for noBots seems like a lot

<sandro> NO

<bengo> eprodrom: A bigger thing with a whole new ontology: sure use a new repo. Make and develop that repo, use as separate @context string. At some point we suck it into AS2 @context.

<sandro> -1 if you use it as a separate namespace YOU CANNOT MOVE IT

<eprodrom> separate context or separate namespace?

<bengo> cwebber2: Evan has a proposal

<ajordan_> sandro: why can't you move it? if you have people refetch contexts

<bengo> cwebber2: We should notify jasnell

<sandro> You can't move the RDF namespace, because people write code & data which uses those URLs

<bengo> HTTP 30x

<eprodrom> sandro: but context and namespace are not the same, right?

PROPOSED: Discuss and curate ActivityStreams extensions in the ActivityStreams git(hub) repository, with normal issues / PRs, etc

+1

tantek: )

<bengo> +1 for extensions developed by CG. Also supportive of extensions outside the CG in diff repos

<bengo> Maybe W3C IT will learn to maintain a scalable web service after 20 years

<bengo> while true; curl tantek.com/micropub; done

<bengo> cwebber2: I want the CG to be welcoming. That should be a priority

<sandro> +1 assuming we keep it as welcoming as possible

<eprodrom> +1

<bengo> cwebber2: Sounds resolved?

<ajordan_> -0

<ajordan_> not -1 but I just don't like the "you can't write to your own spec" if you have edits over a long period of time

<ajordan_> though maybe I missed something

<ajordan_> it's not the worst in the world

<ajordan_> is there a reason why we can't have a repo for extensions and just give people write access liberally?

<eprodrom> Nope

<eprodrom> Go make that

<bengo> sandro: If they want to put it in their own repo, that's fine. If they want a block of text, cool too. But they need to link from our centralized registry

<ajordan_> repeat?

<bengo> cwebber2: Is clarifying it's okay for people to write their own spec in another repo, and we link from our extension to them. Is that okay with you?

<sandro> -1 to them needing a "really good reason". It is sufficient that they want it.

<ajordan_> uhh IIUC sure

<ajordan_> +0

<bengo> cwebber2: Let's resolve this, with condition of if we see a red flag from jasnell

<bengo> cwebber2: Is that fair?

<eprodrom> Sounds good to me

<bengo> +1

<ajordan_> I don't quite understand what's going on but it doesn't matter a huge amount and your proposal seems better so

<ajordan_> let's do it

RESOLVED (pending acceptance from jasnell): Discuss and curate ActivityStreams extensions in the ActivityStreams git(hub) repository, with normal issues / PRs, etc

<bengo> cwebber2: Bumping last agenda item to next week.

<eprodrom> sandro: can we chat for a couple of seconds?

<bengo> sandro: Are you writing something chris?

<eprodrom> That was my question!

<bengo> cwebber2: Making new git repo?

<bengo> cwebber2: I'll make a PR and jasnell can sign off

<bengo> bye

<ajordan_> bye, thanks all

<eprodrom> What new git repo?

trackbot, end meeting

eprodrom: not a new git repo

same git repo

<scribe> new PR

<bengo> (I could have mis-scribed)

Summary of Action Items

Summary of Resolutions

RESOLVED (pending acceptance from jasnell): Discuss and curate ActivityStreams extensions in the ActivityStreams git(hub) repository, with normal issues / PRs, etc

SocialCG/2018-02-14/minutes

Social Web Working Group Teleconference

14 Feb 2018

Attendees

Contents

Summary of Action Items

Summary of Resolutions