Meeting minutes
<acoburn> Scribe list
Introductions and announcements
acoburn: starting with intros and announcements...
… anyone new to the group?
otherJackson: Hi, I am Jackson Morgan - I met a lot of you guys previously, have been around the Solid ecosystem for some years
… excited to get invovled in spec work again
… as an invited expert
acoburn: Jackson did write much of the Primer around Solid-OIDC, so he helped making Solid more accessible
… any anouncements?
- silence -
… at the end of the meeting, we will have a discussion around the editors of the spec - so we can revisit the discussion from last meeting
… main point of today is the protocol specification roadmap
Action items
acoburn: hadrian is not here today, so we will skip that
… Pierre-Antoine, do you have an update on the tooling?
pchampin: not really, hopefully there will be an update next week
acoburn: no other specific actions
Protocol specification roadmap
acoburn: Let me post a link
<acoburn> Current protocol draft
acoburn: and now over to Erich and Jesse. This document is a draft, it is a skeleton, it is likely to change, there is no normative text anywhere, it is a number of general categories that we think are relevant
eBremer: I ll share my screen.
… this is meant to be a starter for discussion
… nothing is meant to be normative. if it is, that's a mistake
… any changes will be done via PRs, please contribute
jeswr: Let's go through the doc and list the categories ...
eBremer: goes through the list... points out the REST Binding
uvdsl: what is the reference point for the binding? or is that a suggestion
eBremer: this is a suggestion, still up for debate
uvdsl: could we have more documentation about this approach
jeswr: let me provide some context
… this section allows us to define operations, and then in the binding section
… we can have the concrete HTTP methods explained
… separation of that means, that we can reference the abstract operations instead of the HTTP method itself
… it should be a presentation thing, that should make reading easily,
… and if we decide that we want to have more other things like GraphQL, or other enterprisy mechansims, then we can do that
… but we are expecting that we will have HTTP first and foremost
pchampin: Just to point out, we are not in cruise speed - uvdsl, please feel free to open an issue and explain why this needs more discussion, as an anchor for discussion
uvdsl: thanks for pointing out the path forward, I would appreciate having anchor points
… in case someone asks whether something has been discussed
… a more stuctured approach would be helpful
<Zakim> acoburn, you wanted to mention future proofing
acoburn: one of the considerations: there was a conversation in the group (no reference rn), whether we would be using DID methods or just HTTP methods.
… there were concerns that we should not say the LWS protocol should use HTTP which then would hinder DID methods in LWS
… and there was some agreement [citation needed]
… and this would hinder adoption/adaptation in the future
… so we wanted to go for a loose coupling
… nobody argues that HTTP is not central to LWS but still it should not be a hard coupling
jswr: To the roadmap of the spec document, and also on how we can best engage the group in this and make progress
jeswr: the order of the sections
… we are not going to work in ordering in the document
… we propose to work on the categories ordered as we expect consensus to arise, so starting with the lesser ones and then progressing to the ones that need more discussion
… e.g. maybe starting with resource identification
… probably using HTTP but maybe also discussion DIDs
… Next area, would be operations
… CRUD
… once we got resource identification and operations defined, then we could work on Section 9 - bindings for REST
… to bring together what combination of resource identifiers and operations
… If there are other topics that anyone would like to adress earlier
… that would be good to know
… so probably open an issue
… to have that discussion
… the work will be done via PRs
<jeswr> w3c/
<gb> Issue 18 Research Topics (by jeswr)
jeswr: we would like to set up streams of research
… to get a clear understanding of prior art
… in the Solid ecosystem and outside of the Solid ecosystem
… we want to create a Wiki of all of the prior art
… to have reference points for discussions
… It would be great to have certain individuals who want to champion certain areas
… send an email via the public list
<Zakim> gibsonf, you wanted to ask if discovery section is where search/query etc would be covered?
jeswr: yes, probably search goes into Discovery
… something like type index
… query would be a more heavy weight discovery mechanisms
… lots of different options for query
uvdsl: regarding research streams, in coming from the solid community, there have been discussions on all of these topics
… might be good to reach out to community group
… there are experts in the Solid group already
… engaging and reaching out to these experts would be good
jeswr: 100% agree
… having the champions on the topic, would more be in that direction as a gatherer, not doing the research themselves
<Zakim> acoburn, you wanted to mention invited experts
acoburn: Just to mention, this is a perfect example of inviting expert , or having guests come in,
… this is something that the W3C Process affords us
… there are alot of experts here already, but we can pull in more as there are more outside of the group
otherJackson: Are the headings locked down in the spec?
… and, will more things be added? - or is this it?
jeswr: This document has been fairly bootstraped
… sections can be added or removed
… as the group comes to consensus
… the provenance discussion had been earlier in the group [citation needed]
… and the agreement [citation needed] was that provenance and such things would be good to have
… but these things would need to be incubated in a CG and then brought in to the WG [citation needed]
otherJackson: So for the research streams, this is only prior art, not inventing something new?
jeswr: yes
<Zakim> ericP, you wanted to say that the spec (index.html) is in the root of the repo vs. lws-ucs, which has them under /spec
acoburn: To add: but not only from a WG! e.g. WAC is just CG
ericP: the document is in the root - before people clone the repo, do we want that? or should it under /spec?
… anyone an opinion?
acoburn: if anyone does, please open an issue
<Zakim> gibsonf, you wanted to ask about research, would this include documenting how existing implementations are using WAC (such as TrinPod) or Discovery?
ericP: sooner better than later, before too many people clone it an open PR
<pchampin> will open an issue -- I think having it under spec/ is better ;-)
gibsonf1: Adding to jackson's question on the research streams
… we had to modify the algorithm to evaluate WAC, and have it working, should we have that in the prior art as well?
<ericP> pchampin, do we want to effect the move in this meeting before it causes more trouble?
jeswr: For each prior art, e.g. WAC, what we want to identify are capabilites and limitations - and the implementation experience would fit into limitations. The specifics of how you fixed WAC is not too important right now, in order to inform the decision for the spec
… it would be good to know what limitations there are
gibsonf1: the limitation wasn't WAC but the discovery mechanism present in Solid
… on hierarchies for agents
… there were discussion around vcard and hierarchies of agents in the Solid channels
acoburn: interjecting - maybe we should not go into the details here, on the issues that Jesse opens, stay highlevel and mention issues
… lets avoid going into rabbit hohles
jeswr: and link to the discussion!
eBremer: Wanted to add my sentiment on bring in people from e.g. the Solid CG
… I agree
… do bring them in!
jeswr: this is it for the roadmap
Editor selection
acoburn: Just so folks know: there will be more discussion on this
pchampin: as acoburn mentioned, there was a lot of dicussion on the appointment of the spec editors
… there were concerns that the editors did not publically volunteer
… there was Sarven who volunteered
… publically
… and following up on the call for expressions of interested
… these did not need to be public ... might also have been private
… which did not seem like a problem
… so I was surprised that this became an issue now
… There was another issue around that the decision was made behind closed doors
… the W3C is alot about openess
… but not everything needs to be open
… such as the decision on the chair
… choosing one individual over another is a sensitive discussion
… which maybe should not be in the open
… the discussion itself .... but the decision is in the open, just as in the last meeting
… the main concern is - as pointed out last meeting - that the group of editors should be a group who works together
… and if things dont work out then this gets reverted to the group
… for example, I had private discussions with Sarven, where we exchanged opinions but I was seemingly not able to convince him that his contributions are still valued
TallTed: for those who havent noticed, Sarven did officially leave the group - in part because of this interaction
… the thought that having this partically behind closed doors being a feature is questionable to me
… but anyways, the way the interaction occured leaves a bitter tast
… there was no response or acknowledgement or follow up on the public volunteering of Sarven - which I think should have been public as well
… and then decision might have been in private, fine
… there were 2 volunteers with enough capacity and one who expressed that they have a full plate
… still the choice as is
… but still the style of interaction was poor
… some discussions can be behind closed doors but the publication should have been an email - not being said in a meeting
ericP: what should have been different?
TallTed: Be clear about how things will work. Public nominations in public or private, private selections in private
pchampin: Thanks Ted, I insist that the process was followed - I did not say that the interaction was good - this should have been handled in a better way - and I hear that many individuals feel that this could have been handled better
… I just want to say that we are not going against the process - not taking away from the style of interaction and how people feel about it