#social 2018-02-14
2018-02-14 UTC
timbl, rowan and bwn joined the channel
timbl, rowan and bengo joined the channel
bengo, bwn, xmpp-social, Loqi and dlongley joined the channel
timbl joined the channel
bengo and BanjoFox joined the channel
# 
bengo are socialcg telecons at 16 UTC?
# bengo or 15 (....now)
# bengo thx
# BanjoFox Cwebber said about 40 minutes from now (well 37 atm)
# bengo Cool. 7am PST was harsh
# bengo Where are you now?
# bengo Got it. Yeah big diff
# BanjoFox What are we at EST-wise now... -5 or -6GMT ... I can never seem to keep track -.-
# 
ajordan https://github.com/strugee/strugee.github.com/blob/src/src/blog/winter-break-retrospective.md apparently the current UTC offset for EST is -4
# BanjoFox Yeah I know what the local time it, but not the UTC or GMT offsets ;)
# BanjoFox Doesn't much matter I suppose :)
# BanjoFox Yep
# BanjoFox cause this is Amurika and we dont need to know about nothing outside of Localtime ;)
# BanjoFox I know.... I tried REALLY SUPER DUPER HARD not to cringe when my boss said "we live in the greatest country" ....
# BanjoFox ANYWAYS
# BanjoFox hello! and TZAG
# BanjoFox What bug?
# BanjoFox OOPS
# BanjoFox I wonder if that's because they need access to the audio device. Mumble works pretty good on Android :) I dialed in that way before.
# ajordan https://chat.indieweb.org/social/2018-02-14#t1518621318107300 we'll see how it goes
# BanjoFox LOL
# BanjoFox IIRC ... yes? I usually plug in my earbuds x.x
rowan joined the channel
# BanjoFox XD
# BanjoFox Dang... it looks like there is no "portable" version of Mumble client for Win
# BanjoFox XD
# BanjoFox waves at @rowan
# BanjoFox haha
# BanjoFox that is a pretty strong endorsement for not breaking everything ;)
# bengo is that mumble mpassword correct?
# bengo I get "password or certificate rejected"
# bengo but can see a ping and 3/100 users
# bengo nvm
# bengo EBKAC
# BanjoFox @bengo :D
# bengo I had entered the hpassword in the username field...
# bengo I put 'ben' as username and it worked
# BanjoFox oops
# BanjoFox I should dial in.. but I am already sitting down...
# BanjoFox <-- at $daygig so.... I would have to go find a conf-room to hide in XD
RRSAgent joined the channel
# 
RRSAgent logging to https://www.w3.org/2018/02/14-social-irc
# bengo present+
# bengo cwebber2: why dont we get started with the agenda and main topic
cdchapman joined the channel
# bengo cwebber2: first major topic: ActivityStreams 2.0 @context, specifically the growth of the context
# bengo cwebber2: Why don't I frame the issue as it stands. Others can join in and correct me if I miss something.
# bengo cwebber2: Effectively, AS2 is being used as the primary vocabulary for ActivityPub
# bengo cwebber2: And for extensions. We have a couple extensions so far. In SocialWG we agreed to hand off extension process to the CG>
# 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.
# 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
# bengo cwebber2: But documentation for that specific term would be on the wiki pages.
# bengo sandro: Sounds right
# 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.
eprodrom joined the channel
# 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
# 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
# bengo cwebber2: So at that point, sandro volunteered to freeze the @context at every time we added terms to the vocabulary.
# 
Loqi [sandhawke] I've now implemented this so people can experiment:
https://www.w3.org/ns/activitystreams-history/
contains all (eight so far) versions of the jsonld version of the namespace document, with cache control max-age 1 year.
It's generated by a s...
# bengo sandro: I wrote a tiny script to expose each version in the context at a nice URL
# bengo sandro: CVS. But like any VCS, I just wrote a script to publish each tag in the VCS at a diff URL
# 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
eprodrom_ joined the channel
# bengo cwebber2: note we're not the only group thinking about this. JSON-LD mailing list too.
# bengo cwebber2: It's not a problem if you just don't know what a term is. But it is a problem for signatures.
# eprodrom "context"
# bengo cwebber2: So let's fast-forward to last meeting. Versioning got mentioned. Evan?
# bengo cwebber2: There may be concern that the vocabulary itself is versioned, but I intended just the @context document to be versioned.
# bengo cwebber2: Do we even want the AS2 @context and vocab to change often? or rare?
# bengo eprodrom: Hi! Let me just quote from AS2 spec (reads from spec that says to use a specific string as @context)
# bengo eprodrom: It's a SHOULD
# 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
# bengo eprodrom: Especially if we are going to have multiple @context strings on our networks.
# bengo eprodrom: Developers now have to look for not 1 string, but many. I think that is a problem.
# bengo eprodrom: It means that people looking for AS2 documents are now finding other things.
# bengo eprodrom: I am co-author of this document and had no idea about these version strings. They are undocumented things.
# 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
# bengo eprodrom: one is documenting this versioning process. And do so in a way that minimizes chaos on the network
# bengo eprodrom: Or we can not do version strings, and commit to doing single @context strings, with the problems that that might cause.
# bengo eprodrom: And figure out something else [for signatures?]
# 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.
# bengo sandro: I agree with what Evan said, makes sense. When I set this up it was as an urgent experiment for Mastodon.
# 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.
# eprodrom q+
# bengo sandro: In some ways this is a truce between just-JSON and LD folks.
# bengo sandro: And just-JSON people won't be doing Linked Data Signatures
# bengo sandro: In the LD world you would never just compare strings, you would dereference things first
# 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
# bengo eprodrom: It seems to me like we can do 1 of 3 things
# bengo eprodrom: 1) Throw out this SHOUDL
# bengo eprodrom: 2) Throw out supporting LDS
# bengo eprodrom: 3) Throw out adding extensions to @context
# bengo +1 3
# bengo eprodrom: I would vastly support throwing out LDS
# bengo eprodrom: After that, the next best option is #3 since we have production code that would not like #2
# bengo sandro: SHOULD is 'do this unless you have a good reason to do something else'.
# bengo sandro: I see LDS as a good reason. LDS trumps the SHOUDL
# eprodrom HODL
# bengo smh
# bengo cwebber2: It might be worth looking at what Mastodon is actually doing
# eprodrom +1
# bengo cwebber2: Here is a paste of an actual AS2 option
# bengo cwebber2: In Mastodon
# bengo cwebber2: Mastodon not even using these versioned strings for @context
# bengo cwebber2: They've just been adding to the context themselves.
# bengo cwebber2: They've been adding their own extensions in the @context *object*, not string.
# bengo cwebber2: I don't think it's a good long term option
# eprodrom q+
# bengo cwebber2: ajordan has another option
# 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
# bengo cwebber2: We can do via HTTP Headers
# bengo cwebber2: It adds one more thing that applications might have to put on a scheduler. And that may be too much
# bengo cwebber2: option #5: If it's distasteful to put extensions in the AS2 @context, maybe we could have an extensions-specific vocabulary.
# bengo cwebber2: (and @context). And if you want to hang out in extension world, use that, or respect the TTL
# bengo ajordan: awesome static
# bengo sandro: I was oversimplifying slightly. My main point was you can't do LDS without a JSON-LD parser
# bengo good point
# bengo q+
# 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.
# bengo eprodrom: If we produce different URls, there is not the same advantage of adding to same context
# bengo eprodrom: By doing versioned context strings, we lose any advantage of adding extensions to that @context
# bengo eprodrom: It would be nice if mastodon did things differently (no versioned context strings?).
# bengo eprodrom: I don't think we should recommend versioned context strings
# bengo sandro: I'm just suggesting in the rare case you are doing LDS
# bengo q?
# bengo eprodrom: MAYBE if we did it with downsides called out
ajordan_ joined the channel
# bengo eprodrom: We're in a bad place if we stray into folk specifications
# bengo 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
# bengo eprodrom: So far aj seems like his proposals will just change mastodon. Do we have power/levers to do that?
# bengo eprodrom: e.g. members here could give PRs to mastodon
# bengo q?
# 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
# BanjoFox Well... Aardwolf is going to be doing a Mastodon-like implementation. I imagine that Rustodon will be doing the same.
# bengo q?
# bengo sandro: As soon as they do change, LDS breaks.
# eprodrom +1
# 
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
# 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
# eprodrom q+
# 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
# bengo scribenick: bengo
# bengo eprodrom: I'd liek to propose that we document the versioned context strings, how they can be used, and what the downsides are
# 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
# bengo cwebber2: I agree with document what we're doing. But in a certain sense we don't know what we're doing.
# bengo cwebber2: We made these URLs for one reason, and they aren't even being used.
# bengo cwebber2: And the current thing being done by Mastodon is different. We don't know what they want.
# bengo cwebber2: Let's look at the proposals
# bengo cwebber2: #1) Keep extending AS2 document. And publish versioned URLs alongside.
# eprodrom Expires: header?
# 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
# 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
# bengo cwebber2: Am I missing something?
# bengo cwebber2: Any corrections?
# eprodrom q+
# bengo sandro: I don't think proposal #2 works. It still breaks.
# bengo (can you verify old signatures with #2)?
# bengo cwebber2: Anything other than append-only would be bad.
# bengo sandro: Does signature include namespace doc or @context?
# bengo cwebber2: expanded to URIs first. Full-quads.
# bengo sandro: But the only things signed are the triples sent to you
# 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.
# bengo sandro: So why didn't mastodon do it? (refresh when you get a bad signature)
# bengo cwebber2: It might not have been suggested
# bengo sandro: I think we did, but don't remember what happened
# bengo cwebber2: For mastodon specifically they were bundling at build-time.
# bengo cwebber2: idk if they would be willing to change their behavior. They have new opinions since they've had a growing @context
# bengo cwebber2: reads ajordan last few chats
# eprodrom I'm -1 on #2 also
# eprodrom Do we need to keep discussing it?
# eprodrom https://gitlab.com/snippets/1698865
# bengo eprodrom: First of all, I want to make sure I absolutely understand the problem.
# bengo eprodrom: I want to make sure, cwebber2, are you saying if the document at that @context URL changes, would the signature be different?
# bengo cwebber2: No because it doesn't use an extension
# bengo eprodrom: Will you make an example where the sigs would change?
# bengo cwebber2: yes I'll do in IRC
# 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
# bengo cwebber2: New version of smilodon comes out after `noBots` was added. Old version on server A, new on server B.
# 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
# bengo cwebber2: If sig is generated with context that DOES have nobots, the signature would be different
# bengo eprodrom: Wouldn't it resolve to _:noBots?
# bengo eprodrom: Not omitted
# bengo cwebber2: oh yes
# bengo cwebber2: Because AS2 has default context
# bengo eprodrom: If we used a versioned context. Then they'd get the correct expansion for noBots?
# bengo cwebber2: correct
# bengo sandro: No one should ever sign a document that is not in the context
# bengo cwebber2: It would fail previously, but maybe not the case now that we have an '_' in there.
# eprodrom q?
# eprodrom q+
# bengo (I failed to scribe the details there)
# 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!
# bengo eprodrom: It's also something completely out of our control
# bengo +1
# bengo eprodrom: yes I -1'd propsal #2 earlier since it's out of our control
# bengo eprodrom: They aren't using caching correctly. That's why they get this problem. They're just not doing it right
# bengo cwebber2: An alternate suggestion: when this happens, is it severe?
# eprodrom q+
# bengo cwebber2: Next agenda item might help with this. If might not be that severe, or implementers may change their behavior.
# 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.
tantek joined the channel
# 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.
# bengo eprodrom: And if you're doing LDS, you'll probably still be requesting something to get a public key
# bengo eprodrom: So we may also want to publish "ways of validating things" suggestions.
# bengo sandro: We're caught where we don't belong between LDS and Mastodon. There was failing in communication between them.
# eprodrom sandro++
# 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.
# bengo sandro: Maybe there is a good reason to do that (e.g. embedded offline devices), but we can't know that.
# eprodrom q-
# bengo cwebber2: Straw poll?
# eprodrom +1
# bengo +1 it doesn't hurt to have URLs
# bengo eprodrom: (with documentation)
# bengo cwebber2 : Let's vote on Proposal 1
# bengo (sry scribe fail)
# eprodrom +1
# bengo +1
# bengo cwebber2: 0.5 because not all implementers here
# bengo cwebber2 P2
# eprodrom -1
# bengo cwebber2 Proposal 2
# bengo -1
# bengo +0 - I don't know enough about LDS
# bengo -1: I dont' like mutating the document. It can lead to ambiguity when adding terms that someone was using intentionally undefined
# bengo I don't think "One context URL" is actually more gain than pain
# 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
# bengo cwebber2 Proposal 3
# bengo +1
# bengo (this is automatically what will happen with 'beta' extensions)
# eprodrom +0
# bengo -1 don't claim things in a namespace you don't govern
# eprodrom -0 implementers can do this already
# bengo cwebber2: Most enthusiasm for versioned thing
# eprodrom q+
# 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)
# 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
# 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
# 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
# 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.
# eprodrom separate context or separate namespace?
# bengo cwebber2: Evan has a proposal
# bengo cwebber2: We should notify jasnell
# bengo HTTP 30x
# eprodrom sandro: but context and namespace are not the same, right?
# 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
sknebel joined the channel
# bengo while true; curl tantek.com/micropub; done
# bengo cwebber2: I want the CG to be welcoming. That should be a priority
# eprodrom +1
# bengo cwebber2: Sounds resolved?
# 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
# 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?
# 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
# 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
# eprodrom What new git repo?
# bengo (I could have mis-scribed)
# RRSAgent I have made the request to generate https://www.w3.org/2018/02/14-social-minutes.html trackbot
# eprodrom I thought we just agreed to use the AS2 repo
RRSAgent left the channel
# eprodrom sandro: I'd like to figure out how we document the versions thing
# eprodrom bengo++
# eprodrom sandro: I don't think we actually decided on someone to do it
# eprodrom cwebber2: I was just thinking something in the ERRATA.md
# eprodrom ajordan_: you can
# eprodrom If people did it the way you said, it would work well
# eprodrom Your proposal was good except for the part where we can't actually get people to do it
# bengo ajordan_ I am grateful for you contribution on the TTL thing.
# bengo ajordan_ AFAICT it will work in practice.
# eprodrom cwebber2: Here's proposed text for ERRATA.md: "In some circumnstances, such as for [LDS], implementers may need to use a context URL for an immutable document. As extensions are added, we create new versioned documents, by version number and by hash. This version history is available [here]."
# eprodrom An extensions _page_?
# eprodrom Why?
# bengo In that ERRATA it would be pretty cool to be able to say "If you want to support versioned contexts, look for this string PREFIX in the @context"
# eprodrom OK but why
# bengo so it is still pretty simple string comparison
rowan_ joined the channel
# eprodrom cwebber2: no no no no no
# eprodrom cwebber2: wouldn't we just keep using this page? https://www.w3.org/ns/activitystreams
# eprodrom It seems to be working really well
# ajordan_ eprodrom: about refetches not working in practice, if we had a canonical "spec" (or CG report or whatever) that said "this is how you do signing on the AP network" I feel like that would be good enough? like I totally understand that right now it isn't because LDS is basically undocumented and wishy washy
# eprodrom ajordan_: THEY WORK IN PRACTICE
# eprodrom No, my objection is that they're already not doing it
# eprodrom Yes
# eprodrom I think documenting the "right" way to do signatures in specifics and verification in general is a super good idea
# bengo ajordan_ If you write your best version of that it will likely be very useful to implementors
# eprodrom bengo: I agree
# eprodrom I can't, sorry
# eprodrom email me
# eprodrom And let's do our meeting on Friday
# BanjoFox Are there any plans to do a Matrix bridge for this channel?
# eprodrom Uh
# eprodrom I have never heard of such plans
# bengo ajordan_ do you have an ActivityPub implementation?
# BanjoFox it might. but I'm not sure how to connect here from Matrix :)
# eprodrom Oh no
# bengo ah that's right. thx for reminding me
# eprodrom ajordan_: what are you hacking on then?
# eprodrom "Alexa, delete line 475 of main.js"
# 
csarven re "tantek is glad to see vcard as an explicit desired addition, instead of yet another SemWeb fork re-use" -- So, what's "reuse" and what's the "problem" with reuse? mf-1 "reused" terms from VCARD and serialized them entirely in its own way. So did mf-2 in a completely different non-backwards compatable way - Crystal clear longevity fail. All within ~5 years! Is there a particular need to bash SW (yet again)? Isn't that what the IWC wiki is for? Can we
# eprodrom thanks
# eprodrom cwebber2: so, one of the things I wanted to put on the agenda for today, being valentine's day, was discussing web dating systems
# eprodrom I did a talk about dating on the open web at MozillaFest and it went over great http://slides.com/evanpro/dating-on-the-open-web
# saranix cwebber2: minutes posted to 2018-02-13 but it is 2018-02-14
# eprodrom I'm going to put it on the agenda for the next meeting
# eprodrom cool
# cwebber2 apparently it was fixed anyway despite the exception https://www.w3.org/wiki/SocialCG/2018-02-14/minutes
# eprodrom cwebber2: did it already
# eprodrom cwebber2: 2018-02-28 correct?
# eprodrom Biweekly IIRC
# eprodrom :(
# eprodrom l8r innov8rz
# melody i miss one meeting and this place explodes what on earth happened
# bengo +1 cweber.
# bengo leaves
# csarven tantek Why do you feel that you are always right? I simply asked you to clarify yourself by merely backing up "personal jab". I asked to simply highlight some text from what I originally said and paste. A quote. Why do you refuse to that or ignore that and continue to feed false information? What do you want out of this exactly?
timbl joined the channel
# csarven [18:56:04] <csarven> re "tantek is glad to see vcard as an explicit desired addition, instead of yet another SemWeb fork re-use" -- So, what's "reuse" and what's the "problem" with reuse? mf-1 "reused" terms from VCARD and serialized them entirely in its own way. So did mf-2 in a completely different non-backwards compatable way - Crystal clear longevity fail. All within ~5 years! Is there a particular need to bash SW (yet again)? Isn't that what the IWC
# saranix "<csarven> "decentralized social web initiatives haven't..." what article is this?
# saranix uri
# 
tantek saranix, this post: https://dustycloud.org/blog/on-standards-divisions-collaboration/
# saranix I must admit the title has me intrigued
rowan and rowan_ joined the channel
# melody trying to understand the implications of the decision(s?) made today -- if an implementor wants/needs to create extension(s) that add terms what is the process now? i'm not entirely clear from reading the backscroll what was decided in the end
# saranix I've never been clear
# melody what happens if AS doesn't want the vocab/terms?
# melody I wasn't sure if that had somehow changed based on today -- like I was planning on (probably) implementing my own vocabulary/context in addition to the existing one because I'm pretty sure my needs are going to be controversial & also require a lot of incubation time before the value of them could be proven
# melody but i saw some references to not adding additional contexts because it was a bad idea
# melody ok
# melody i'm not sure if i am going to be wanting/needing LDS yet, but prep work for my implementation is slowly ramping up now so i'm putting a lot more thought into the technical constraints
# melody and wanting to keep on top of stuff
# melody i haven't finished reading up on json-ld -- what happens if multiple vocabularies define the same term? like, mostly curious if like, i implement an extension that eventually gets used in AS without my knowledge, or i've used a term that gets used for a _different_ extension that gets pulled into AS, how badly things will break
# melody yeah, that's what i'm asking about -- if i define a term in a context at `melodysthing.social/whatever` and then AS also gets an official extension that defines that term sometime later
# melody actually pretty likely to need to redefine or break some vocabulary eventually
# melody i anticipate i'm going to need to add a lot of things to AP and that some of them are probably going to eventually become extensions, and some might not, and parts of some might make it but other parts might be too controversial, but there are going to be things i'm not going to be willing/able to compromise on if it would violate the integrity of the project's principles around anti-harassment/anti-abuse/accessibility things so i anticipate i'm
# nightpool sorry, just joining and also catching up on today's discussion
# melody being a good citizen of the fediverse is further down the priority list than other design constraints for me, so i'm going to make a best effort but there are going to be things that aren't proven/things that might not work/things that other people frankly just won't want -- but i guess i will figure out how to reconcile them when it happens
# nightpool melody: do you mean you'd be adding terms like 'https://melodysthing.social/term' and are wonder what would happen if that got pulled into a as2 context? but wouldn't an as2 context have to be rooted at 'https://www.w3.org/ns/activitystreams'
# melody i'm really not sure of the details, i'm still reading up on json-ld, i only understand linked data in pretty broad terms and i understand how we're using it slightly less than that, but if i have both contexts (which i think i would need?) i was asking what happens if activitystreams adds a term that had previously been my-thing-specific
# nightpool all json-ld terms are URIs
# nightpool so they have to have an authority and a path
# nightpool terms you defined would presumably be defined under a hostname you control
# nightpool so it would be impossible for activitystreams to define one that shadows it
# melody ah, so as long as i ....nest things under the appropriate context, it should disambiguate them okay?
# nightpool uh, -ish?
# nightpool basically, every json LD document looks like
{"https://www.w3.org/ns/activitystreams#name": "nightpool"}# nightpool but we use @context to compact that to just
{"@context": "https://www.w3.org/ns/activitystreams", "name": "nightpool"}# melody after it's been (processed? resolved? flattened?) -- if i'm using the compacted form with terms only defined in my context but then the term is suddenly also in activitystreams' context
# melody i am less clear on what would happen
# nightpool that would be a problem with pure-json processors
# nightpool I, hmm. I guess it does affect older documents too though, since we're not using versioned specifiers.
# nightpool I guess the answer is 'if youre concerned it might happen, only ever compact to prefixed terms like "as:name"', maybe?
# nightpool i do see the problem you're asking about now though.
# melody glad it's not a completely silly question, lol
# nightpool if im understanding cwebber2's answer, it was that if you put your context first, no later contexts can 'shadow' it
# melody i'm trying to catch up on all this stuff but there's so many standard documents to read and it's a lot to hold in my head while i'm also trying to map it all to my use cases
# nightpool yeah, no worries
# melody and then there's the additional decisions that get made here
# nightpool cwebber2: if you're around i can clarify some of the current mastodon thoughts on LDS for the record.
# nightpool sure
# nightpool (it might need to be more like 30 given that im about to go to a short meeting here)
# nightpool anyway, melody, given this concern and also similar concerns around pure-json processors.
# melody i'm going into a 30m meeting here, will check in when i get back
# nightpool oops I was going to finish that sentence but can't, sorry
# nightpool yeah see you then
# melody forgot i have two more meetings after this one, 1h each, so i might be peeking in but probably won't say much until later
# nightpool okay, so, just to capture what I was thinking earlier before I forget:
# nightpool right now i think AS2 is a little too liberal about what it allows as far as compact URIs go
# nightpool in my ideal pure-JSON world, the only compact uris allowed without prefixes would be ones in the activitystreams context
# nightpool and all others need at least some prefix, if not a full uri.
# nightpool my concern though is that, as melody mentioned, in the presence of a growing context, these terms can even be amgibuous to a JSON-LD compliant processor.
# nightpool sorry, by "these terms" I mean "compact URIs without a prefix"
# nightpool sure.
# nightpool 1: server a publishes a document like
{"@context": ["https://myname.space", "https://www.w3.org/ns/activitystreams"], "term1": "whatever"}# nightpool this is valid because term1 is a property only in myname.space.
# nightpool 2. term1 gets added to the activitystreams namespace
# nightpool now the old document (which may be getting passed around, signed or cached or whatever) has totally different semantics
# nightpool depending on which context you resolve from first, which I dont even know without looking it up
# nightpool right
# cwebber2 this is a reason for freezing contexts ie on https://www.w3.org/ns/activitystreams-history/
# nightpool i'm not exactly sure how that solves the practical problem, unless you just reject all documents with a newer versioned context
# nightpool right.
# nightpool but what happens to, say, a mastodon server when some of the servers you're talking to have upgraded and you haven't yet?
# nightpool right but we dont do jsonld processing.
# nightpool basically.
# nightpool i guess??? in melodys case their would be, but that's easily avoided by either doing jsonld processing or always compacting to prefixed compact uris
# nightpool anyway i g2g, but we should pick this up later
# nightpool i think that ultimately for the best pure json compatibility, as2 shouldn't allow people to compact to bare URIs for anyhting except term definitions from the activitystreams context
# nightpool but i dont know how feasible that change is wrt where we are in the spec process with as2 and ap
# nightpool but yeah g2g
jaywink and rowan joined the channel
# melody finally out of meetings and checking in on this -- i think i actually understood the conversation in the scrollback this time which is very exciting 😄 proof that i have been ~* learning things *~ but still trying to process the implications, especially around freezing contexts -- like, will a json-ld compliant processor know how to get the frozen context or is this something that will need to be handled if you want it some other way?
# melody Like, if I want to make sure I'm only passing around documents with frozen contexts, even if when I get the document it has an unfrozen URI, it's not clear to me where the responsibility for that falls based on my current understanding
# csarven Forgot to +1 Evan for using vCard. SW fully supports the reuse of that vocabulary as well eg https://www.w3.org/TR/vcard-rdf/
# melody @cwebber2 that part i understand, i'm asking how you get the frozen version of the URI -- if i get a document that just has "https://www.w3.org/ns/activitystreams" how do I get the frozen version of that context and replace it and will doing so screw up signatures again?
# melody for stuff that originates with me, i think so -- will i also have to manually map the base URI to the frozen version for stuff coming from implementations that aren't as careful?
# melody that adds my problem back w/ compacted terms but i guess i can just be sure i prefix mine
# melody but i think in practice i can't really control whether other people are giving me frozen contexts and i do worry that this will bite me if i don't mutate the document to freeze the context when i get it
# melody and mutating the document would invalidate the signature
# melody probably?
# melody i feel like it _should_
# melody but i guess i'm not sure
# melody i'm still not sure if i'm going to be caring about LDS or not
# melody yeah i've not gotten to mess around with it much yet and still not sure if i'm going to have to implement libraries for json-ld in addition to all my other work, haven't gotten there yet
# melody the project itself is still very much in a UX Research/Design phase, but I'm trying to bridge that to also determine like, what infrastructure needs to come into being to realize these things we're talking about and can I make the standards fit
# melody so i'm straddling a weird line between high-concept and buried in the weeds
# melody and having to context-switch back and forth regularly
rowan joined the channel
rowan joined the channel