#social 2018-09-12

2018-09-12 UTC
cdchapman, xmpp-social and vasilakisfil joined the channel
#
heluecht[m] Concerning the digest I noticed yesterday during my tests that either the RFC example is wrong or Mastodon and Pleroma had implemented it wrong.
#
heluecht[m] In the RFC the sha256 digest is a base64 of a sha256 checksum - See here: "Example of Instance Digest for SHA-256:
#
heluecht[m] But on Pleroma and Mastodon this is a base64 of a binary sha256 checksum, for example "SHA-256=w9O33P2TYlVzDKtSc6unax+T31hH4QyQqB/vGelFB6w="
#
heluecht[m] You surely notice the lewngth differences. Question is if both is okay.
vasilakisfil joined the channel
#
nightpool[m] huh
#
nightpool[m] i guess we should support both cases but as far as I can tell, that example is just wrong
#
puckipedia <heluecht[m]> Concerning the digest I noticed yesterday during my tests that either the RFC example is wrong or Mastodon and Pleroma had implemented it wrong. <- wait what ehm
#
puckipedia https://www.rfc-editor.org/errata_search.php?rfc=5843
#
puckipedia it's in the errata lol
#
heluecht[m] RFCs are never corrected?
#
heluecht[m] I fiddled around with this for some time yesterday until I looked into the code from Hubzilla to see the difference.
#
puckipedia good question. no idea.
#
nightpool[m] apparently
alejandro joined the channel
#
cwebber2 nightpool[m]: https://github.com/w3c/activitypub/issues/319#issuecomment-420660259
#
Loqi [cwebber] The right approach which degrades gracefully is to add a new proof node with a proofPurpose that says whether or not a post is signed off on as a valid reply. So: ``` {"type": "Note", "content": "bla bla", "inReplyTo": ..., ... "signatur...
#
cwebber2 we have a meeting in 40 minutes... I should send out reminders
#
puckipedia bleps
tantek and vasilakisfil joined the channel
#
cwebber2 hi puckipedia
#
nightpool[m] I'm at work now
#
nightpool[m] I'll be able to take a look in ~7 hours
#
cwebber2 ok, good to know nightpool[m]
#
cwebber2 we're going to try to get resolution on https://github.com/w3c/activitystreams/issues/479 today
#
Loqi [gobengo] #479 Don't encourage work-in-progress extensions in w3.org namespace
#
cwebber2 https://github.com/w3c/activitystreams/wiki/Extension-process
#
tantek is there a meeting today?
#
tantek not seeing anything in /topic
#
cwebber2 there's a meeting today
#
cwebber2 I just mentioned it :)
#
cwebber2 https://www.w3.org/wiki/SocialCG/2018-09-12
eprodrom joined the channel
#
eprodrom I think Sandro said he was going to join
#
tantek skims the agenda
#
tantek going to be a bit late (in transit) but I have some opinions on some things.
#
tantek on vCard in particular, I'd say time to reference vCard4 RFC, not an obsolete W3C NS doc / URL
#
cwebber2 ===== MEETING LOGGING STARTS =====
#
cwebber2 present+
#
tantek the whole practice of creating forks of vocabs in "RDF space" that go stale is a massive anti-pattern IMO
#
aaronpk Well I *was* gonna be on a flight just now but it is delayed so I can try to dial in
#
aaronpk No promises on airport Wi-Fi tho
#
tantek (kind of a problem with SemWeb approaches in general, but that's a larger / harder topic beyond the context of this telcon)
#
eprodrom present+
#
puckipedia present+
#
cwebber2 chair: cwebber2
#
tantek will try to join by mumble by ~08:30 PDT
#
cwebber2 scribe: cwebber2
#
eprodrom scribenick: eprodrom
#
eprodrom scribe: eprodrom
#
cwebber2 https://www.w3.org/wiki/SocialCG/2018-09-12
#
cwebber2 eprodrom: re: scheduling CG telecon meetings
#
cwebber2 eprodrom: coming off of summer, we've had skipped meetings over last couple weeks and I'd like to get us to a point where we have a good process for meetings
#
cwebber2 eprodrom: I understand we're coming out of the summer period, but seems like a good time to talk about process going forward
#
cwebber2 cwebber2: should we be making changes to the meeting patterns?
#
cwebber2 eprodrom: I think if we're on biweekly meetings that's fine, but it seems to be a lot, but maybe there would be more energy behind monthly meetings
#
cwebber2 eprodrom: the other question is about chairing meetings, it may be useful for you and aaron to have a clear agreement on who's chairing when
#
cwebber2 cwebber2: I'm open to switching off co-chairing, and I'm open to moving to monthly meetings
#
cwebber2 puckipedia: I think that's good, also currently there doesn't seem to be as much to be things happening specifically with the SocialCG
#
cwebber2 eprodrom: I would agree with that, I'll be as honest as I can be, I think we've gotten jammed up with AS2 issues, and I think Chris agrees here
#
cwebber2 eprodrom: hopefully if we can clear up that blockage with this meeting we can start stuff moving forward
#
eprodrom cwebber2: Agree that vocabulary discussion has dragged, will be good to close it up
#
eprodrom cwebber2: pulling in more implementers would be great
#
eprodrom cwebber2: triaging and resolving AP issues will help also
#
cwebber2 eprodrom: there's also a lot of open AS2 issues we should triage, it's cool we're getting th ekind of review necessary to do that and next step is to knock them down
#
cwebber2 eprodrom: I think we have good ideas on how to deal with that now
#
cwebber2 eprodrom: in terms of meeting, do we want to switch to a monthly meeting, say the 2nd weds of the month and try it out for now?
#
eprodrom cwebber2: that gets a +1 from me
#
cwebber2 aaronpk, ^^^
#
puckipedia +1 from me as well
#
aaronpk +1
#
cwebber2 eprodrom: I'll make a formal proposal
#
eprodrom PROPOSAL: reschedule teleconferences to monthly meeting on the 2nd Wednesday of the month
#
cwebber2 +1
#
puckipedia +1
#
eprodrom +1
#
eprodrom RESOLVED: reschedule teleconferences to monthly meeting on the 2nd Wednesday of the month
#
cwebber2 eprodrom: I think this will make things higher stakes to where we'll take prioritization more seriously
#
cwebber2 cwebber2: agreed
#
cwebber2 cwebber2: and we can prioritize later
up201705417 joined the channel
#
cwebber2 eprodrom: vcard and sec are examples of changes backed up because we don't know how to do this
vt joined the channel
#
cwebber2 https://github.com/w3c/activitystreams/wiki/Extension-process
#
cwebber2 present+ sandro
#
cwebber2 present+ melody
#
cwebber2 eprodrom: I'll do a quick overview
#
cwebber2 eprodrom: issues we're trying to address, biggest for me is the context property we have to put into the AS2 doc, can get really complicated really fast. If you're trying to include many vocabularies and namespaces and etc, it gets messy
#
cwebber2 eprodrom: ideally what we'd like to do is to say "use that single string for AS2" and I realize that's an ideal... but the more we approach to saying move widely used prefixes into the context itself, the easier it becomes for everyone to make good as2 documents, and it cuts down on accidents. I think it's helpful, the more we can do to ?? our document, the easier it is for publishers to use AS2
#
cwebber2 eprodrom: I originally made this doc with suggestions on how to add things to the AS2 namespace, but namespace is distinct from context document, and there was pushback on that
#
cwebber2 eprodrom: so I changed it so that it's not about changing namespace, only about including terms in our context
#
cwebber2 eprodrom: and it may be worthwhile to rename this page or call it something else, but for right now what it's doing is just talking about including external namespaces
#
cwebber2 eprodrom: it talks about a number of different namespaces from external vocabularies to there are plenty of namespaces we want to leave out
#
cwebber2 eprodrom: we drop a lot of implementation-specific documentation
#
cwebber2 eprodrom: how we would use namespace, where we choose to incorporate
#
cwebber2 eprodrom: where we've gotten caught up is I think two camps, one that says that ok if you're going to do new features for AS2 you should do it as an external namespace, another that says we should do it in an internal namespace
ben_thatmustbeme joined the channel
#
cwebber2 eprodrom: it's interesting but we don't have consensus and we're not bringing in any of these external namespaces
#
cwebber2 eprodrom: I'd take the security namespace as a good example, it's widely used for AP but we all have to find it and include it and etc... would be very nice for it to just be included in the AS2 context document. Can we agree on this mechanism for including external namespaces and have the argument about whether to use external namespaces or augment as2 namespaces as a separate discussion?
#
cwebber2 sandro: can we go for a slightly more... not siding on a mechanism but including a bunch of external namespaces or ???
#
cwebber2 eprodrom: are you saying have votes on a per-namespace basis or all at once
#
cwebber2 sandro: the harm is if we include something we want to take out again that woudl cause problems and if we can't agree on prefix that would also be a problem
#
cwebber2 sandro: don't know if those are controvercial or at risk
#
cwebber2 sandro: frankly I wasn't thinking about that as the issue
#
cwebber2 puckipedia: we have two things, actual extensions and things where we have eg the sec: namespace which isn't an extension as itself, it doesn't add any functionality to AP, just using the namespace as a way to basically create an extension with existing namespaces
#
cwebber2 puckipedia: I think that's what kind of sandro means?
#
cwebber2 sandro: I don't know what the sec namespace is, can someone explain?
vasilakisfil joined the channel
#
cwebber2 eprodrom: I'd like to get this to a vote, do we do it or not
#
cwebber2 sandro: you didn't say anything about my proposal
#
cwebber2 eprodrom: my response to that is I've been working on this extension process for months instead of skipping over it
#
cwebber2 +1 from me
#
cwebber2 eprodrom: I'd like to get this off the agenda, if we get to the point where we don't agree, but I'd like to close that up
#
cwebber2 eprodrom: I'm honestly really tired of it
#
cwebber2 cwebber2: it soudns like what evan is proposing is the process
#
cwebber2 eprodrom: that's it
#
cwebber2 sandro: this is about the context and not the extension process?
#
cwebber2 eprodrom: that's true
#
cwebber2 sandro: can you read the proposal?
#
eprodrom PROPOSAL: Accept https://github.com/w3c/activitystreams/wiki/Extension-process as extension process for AS2
#
eprodrom -1
#
cwebber2 eprodrom: it seems we don't have consensus on it, so I think we just move on
#
cwebber2 sandro: -1
#
eprodrom Rounding down!
#
cwebber2 +1
bengo joined the channel
#
bengo +1
#
cwebber2 eprodrom: why don't we take this as closed, if we have need for guidelines for an extension process, otherwise we don't have a process for extensions to AS2
#
cwebber2 eprodrom: maybe we just do it ad-hoc as needed
#
cwebber2 eprodrom: we do have a couple of issues open that might help guide discussion
#
puckipedia -1 for now, we should most definitely figure out how to do this and maybe just try it out first, before having a proper process
#
bengo I don't think you can hear me. Sandro, do you have an issue filed?
#
bengo about your concerns?
#
puckipedia bengo: noone can hear you
#
puckipedia you're not talking at all
#
cwebber2 bengo, yeah I can't hear you
#
cwebber2 bengo: it sounded like evan voted -1 for consensus reasons rather than the issue itself
#
cwebber2 bengo: maybe there's a path forward
#
cwebber2 bengo: maybe further discussion on github issues
#
eprodrom q+
#
cwebber2 bengo: this happens to all humans, but there's room for that passing, maybe evan will only vote -1 if there's not full consensus
#
puckipedia q+
#
bengo sandro btw I am soooo sympathetic to the fact you didn't see it till later. <3
#
cwebber2 sandro: I think in my posting last night, I apologize for not noticing the issue until late last night... I do care about this community, I do care about namespaces... I wrote about the extension process for the namespace, not sure what else to say than I said. I'm 0 (or -0?) on the context thing
#
bengo k
#
cwebber2 ack eprodrom
#
cwebber2 eprodrom: so I wonder if there's any value in... since there's two other items on the agenda... it feels like we have not moved this proposal forward and it's not closed. We've literally talkeda bout this at every meeting since may. If we were ready to go we would but we're not. Maybe we approve moving a couple of namespaces into the context, high value ones, and we develop a process through experience rather than prescriptive process
#
cwebber2 sandro: +1
#
cwebber2 ack puckipedia
#
cwebber2 puckipedia: so my opinion, we're trying to make a process for something that hasn't yet occurred at all except for possibly... we don't have any formal proposals for extensions yet, and we don't have any... we could go with experience with adding extensions and how people hadnle that
#
cwebber2 https://github.com/w3c/activitystreams/issues/459
#
Loqi [evanp] #459 Add vcard to @context
#
cwebber2 https://github.com/w3c/activitystreams/issues/477
#
Loqi [evanp] #477 Add the Web security namespace to @context
#
cwebber2 eprodrom: we have two proposals above
#
eprodrom https://www.w3.org/TR/activitystreams-core/#actors
#
cwebber2 s/eprodrom: we have/cwebber2: we have
#
cwebber2 eprodrom: wish I had a chance to get multiple examples together
#
cwebber2 eprodrom: vcard is SHOULD in AS2, if that's the case it seems like a simple... adding the namespace ot the context document is low-impact, the only downside would be if for some reason someone is using vcard for something else that it would interfere or be confusing otherwise this seems like a simple addition for AS2
tantek joined the channel
#
bengo yes, propose so I can +1
#
tantek present+
#
tantek muted
#
tantek checks logs
#
eprodrom PROPOSED: Accept https://github.com/w3c/activitystreams/commit/94a2dfad623a663dd206f4de2505c1c75c54f84e to close issue #459
#
cwebber2 eprodrom: clarification, this is just about adding vcard: shortname
#
cwebber2 +1
sandro_ joined the channel
#
eprodrom +1
#
melody +1
#
bengo +1
#
puckipedia +1
#
tantek will defer to rest of CG on this issue
#
puckipedia https://github.com/w3c/activitystreams/pull/491
#
Loqi [evanp] #491 Add vcard: prefix to context document; closes #459
#
puckipedia <eprodrom> PROPOSED: Accept https://github.com/w3c/activitystreams/commit/94a2dfad623a663dd206f4de2505c1c75c54f84e to close issue #459
#
tantek next telcon: https://www.w3.org/wiki/SocialCG/2018-09-12. Logs: https://chat.indieweb.org/social/
#
sandro_ +1
#
bengo https://github.com/w3c/activitystreams/pull/491
#
Loqi [evanp] #491 Add vcard: prefix to context document; closes #459
#
bengo thanks puck
#
bengo :P
#
tantek sees a lot of whitespace changes 😂
#
eprodrom RESOLVED: Accept https://github.com/w3c/activitystreams/commit/94a2dfad623a663dd206f4de2505c1c75c54f84e to close issue #459
#
eprodrom tantek: I know, I just noticed that myself
#
bengo https://github.com/w3c/activitystreams/pull/490 for 'sec:'
#
Loqi [evanp] #490 Issue 477
#
puckipedia +q
#
cwebber2 puckipedia: one issue I have with PRs currently is that it isn't actually useful for anything currently, becasue all current uses of this namespace have been by importing the entire context, which for example is use used for publicKeyPem etc
#
tantek hmm I thought vCard already had a KEY property
#
bengo q+
#
cwebber2 puckipedia: if we were to embed the context we should also at least unpack the parameters
#
eprodrom q+
#
sandro_ losing puck audio
#
cwebber2 puckipedia: for compatibility with current servers
#
cwebber2 bengo: I think that's a step further, the way the PR is currently done, it wouldn't make existing implementations break, they can still use more namespaces in their context, so wouldn't be backwards incompatible?
#
cwebber2 puckipedia: it wouldn't be incompatible, but it wouldn't make sense to include it and have nobody use it
#
bengo q?
#
tantek agrees with puckipedia
#
cwebber2 q+
#
tantek feel premature
#
cwebber2 eprodrom: question would be... if this is accepted, this would be a simple context, and then you could use the sec: terms with prefixes. So sec:publicKeyPem etc and that would just... that saves the step of having to add it for the context
#
bengo We can always do what puck is proposing later... but there isn't a PR for that now. And also Occam's razor applies. "It's vain to do with more what can be done with less" for adding all thos ealiases. I'm in favor of PR as is
#
cwebber2 eprodrom: I realize that it does not also mean adding the aliases, I wonder if it's valuable to us to separate those two changes, first add the namespace then add the aliases, or must we do both simultaneously
#
cwebber2 puckipedia: I would like to point out there is a small issue with doing this and it is id values, eg sec:owner is id, so if you put a string in it it becomes a url
#
cwebber2 puckipedia: if you just use the prefix it doesn't do this
#
cwebber2 {"sec:publicKeyPem": "..."}
#
cwebber2 {"publicKeyPem": {"@type": "@id", "@id": "..."}}
#
puckipedia {"sec:owner": "https://puckipedia.com/"} is either {"@value": "https://puckipedia.com/"} or an object {"id": "https://puckipedia.com/", "preferredUsername": "puckipedia"}
#
Loqi HACKER TEEN PUCKIPEDIA 👩‍💻
#
eprodrom q+
#
cwebber2 eprodrom: we're coming up on 12:00, unfortunately I can't keep going, can we vote this up or down or defer?
#
tantek my vote is defer as well
#
tantek in particular, no evidence is documented in the issue for "security namespace as a good example, it's widely used for AP"
#
tantek cwebber2: can you add such examples to https://github.com/w3c/activitystreams/issues/477 ?
#
Loqi [evanp] #477 Add the Web security namespace to @context
#
tantek we should back up assertions like "widely used" with citations in GitHub
#
tantek thanks
#
eprodrom Thanks all
#
cwebber2 eprodrom: we're running out of time, should we defer this?
#
cwebber2 cwebber2: yes
#
cwebber2 cwebber2: see you next month, oct 10th
#
cwebber2 ===== MEETING LOGGING ENDS =====
sandro__ joined the channel
#
melody sorry for dropping out sudenly, i had a hard stop at 12
#
melody had another meeting
#
melody does anybody know how to put up a recurring meeting for "second wednesday of every month" on _any_ kind of calendar app because i'd love for my calendar not to be totally wrong about when meetings are so that i can start participating again
#
tantek pretty sure iCal RFC 5445 supports that
#
tantek now whether any calendar app supports that interoperably, who knows. there's no public iCal test suite so... yeah.
#
aaronpk Recurring events are hard. I just create events for like 6-12 months out. It doesn't take that long.
#
nightpool[m] uploaded an image: Screenshot_20180912-123131.png (73KB) <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/PKxDDtQNIoqmmwaYaOmzVmJq>
#
nightpool[m] gcal seems to support it?
sandro_ joined the channel
#
melody yeah i figured that out shortly after asking
#
melody so the meetings are on my calendar now
#
tantek melody, btw if you'd like an icon next to your name in the logs (e.g. https://chat.indieweb.org/social/2018-09-12#bottom ) feel free to add yourself to https://www.w3.org/wiki/irc-people !
#
tantek (and e.g. link your name in the logs to your personal site)
#
melody i'm about 99% sure i don't have access to that wiki
#
melody i'm not concerned in any event, but i don't think i could if i wanted to
#
nightpool[m] yeah tantek nobody has access to the wiki because none of us are WG members
#
tantek grr darn it CG members are supposed to be able to get access
#
tantek ok I will raise that to the AB
#
tantek in the mean time, I'm happy to be your edit monkey
#
tantek er, edit puppet
#
tantek actually for anyone here - if you have minor edits to suggest for w3c wiki, feel free to !tell me and I'll try to keep up
#
tantek (plus that will motivate me to get y'all permissions / logins 😂)
#
cwebber2 minutes posted
#
saranix doesn't understand all this json-ld talk, context import vs. prefixes, yadda yadda. also don't get vcard which tries to be a format, a schema, an encoding, and a protocol all in one while somehow only being a data structure in reality...
#
heluecht[m] I don't have a problem with vcard data in AP. But I really dislike it that with JSON-LD there are numerous ways to display the exactly same piece of information.
#
saranix I don't think AP/JSON-LD creates that problem, but it sure does a good job of putting it all in one 'junk drawer' so we can now address it, if we want. baby steps...
#
tantek re: what vcard tries to be: vCard4 RFC 6350 is both a vocabulary and a format (MIME headers style) with a file extension .vcf which pretty sure requires UTF-8 now. no mention of protocol AFAIK.
up201705417, cwebber2, vasilakisfil and sandro__ joined the channel
#
nightpool[m] Reading up on meeting minutes.
#
nightpool[m] (cwebber2, mind fixing your connection?)
#
nightpool[m] thoughts on meeting times: I think we've seen a lot of drop off from this telecom due to people's schedules changing, and i don't think keeping the same time but moving to once a month is going to move the needle there
#
nightpool[m] we should consider rescheduling the meetings, since AFAIK the current time hasn't changed since the very beginning of the group.
#
nightpool[m] Thoughts on extensions:
#
nightpool[m] I don't agree with puckipedia or tantek__ that an extension process is premature.
#
Loqi yea
cwebber2 joined the channel
#
nightpool[m] I've been very vocal about the fact that i think mastodon development has suffered due to uncertainty about consensus for certain properties or the extension process as a whole.
#
nightpool[m] We have four extensions in kind of a "no man's land" of being put into the AS namespace without any specific group consensus (although at the time there was consensus that it was a good idea for us to put properties in that namespace generally)
#
nightpool[m] and three extensions that we've put into our own namespace because the group had stalled out on approving an extension process
cwebber2 joined the channel
#
nightpool[m] I know peertube and pleroma have similar extensions (as:dislikes comes to mind)
#
puckipedia nightpool[m]: so, my stance is basically "we can't figure out an extension process without having extensions to process first" - I don't think blindly taking an extension process would work
#
nightpool[m] we have lots of extensions to process
#
nightpool[m] Everything on https://www.w3.org/wiki/Activity_Streams_extensions, for a start
cwebber2 joined the channel
#
nightpool[m] I mentioned focalPoint, Emoji, and featured on the issue tracker
#
nightpool[m] there's been cross-implementor support for standardizing a migration flow
#
puckipedia like, the extension process page is decent as for how extensions will end up being implemented possibly, but I think e.g. formalizing something more based on experiences on ratifying a few extensions separately first would be best
#
nightpool[m] well then we should actually do those things
#
puckipedia agreed
#
nightpool[m] but i think that having a json-ld context extension implementation guide came about because we were very unsure on how to procede on a technical level
cwebber2 joined the channel
#
nightpool[m] but for over a year now this extension process has been a blocker to actually talking about extensions
cwebber2 joined the channel