16:02:04 <RRSAgent> RRSAgent has joined #social
16:02:04 <RRSAgent> logging to https://www.w3.org/2018/02/14-social-irc
16:02:06 <trackbot> RRSAgent, make logs public
16:02:09 <trackbot> Meeting: Social Web Working Group Teleconference
16:02:09 <trackbot> Date: 14 February 2018
16:02:14 <ajordan> present+
16:02:16 <cwebber2> present+
16:02:18 <bengo> present+
16:02:19 <rhiaro> present+
16:02:19 <aaronpk> pesent+
16:02:21 <aaronpk> er
16:02:22 <sandro> present+
16:02:23 <aaronpk> present+
16:02:35 <ajordan> present+ eprodrom
16:03:05 <cwebber2> chair: cwebber2
16:03:25 <cwebber2> scribenick: bengo
16:03:54 <bengo> cwebber2: why dont we get started with the agenda and main topic
16:03:55 <cdchapman> cdchapman has joined #social
16:03:57 <cwebber2> https://www.w3.org/wiki/SocialCG/2018-02-14#Topics
16:04:13 <bengo> cwebber2: first major topic: ActivityStreams 2.0 @context, specifically the growth of the context
16:04:29 <bengo> cwebber2: Why don't I frame the issue as it stands. Others can join in and correct me if I miss something.
16:04:45 <bengo> cwebber2: Effectively, AS2 is being used as the primary vocabulary for ActivityPub
16:05:06 <bengo> cwebber2: And for extensions. We have a couple extensions so far. In SocialWG we agreed to hand off extension process to the CG>
16:05:50 <bengo> cwebber2: To give backstory. One of the discussions in SocialCG awhile ago (not with everyone here), is "How should we handle extnesions". What we agreed at the time (sandro to confirm): We'd have a fairly lax process.
16:06:03 <ajordan> s/extnesions/extensions/
16:06:13 <bengo> cwebber2: 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
16:06:24 <bengo> cwebber2: But documentation for that specific term would be on the wiki pages.
16:06:29 <bengo> sandro: Sounds right
16:07:28 <bengo> 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.
16:08:05 <eprodrom> eprodrom has joined #social
16:08:40 <bengo> cwebber2: 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
16:09:04 <bengo> cwebber2: 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
16:09:26 <bengo> cwebber2: So at that point, sandro volunteered to freeze the @context at every time we added terms to the vocabulary.
16:09:47 <cwebber2> https://github.com/w3c-dvcg/ld-signatures/issues/9#issuecomment-326720082
16:09:48 <Loqi> [sandhawke] I've now implemented this so people can experiment:
16:09:48 <Loqi> https://www.w3.org/ns/activitystreams-history/
16:09:48 <Loqi> contains all (eight so far) versions of the jsonld version of the namespace document, with cache control max-age 1 year.
16:09:48 <Loqi> It's generated by a s...
16:09:48 <bengo> sandro: I wrote a tiny script to expose each version in the context at a nice URL
16:10:00 <cwebber2> https://www.w3.org/ns/activitystreams-history/
16:10:11 <bengo> sandro: CVS. But like any VCS, I just wrote a script to publish each tag in the VCS at a diff URL
16:10:38 <bengo> 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
16:10:55 <eprodrom_> eprodrom_ has joined #social
16:10:57 <bengo> cwebber2: note we're not the only group thinking about this. JSON-LD mailing list too.
16:11:14 <bengo> cwebber2: It's not a problem if you just don't know what a term is. But it is a problem for signatures.
16:11:29 <eprodrom> "context"
16:11:37 <bengo> cwebber2: So let's fast-forward to last meeting. Versioning got mentioned. Evan?
16:11:37 <ajordan> eprodrom: I was literally JUST thinking that
16:12:03 <bengo> cwebber2: There may be concern that the vocabulary itself is versioned, but I intended just the @context document to be versioned.
16:12:15 <bengo> cwebber2: Do we even want the AS2 @context and vocab to change often? or rare?
16:12:43 <sandro> +1 whole summary cwebber2
16:13:03 <ajordan> eprodrom: link to what you're reading?
16:13:07 <bengo> eprodrom: Hi! Let me just quote from AS2 spec (reads from spec that says to use a specific string as @context)
16:13:16 <bengo> eprodrom: It's a SHOULD
16:13:40 <bengo> eprodrom: What we are apparently now recommending is people should use *some other* URL as the @context. I think that that is a bad idea
16:13:52 <bengo> eprodrom: Especially if we are going to have multiple @context strings on our networks.
16:14:07 <bengo> eprodrom: Developers now have to look for not 1 string, but many. I think that is a problem.
16:14:18 <ajordan> https://www.w3.org/TR/activitystreams-core/#jsonld?
16:14:18 <bengo> eprodrom: It means that people looking for AS2 documents are now finding other things.
16:14:45 <bengo> eprodrom: I am co-author of this document and had no idea about these version strings. They are undocumented things.
16:15:05 <bengo> eprodrom: 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
16:15:17 <bengo> eprodrom: one is documenting this versioning process. And do so in a way that minimizes chaos on the network
16:15:36 <bengo> eprodrom: Or we can not do version strings, and commit to doing single @context strings, with the problems that that might cause.
16:15:43 <bengo> eprodrom: And figure out something else [for signatures?]
16:16:01 <bengo> eprodrom: I do not think that generating multiple @context strings based on version with minor additive changes is an effective way to do this.
16:16:13 <sandro> q+
16:16:16 <cwebber2> q?
16:16:23 <cwebber2> ack sandro
16:16:41 <bengo> sandro: I agree with what Evan said, makes sense. When I set this up it was as an urgent experiment for Mastodon.
16:17:05 <bengo> sandro: It was just to try it out. So far, it's working, it seems. I don't know first-hand. Maybe cwebber2 knows.
16:17:07 <eprodrom> q+
16:17:08 <cwebber2> q+
16:17:09 <ajordan> sandro: by what definition of working
16:17:31 <bengo> sandro: In some ways this is a truce between just-JSON and LD folks.
16:17:36 <ajordan> q+
16:17:46 <bengo> sandro: And just-JSON people won't be doing Linked Data Signatures
16:18:01 <bengo> sandro: In the LD world you would never just compare strings, you would dereference things first
16:18:09 <cwebber2> ack eprodrom
16:18:44 <bengo> 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
16:18:57 <bengo> eprodrom: It seems to me like we can do 1 of 3 things
16:18:59 <bengo> eprodrom: 1) Throw out this SHOUDL
16:19:05 <bengo> eprodrom: 2) Throw out supporting LDS
16:19:14 <bengo> eprodrom: 3) Throw out adding extensions to @context
16:19:15 <ajordan> s/SHOUDL/SHOULD/
16:19:16 <bengo> +1 3
16:19:21 <cwebber2> there's one more, which is something ajordan suggested last meeting
16:19:27 <bengo> eprodrom: I would vastly support throwing out LDS
16:19:52 <bengo> eprodrom: After that, the next best option is #3 since we have production code that would not like #2
16:20:03 <cwebber2> q?
16:20:14 <bengo> sandro: SHOULD is 'do this unless you have a good reason to do something else'.
16:20:22 <bengo> sandro: I see LDS as a good reason. LDS trumps the SHOUDL
16:20:30 <eprodrom> HODL
16:20:34 <bengo> smh
16:20:38 <cwebber2> ack cwebber
16:20:49 <bengo> cwebber2: It might be worth looking at what Mastodon is actually doing
16:20:54 <eprodrom> +1
16:20:57 <cwebber2> http://sebsauvage.net/paste/?0e250b0818ce23ad#XdHVaPzEzdU0WgBrNZKi4IR3VG3p7Axj0f4u9JcX2OI=
16:20:59 <bengo> cwebber2: Here is a paste of an actual AS2 option
16:21:03 <bengo> cwebber2: In Mastodon
16:21:16 <bengo> cwebber2: Mastodon not even using these versioned strings for @context
16:21:20 <ajordan> ping Gargron
16:21:38 <bengo> cwebber2: They've just been adding to the context themselves.
16:21:57 <bengo> cwebber2: They've been adding their own extensions in the @context *object*, not string.
16:22:07 <bengo> cwebber2: I don't think it's a good long term option
16:22:09 <eprodrom> q+
16:22:11 <bengo> cwebber2: ajordan has another option
16:22:45 <bengo> cwebber2: 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
16:23:09 <bengo> cwebber2: We can do via HTTP Headers
16:23:21 <bengo> cwebber2: It adds one more thing that applications might have to put on a scheduler. And that may be too much
16:23:56 <ajordan> I'd like to respond, I have a lot of comments
16:24:08 <bengo> cwebber2: option #5: If it's distasteful to put extensions in the AS2 @context, maybe we could have an extensions-specific vocabulary.
16:24:22 <bengo> cwebber2: (and @context). And if you want to hang out in extension world, use that, or respect the TTL
16:24:25 <cwebber2> ack ajordan
16:24:39 <bengo> ajordan: awesome static
16:24:41 <ajordan> hold on
16:25:06 <ajordan> IRC it is
16:25:11 <ajordan> so
16:25:56 <ajordan> 1) sandro's remark about only LD people caring about LDS strikes me as incorrect
16:26:25 <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
16:26:39 <bengo> sandro: I was oversimplifying slightly. My main point was you can't do LDS without a JSON-LD parser
16:26:39 <ajordan> sandro: yes that's true BUT
16:27:08 <ajordan> if you're relying on recognizing AS2 documents by the @context in plain JSON
16:27:20 <ajordan> your LDS will work fine
16:27:31 <ajordan> but it may never reach that part of the code because you don't recognize the @context!
16:27:40 <cwebber2> q+
16:27:52 <ajordan> yeah
16:27:56 <ajordan> sorry I'm slow typing
16:27:58 <ajordan> anyway 2)
16:28:15 <ajordan> you don't need a scheduler to require refreshes of the AS2 context
16:28:25 <ajordan> because you only need to refresh it if LDS validation fails
16:28:40 <bengo> good point
16:28:41 <ajordan> who cares if you have an out-of-date context if the signature matches
16:29:02 <ajordan> so all you have to do is refetch *if* the signature fails AND *if* your cache is out of date
16:29:15 <ajordan> you can just do that in-band during a request-response cycle
16:29:20 <sandro> *AND* if the CG adds things quickly whenever anyone needs them
16:29:27 <bengo> q+
16:29:44 <ajordan> yeah
16:29:56 <ajordan> sure
16:29:59 <ajordan> whatever works
16:30:07 <cwebber2> ack eprodrom
16:30:48 <bengo> 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.
16:31:06 <bengo> eprodrom: If we produce different URls, there is not the same advantage of adding to same context
16:31:23 <bengo> eprodrom: By doing versioned context strings, we lose any advantage of adding extensions to that @context
16:31:47 <bengo> eprodrom: It would be nice if mastodon did things differently (no versioned context strings?).
16:31:50 <ajordan> btw my third thing was a strawman proposal that I think might make everyone happy
16:32:00 <cwebber2> ajordan: make that proposal!
16:32:04 <bengo> eprodrom: I don't think we should recommend versioned context strings
16:32:22 <bengo> sandro: I'm just suggesting in the rare case you are doing LDS
16:32:27 <bengo> q?
16:32:33 <ajordan> cwebber2: you want me to just dump it while other people are talking?
16:32:39 <bengo> eprodrom: MAYBE if we did it with downsides called out
16:32:39 <cwebber2> ajordan: yes
16:32:50 <sandro> +1
16:32:52 <ajordan_> ajordan_ has joined #social
16:33:02 <cwebber2> ajordan: I'll read it out
16:33:07 <ajordan_> cwebber2: great
16:33:20 <bengo> eprodrom: We're in a bad place if we stray into folk specifications
16:33:20 <ajordan_> okay so basically here it is:
16:33:23 <cwebber2> q?
16:33:43 <bengo> cwebber2: Let's see what aj has
16:33:53 <sandro> PROPOSED: add to https://www.w3.org/ns/activitystreams-history/ an explanation that this is pretty much only for LDS
16:34:20 <bengo> eprodrom: So far aj seems like his proposals will just change mastodon. Do we have power/levers to do that?
16:34:32 <bengo> eprodrom: e.g. members here could give PRs to mastodon
16:34:36 <bengo> q?
16:34:37 <sandro> q?
16:35:04 <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
16:35:11 <bengo> 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
16:35:21 <BanjoFox> Well... Aardwolf is going to be doing a Mastodon-like implementation.  I imagine that Rustodon will be doing the same.
16:35:26 <ajordan_> but people can keep referencing the old "individual" @context while the network refreshes the main @context
16:35:41 <bengo> q?
16:35:42 <ajordan_> so LDS always works
16:35:55 <ajordan_> but eventually you can drop the "individual" extension @context
16:35:59 <bengo> sandro: As soon as they do change, LDS breaks.
16:36:10 <ajordan_> wut
16:36:16 <cwebber2> ack cwebber
16:36:18 <cwebber2> ack bengo
16:36:23 <cwebber2> scribe: bengo
16:36:28 <ajordan_> sandro: are you telling me that you can't append to the @context without breaking LDS?
16:36:30 <cwebber2> scribe: cwebber2
16:36:42 <ajordan_> not modify, append
16:36:43 <eprodrom> +1
16:37:14 <sandro> -1   that's an anti-pattern
16:37:19 <cwebber2> 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
16:37:28 <sandro> q+
16:38:18 <cwebber2> bengo: 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
16:38:46 <cwebber2> bengo: I do have an implementation that does linked data things for certain things but not for others
16:39:02 <cwebber2> sandro: so you're consuming content which has signatures you're supposed to check, but you aren't checking them?
16:39:12 <cwebber2> bengo: true but I'm not sure you're supposed to check the signature
16:39:21 <eprodrom> q+
16:39:32 <cwebber2> sandro: I'm not sure but I think if there are signatures and others aren't checking them that opens vulnerabilities
16:39:49 <cwebber2> bengo: it doesn't apply much to my mostly-anonymous implementation, but it's a good check I'll review
16:40:51 <cwebber2> 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
16:40:55 <cwebber2> bengo: or don't move things
16:41:21 <bengo> scribenick: bengo
16:41:26 <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
16:41:30 <cwebber2> q?
16:41:43 <cwebber2> ack sandro
16:41:47 <cwebber2> acj
16:41:49 <cwebber2> ack eprodrom
16:42:33 <cwebber2> q+
16:42:36 <bengo> eprodrom: I'd liek to propose that we document the versioned context strings, how they can be used, and what the downsides are
16:42:58 <sandro> q+ to say yes let's document, can we brainstorm all the places that documentation needs to mentioned?
16:43:05 <bengo> eprodrom: 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
16:43:15 <cwebber2> q?
16:43:16 <sandro> +1
16:43:18 <cwebber2> ack cwebber
16:43:36 <bengo> cwebber2: I agree with document what we're doing. But in a certain sense we don't know what we're doing.
16:44:01 <bengo> cwebber2: We made these URLs for one reason, and they aren't even being used.
16:44:30 <bengo> cwebber2: And the current thing being done by Mastodon is different. We don't know what they want.
16:44:39 <bengo> cwebber2: Let's look at the proposals
16:44:59 <bengo> cwebber2: #1) Keep extending AS2 document. And publish versioned URLs alongside.
16:45:23 <eprodrom> Expires: header?
16:45:36 <bengo> 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
16:45:39 <ajordan_> q+ to clarify sandro's issue with my strawman
16:45:58 <ajordan_> actually I'll just ask now since I'm IRC anyway
16:46:13 <bengo> 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
16:46:17 <cwebber2> q?
16:46:17 <sandro> PROPOSAL-1: keep extending AS2 document and have versioned snapshots
16:46:17 <sandro> PROPOSAL-2: extend context/vocab, and use TTL or sig-failing as a trigger to refresh
16:46:17 <sandro> PROPOSAL-3: put extensions at at other URLs
16:46:19 <bengo> cwebber2: Am I missing something?
16:46:44 <bengo> cwebber2: Any corrections?
16:46:45 <cwebber2> q+ to do straw poll
16:46:47 <cwebber2> ack sandro
16:46:48 <Zakim> sandro, you wanted to say yes let's document, can we brainstorm all the places that documentation needs to mentioned?
16:46:53 <sandro> q+ to say I don't think P-2 works
16:47:14 <eprodrom> q+
16:47:32 <bengo> sandro: I don't think proposal #2 works. It still breaks.
16:47:38 <bengo> (can you verify old signatures with #2)?
16:47:54 <cwebber2> bengo, you should be able to, if it's append only
16:48:03 <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
16:48:27 <bengo> cwebber2: Anything other than append-only would be bad.
16:48:28 <ajordan_> ^^^ about my strawman
16:48:52 <ajordan_> "since consumers would be refetching" meaning LD consumers
16:48:58 <ajordan_> and plain JSON consumers wouldn't care
16:49:14 <bengo> sandro: Does signature include namespace doc or @context?
16:49:31 <bengo> cwebber2: expanded to URIs first. Full-quads.
16:49:47 <bengo> sandro: But the only things signed are the triples sent to you
16:50:06 <bengo> 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.
16:50:23 <bengo> sandro: So why didn't mastodon do it? (refresh when you get a bad signature)
16:50:27 <bengo> cwebber2: It might not have been suggested
16:50:34 <bengo> sandro: I think we did, but don't remember what happened
16:50:42 <bengo> cwebber2: For mastodon specifically they were bundling at build-time.
16:50:59 <cwebber2> q?
16:51:00 <bengo> cwebber2: idk if they would be willing to change their behavior. They have new opinions since they've had a growing @context
16:51:11 <bengo> cwebber2: reads ajordan last few chats
16:51:18 <eprodrom> I'm -1 on #2 also
16:51:20 <ajordan_> thx cwebber2 :P
16:51:23 <cwebber2> q?
16:51:25 <eprodrom> Do we need to keep discussing it?
16:51:28 <cwebber2> ack ajordan_
16:51:28 <Zakim> ajordan_, you wanted to clarify sandro's issue with my strawman
16:51:29 <ajordan_> q-
16:51:35 <ajordan_> that was it
16:51:51 <sandro> q-
16:51:51 <cwebber2> ack sandro
16:51:58 <cwebber2> ack eprodrom
16:52:41 <eprodrom> https://gitlab.com/snippets/1698865
16:52:42 <bengo> eprodrom: First of all, I want to make sure I absolutely understand the problem.
16:53:05 <bengo> eprodrom: I want to make sure, cwebber2, are you saying if the document at that @context URL changes, would the signature be different?
16:53:29 <bengo> cwebber2: No because it doesn't use an extension
16:53:36 <bengo> eprodrom: Will you make an example where the sigs would change?
16:53:42 <bengo> cwebber2: yes I'll do in IRC
16:54:12 <cwebber2> {"@context": "https://www.w3.org/ns/activitystreams", "id": "https://example.com/evanp", "type": "Person", "noBots": true}
16:54:13 <Loqi> [Amy Guy] ActivityStreams 2.0 Terms
16:55:11 <bengo> 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
16:55:57 <bengo> cwebber2: New version of smilodon comes out after `noBots` was added. Old version on server A, new on server B.
16:56:32 <bengo> cwebber2: 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
16:56:44 <bengo> cwebber2: If sig is generated with context that DOES have nobots, the signature would be different
16:56:57 <bengo> eprodrom: Wouldn't it resolve to _:noBots?
16:56:58 <bengo> eprodrom: Not omitted
16:57:02 <bengo> cwebber2: oh yes
16:57:12 <bengo> cwebber2: Because AS2 has default context
16:58:04 <bengo> eprodrom: If we used a versioned context. Then they'd get the correct expansion for noBots?
16:58:07 <bengo> cwebber2: correct
16:58:19 <cwebber2> q?
17:00:15 <bengo> sandro: No one should ever sign a document that is not in the context
17:00:30 <bengo> cwebber2: It would fail previously, but maybe not the case now that we have an '_' in there.
17:00:40 <eprodrom> q?
17:00:41 <eprodrom> q+
17:00:52 <bengo> (I failed to scribe the details there)
17:01:01 <cwebber2> ack eprodrom
17:01:23 <bengo> 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!
17:01:30 <bengo> eprodrom: It's also something completely out of our control
17:01:31 <bengo> +1
17:01:55 <sandro> q+
17:01:58 <bengo> eprodrom: yes I -1'd propsal #2 earlier since it's out of our control
17:02:10 <bengo> eprodrom: They aren't using caching correctly. That's why they get this problem. They're just not doing it right
17:02:27 <bengo> cwebber2: An alternate suggestion: when this happens, is it severe?
17:02:32 <eprodrom> q+
17:02:50 <bengo> cwebber2: Next agenda item might help with this. If might not be that severe, or implementers may change their behavior.
17:03:10 <bengo> eprodrom: You can always validate something that's shared by going to the `id` URL for that item and seeing if it's there.
17:03:19 <tantek> tantek has joined #social
17:03:34 <bengo> eprodrom: 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.
17:03:47 <bengo> eprodrom: And if you're doing LDS, you'll probably still be requesting something to get a public key
17:03:58 <bengo> eprodrom: So we may also want to publish "ways of validating things" suggestions.
17:04:12 <cwebber2> q?
17:04:12 <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?
17:04:27 <cwebber2> ack sandro
17:04:38 <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
17:04:57 <bengo> sandro: We're caught where we don't belong between LDS and Mastodon. There was failing in communication between them.
17:05:05 <eprodrom> sandro++
17:05:06 <Loqi> sandro has 56 karma in this channel (63 overall)
17:05:13 <bengo> 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.
17:05:32 <bengo> sandro: Maybe there is a good reason to do that (e.g. embedded offline devices), but we can't know that.
17:05:45 <cwebber2> q?
17:05:47 <eprodrom> q-
17:05:51 <cwebber2> ack cwebber
17:05:51 <Zakim> cwebber, you wanted to do straw poll
17:05:54 <bengo> cwebber2: Straw poll?
17:06:05 <sandro> PROPOSAL-1: keep extending AS2 document and have versioned snapshots
17:06:05 <sandro> PROPOSAL-2: extend context/vocab, and use TTL or sig-failing as a trigger to refresh
17:06:05 <sandro> PROPOSAL-3: put extensions at at other URLs
17:06:15 <eprodrom> +1
17:06:21 <bengo> +1 it doesn't hurt to have URLs
17:06:43 <sandro> assume everything is well documented
17:06:45 <cwebber2> +1
17:06:45 <bengo> eprodrom: (with documentation)
17:07:00 <sandro> PROPOSAL-1: keep extending AS2 document and have versioned snapshots
17:07:00 <bengo> cwebber2 : Let's vote on Proposal 1
17:07:03 <bengo> (sry scribe fail)
17:07:04 <eprodrom> +1
17:07:08 <bengo> +1
17:07:09 <sandro> +1
17:07:12 <cwebber2> +0.5 / +1
17:07:30 <sandro> (assuming it works for Mastodon, etc)
17:07:32 <bengo> cwebber2: 0.5 because not all implementers here
17:07:37 <sandro> PROPOSAL-2: extend context/vocab, and use TTL or sig-failing as a trigger to refresh
17:07:39 <bengo> cwebber2 P2
17:07:41 <eprodrom> -1
17:07:42 <bengo> cwebber2 Proposal 2
17:07:43 <cwebber2> +0
17:07:44 <sandro> +1 if it works
17:07:44 <bengo> -1
17:07:49 <cwebber2> +0.5
17:08:30 <cwebber2> scribenick: cwebber2
17:08:31 <cwebber2> bengo: I'm more like a +0, I just don't think it's a whole solution
17:08:37 <bengo> +0 - I don't know enough about LDS
17:08:37 <cwebber2> sandro: can you explain explicitly?
17:08:59 <cwebber2> 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
17:09:06 <sandro> eprodrom: people arent doing this already, can't guarantee they will in the future
17:09:21 <ajordan_> also I don't think we can say people aren't doing this "correctly"
17:09:38 <ajordan_> nobody said to refetch contexts so why would people think to do that
17:09:48 <bengo> -1: I dont' like mutating the document. It can lead to ambiguity when adding terms that someone was using intentionally undefined
17:10:02 <cwebber2> cwebber2: just to point out I'm not sure that askign for hashes is less prescriptive
17:10:08 <bengo> I don't think "One context URL" is actually more gain than pain
17:10:09 <sandro> why would someone use an intentionally undefined term...?
17:10:19 <bengo> retrofitting old JSON APIs
17:10:57 <bengo> cwebber2: One propsal, a little goofy: We could have content-addressed @contexts. And with special #fragments with SHA-sigs of the @context
17:11:22 <sandro> PROPOSAL-3: put extensions at at other URLs
17:11:22 <bengo> cwebber2 Proposal 3
17:11:25 <cwebber2> -0.5
17:11:27 <bengo> +1
17:11:38 <bengo> (this is automatically what will happen with 'beta' extensions)
17:11:49 <cwebber2> -0
17:12:05 <sandro> -0.9 would make everyone use a messy list of URLs at the top of every document
17:12:14 <eprodrom> +0
17:12:37 <ajordan_> -0 for the proposal as listed because of sandro's ballooning @context concerns
17:13:11 <cwebber2> PROPOSAL-4: {"as:noBots": true}
17:13:16 <ajordan_> but I think we could solve that by "migrating" stuff to the AS2 context
17:13:31 <ajordan_> by telling people to refetch
17:13:33 <cwebber2> 0
17:13:40 <sandro> cwebber2: Just use the CURIE approach
17:13:54 <bengo> -1 don't claim things in a namespace you don't govern
17:14:00 <eprodrom> -0 implementers can do this already
17:14:00 <sandro> -0.9 gives up much of niceness of AS2
17:14:15 <bengo> cwebber2: Most enthusiasm for versioned thing
17:14:16 <eprodrom> q+
17:14:22 <ajordan_> -1 breaks plain JSON if you try to change it
17:14:27 <cwebber2> ack eprodrom
17:14:47 <bengo> eprodrom: If we talk about adding to this @context, should that be in Issues on GitHub?
17:15:19 <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.
17:15:53 <bengo> cwebber2: Only W3C members can edit w3 wikis, not all community members
17:16:07 <bengo> eprodrom: Can we just use existing repo for activitystreams?
17:16:11 <bengo> cwebber2: I'm okay with that
17:16:27 <bengo> sandro: I think there should be a repo per extension
17:16:59 <bengo> cwebber2: Sounds like similar problems to Proposal #3
17:17:15 <bengo> sandro: This isn't for machine-readable @context, but for discussing a new extension (human readable)
17:17:36 <ajordan_> cwebber2: sandro means instead of having swicg/as2-extensions we'd have swicg/as2-nobot, swicg/as2-follower-migration, etc. on GitHub
17:17:52 <bengo> eprodrom: I strongly feel it should be in same repo. That's where the document you're extending is.
17:18:08 <cwebber2> q?
17:18:09 <cwebber2> q+
17:18:14 <BanjoFox> Perhaps same repo but different branches?
17:18:20 <cwebber2> ack cwebbrer
17:18:25 <cwebber2> ack cwebber2
17:18:32 <eprodrom> https://github.com/w3c/activitystreams/issues/459 <-- for example
17:18:33 <Loqi> [evanp] #459 Add vcard to @context
17:18:48 <bengo> cwebber2: I'm sold on evans suggestion. We do need one repo for discoverability reasons.
17:18:59 <bengo> cwebber2: If we're changing the context anyway, it might as well be in that repo
17:19:09 <bengo> folks can fork AS2 to develop/edit an extension, then PR back in
17:19:14 <ajordan_> can we give people collaborator access to the AS2 repo?
17:19:22 <bengo> sandro: How do I propos an extension? What are the steps?
17:19:34 <bengo> sandro: Make a PR? And revise my PR based on issues?
17:19:57 <bengo> cwebber2: Sounds like a process that implementors would already be familiar with
17:20:16 <bengo> eprodrom: Yeah a single property would start as an issue, then PR, discussion on PR.
17:20:24 <bengo> eprodrom: A whole repo for noBots seems like a lot
17:20:58 <sandro> NO
17:21:07 <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.
17:21:11 <sandro> -1 if you use it as a separate namespace YOU CANNOT MOVE IT
17:21:24 <cwebber2> q?
17:21:26 <eprodrom> separate context or separate namespace?
17:21:54 <bengo> cwebber2: Evan has a proposal
17:22:02 <ajordan_> sandro: why can't you move it? if you have people refetch contexts
17:22:34 <bengo> cwebber2: We should notify jasnell
17:22:35 <sandro> You can't move the RDF namespace, because people write code & data which uses those URLs
17:22:42 <bengo> HTTP 30x
17:22:48 <eprodrom> sandro: but context and namespace are not the same, right?
17:23:00 <cwebber2> PROPOSED: Discuss and curate ActivityStreams extensions in the ActivityStreams git(hub) repository, with normal issues / PRs, etc
17:23:11 <cwebber2> +1
17:23:35 <cwebber2> tantek :)
17:24:22 <bengo> +1 for extensions developed by CG. Also supportive of extensions outside the CG in diff repos
17:24:52 <bengo> Maybe W3C IT will learn to maintain a scalable web service after 20 years
17:25:36 <sknebel> sknebel has joined #social
17:25:44 <bengo> while true; curl tantek.com/micropub; done
17:26:46 <bengo> cwebber2: I want the CG to be welcoming. That should be a priority
17:26:51 <sandro> +1 assuming we keep it as welcoming as possible
17:26:55 <eprodrom> +1
17:27:06 <bengo> cwebber2: Sounds resolved?
17:27:08 <ajordan_> -0
17:27:40 <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
17:27:44 <ajordan_> though maybe I missed something
17:27:48 <ajordan_> it's not the worst in the world
17:29:02 <ajordan_> is there a reason why we can't have a repo for extensions and just give people write access liberally?
17:29:18 <eprodrom> Nope
17:29:20 <eprodrom> Go make that
17:29:23 <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
17:29:36 <ajordan_> repeat?
17:29:52 <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?
17:30:03 <sandro> -1 to them needing a "really good reason".   It is sufficient that they want it.
17:30:24 <ajordan_> uhh IIUC sure
17:30:38 <tantek> tantek has changed the topic to: https://www.w3.org/wiki/SocialCG/2018-02-14  Chat Logs: https://chat.indieweb.org/social/today
17:30:59 <ajordan_> +0
17:31:17 <bengo> cwebber2: Let's resolve this, with condition of if we see a red flag from jasnell
17:31:22 <bengo> cwebber2: Is that fair?
17:31:25 <eprodrom> Sounds good to me
17:31:27 <bengo> +1
17:31:28 <ajordan_> I don't quite understand what's going on but it doesn't matter a huge amount and your proposal seems better so
17:31:38 <ajordan_> let's do it
17:31:41 <cwebber2> RESOLVED (pending acceptance from jasnell): Discuss and curate ActivityStreams extensions in the ActivityStreams git(hub) repository, with normal issues / PRs, etc
17:32:06 <bengo> cwebber2: Bumping last agenda item to next week.
17:32:16 <eprodrom> sandro: can we chat for a couple of seconds?
17:32:19 <bengo> sandro: Are you writing something chris?
17:32:20 <eprodrom> That was my question!
17:32:28 <bengo> cwebber2: Making new git repo?
17:32:37 <bengo> cwebber2: I'll make a PR and jasnell can sign off
17:32:39 <bengo> bye
17:32:45 <ajordan_> bye, thanks all
17:32:46 <eprodrom> What new git repo?
17:32:49 <cwebber2> trackbot, end meeting
17:32:49 <trackbot> Zakim, list attendees
17:32:49 <Zakim> As of this point the attendees have been ajordan, aaronpk, cwebber, eprodrom, ben_thatmustbeme, bengo, rhiaro, sandro
17:32:52 <cwebber2> eprodrom: not a new git repo
17:32:55 <cwebber2> same git repo
17:32:56 <cwebber2> new PR
17:32:57 <bengo> (I could have mis-scribed)
17:32:57 <trackbot> RRSAgent, please draft minutes
17:32:57 <RRSAgent> I have made the request to generate https://www.w3.org/2018/02/14-social-minutes.html trackbot
17:32:58 <eprodrom> I thought we just agreed to use the AS2 repo
17:32:58 <trackbot> RRSAgent, bye
17:32:58 <RRSAgent> I see no action items