Skip to content

Latest commit

 

History

History
196 lines (152 loc) · 15.1 KB

2023-08-09.md

File metadata and controls

196 lines (152 loc) · 15.1 KB
Raw

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • Wouter Termont

Introductions

  • name: text

Topics

  • SC: These first three are some editorial issues about the WG charter. Feel free to PR; we're not picking these up in the meeting.

Update mission

URL: solid/solid-wg-charter#7

Motivation still seems a bit vague

URL: solid/solid-wg-charter#44

Clarifying "Achieve Them" in Deliverables Section

URL: solid/solid-wg-charter#45

WIP Implementation Feedback

  • SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
  • SC: More on the future of this topic in Solid Demos and other dedicated meetings.
  • ME: Mentions https://teamid.live/ . I've been maintaining a new CSS instance there.
  • SC: Does the name imply anything?
  • ME: Not meant to steal from Microsoft, but we are collaborating, so to emphasise the team spirit.
  • eP: i think at some point we should have a directory of Solid services with reviews/checkmarks. Is this something you are writing or are there other contributors. What's its stability?
  • ME: It's mainly me. I can only promise my best. there is no organisation behind it.
  • eP: It's great that people are putting in effort. I just want to emphasise that great intentions bump into something that changes, and accidents that people drop services would be bad for Solid uptake. If people try Solid, we would like to have them still have it in a few years.
  • ME: We have only 5 or 6 users, but solidweb.me (300 users) and solidweb.org (3000 users) and ... have a great uptake. I will try to let it stay in the solidverse for as long as I can.
  • SC: ... you can put up promises for services anywhere on the site, so that people can be aware of the terms of service. (e.g. like solidcommunity.net)

Solid Demos

  • SC: Following https://github.com/solid/specification/blob/main/meetings/2023-07-19.md#solid-demos
  • SC: There is a special meeting noted for 2023-08-15 to dive into Solid Demos - not necessarily to present on that day but to explore this topic/recurring event.
  • SC: We want it to be a low-admin event where screencast can be recorded of everyone who wants to demo.
  • SC: We can come back to the exact timing if it does not suit someone.
  • SC: There is a "Call for Group updates and Technical Demos (videos)" at TPAC2023. It is suggested that we showcase the work done in the Solid CG by creating a short video to be published on the TPAC2023 website. Videos are due by 2023-08-30. More details to follow, but there are Best Practices for Recording Videos.
  • SC: We have two separate cases to communicate/demo: 1) general (representative) CG work, and 2) specific use cases or interests.
  • eP: It may be easier to have a playlist of videos, containing demos, than to coordinate a single video.
  • SC: Sure, both work. Just share the link of prerecordings with the group.
  • SC: For the time being, I suggest everyone self-publish their screencasts, and share the URLs with the CG. These are good assets. We can find a home to refer to those links. More details to follow; for instance, make sure the URL is publicly archivable by the Internet Archive.

Special Topic Meetings

  • SC: Tentatively on Tuesdays starting at 14:00 UTC with duration 1 or more hours depending on topic and participants. We can reserve a 2h block in the CG calendar.
  • SC: Security flaws in OIDC spec, based on interaction with Ross Horne in chat.
  • SC: Upcoming:
    • 2023-08-15: Solid Demos.
    • yyyy-mm-dd: Security flaws in OIDC spec.
    • yyyy-mm-dd: Implementer Feedback meeting.
    • yyyy-mm-dd: Reorganizing github repositories related issue.
  • SC: Let's organize the order/time in chat.

Security flaws in OIDC spec

  • RH: My though was to introduce it in the chat and see ...
  • SC: That's good, those who are interested can join in. We are slowly changing from panel meetings to special topic meetings.
  • RH: We need to gather the right meeting. At some point, we might still address this in five minutes to the community as a whole.
  • RH: Do you suggest this is just a series of meetings, instead of a special group.
  • SC: Yes, for now just one meeting. We don't really have panel meetings happening anymore for the most part, so we just raise interesting topics to solve by those interested.
  • SC: Let's continue in chat. The recurring meeting is Tuesdays at 14pm UTC. We can see who can make that, and maybe dip shortly into it at the end of this meeting.
  • eP: Would it be possible to first raise an issue on SolidOIDC repo, to organise this there?
  • SC: I think Ross preferred not to do that at the time.
  • RH: If anyone can maybe start it, and I can comment, that would be great. I can put it there.

Summary of Special Topic: Alternative solutions to container HATEOAS

  • SC: We had such a meeting on 08-08
  • eP: We explored the topic from different angles. No information was ended, but we explored how to tackle it. The main outcome was that we dove again into HTML, so I also want to incorporate that (i.e., to have an HTML representation of a container). Personally, I thought we would just need RDF description, and the problem was client- vs server-asserted statements, but the topic was opened further.
  • WT: Main conclusion IMO was: we started exploring how to solve this question of how to combine server-managed RDF source like a container with both client-managed RDF and client-managed non-RDF representations of the same resource. We had started on a decision tree that we answered affirmative/negative ways to see where it leads us.
  • eP: Just to clarify, Aaron also raised that we mostly focused on clearly presenting the problem, but the final decision lies with the Working Group. So it was mostly to gather the multiple overlapping conversations and providing a nice way to continue working on that.
  • SC: About that note, there is a condition on that (IF the working group happens). Even if the WG picks up this topic, it does not mean that any work done in the CG does not matter or is irrelevant. The WG will have to take that into account; even if that is a decision. So it is not that these considerations need to be put aside. If that were the case, we would not need a CG. Again, the WGs may limit voting/decision to its own members, but W3C is quite open to who can be part of the community to collect/gather information for these issues. The WG is there to process that information. I suggest that we make progress as much as we can, and if we see that it is a blocker, we can look into that.
  • SC: This topic has been around for a while and encompasses a lot. I do think we need to be careful, how much redesign is worthwhile, given some other things to do.
  • SC: If you want to continue on that in special meetings.
  • eP: I think we need to follow up in the issue, so that everyone is as well involved as can be, and then bring it up again in this meeting or a special meeting.
  • WT: There was this idea to have special task forces have a meeting on a specific topic apart from this meeting. Maybe this is an idea for that. Perhaps three more meetings?
  • SC: Sounds good, this is soft organization, communicate that this is happening.
  • eP: I would be cautious with tasks force, because it would take a lot of time (twice a month, plus github work). At least myself I cannot commit to work more on this than I am.
  • SC: I think that's fair. There is a lot of material to digest. Pavlik, can I ask you to raise a meeting to follow up.
  • eP: We'll track so in the issue.

Add W3C Solid CG Charter

URL: solid/process#323

  • SC: At this point we have an approval of the charter (at this point about a quarter of the active participants). Pierre-Antoine agreed that it looks pretty healthy. Thank you to everyone approving and making improvements to the charter.
  • SC: Effective on 2023-09-01. Pending licensing section (see next topic). Whatever that comes out to be, will be put into the charter.
More details about the PR
  • 37 days under review.
  • 22 participants.
  • 17 reviews and approvals, 0 change requests, 0 comments.
  • 4 thumbs-ups and 2 thumbs-downs emoji reactions on the original comment. Various exciting emojis throughout the PR.
  • 23 commits integrating feedback from the reviews, meetings, and elsewhere.
  • 202 conversations.

MIT License and/or W3C CLA and FSA

URL: solid/process#327

  • SC: A summary:
  • SC: The temporary resolution in 2023-08-02 CG meeting was to mention both MIT+W3C licenses in the charter, and to incorporate the resolution of issue 327 by 2023-08-31. There is no specific objection to using both MIT and W3C licenses.
  • SC: There are two change suggestions (let's call them the "short" and "long" version):
  • SC: The short version is closest to 2023-08-02 meeting resolution, and the longer version incorporates finer details of W3C requirements as well as recommendations for the ecosystem. We can commit one of these change suggestions now, and keep the PR open as previously agreed, integrating updates as we go until the end of the month.
  • WT: To clarify: as you said, it is not that the versions differ but they both say the W3C requirements and the context in which we've been working... like the deliverables that have to comply in the WG.

PROPOSAL: Commit the short version? (If long version is preferred, say so along with +0)

  • eP: +0
  • WT: +0
  • SC: +1 (to be on the "safe side" for now.)

PROPOSAL: Commit the long version?

  • eP: +1
  • WT: +1
  • LD: +1
  • eP: I see the long version safer. I think we often seem to disagree due to talking about different things to license. Having it detailed can help with clarity on what specifically is being discussed.
  • SC: The long version does spell out a lot of what is given. Clarity may indeed be better, provided that we're not introducing errors.
  • WT: I prefer long version, it repeats a lot of what is given by participation in CG. For some people it might be the first time they get chance to read those details. Having it here might be more accessible than going through W3C licenses. We still have 3 weeks to fine tune the text.
  • SC: That's a fair point. The long version also clearly gives people a point to respond to for people objecting to them.
  • SC: We have more pluses on the long version. Any objections to accepting the commit of the long version? If not we can do so following this meeting.

RESOLUTION: SC to commit long version.

  • SC: There is a request to have more (undefined amount of) time given so that a particular participant can review "legal implications with respect to change in the contract of their contributions."
  • SC: There were a few responses to that but I haven't seen response back from the original commenter.
  • SC: We can still benefit from Rigo's (W3C Legal) advisory but they're out of office. TimBL is "out of office" as well. PAC is out of office.
  • SC: Corrections or additional information is welcome! So are objections — please provide details/follow-up on issue 327. Be clear about exactly what part of the licensing is an issue, including objections to forming a Working Group, which will necessarily take on MIT-licensed CG work and use W3C licenses anyway.
  • WT: The license section is kept open indeed because people can look into it longer but I'm curious to see what they're looking into because we don't have any code besides test suite in the CG repos. What would change for the worse using W3C license for that particular organisation?
  • SC: I want to come back to the timing of things. We can benefit from Rigo's acknowledgement. What we have seems safe as far as the charter is concerned. But have Rigo double check could be worth waiting for.
  • SC: We can still be effective on September 1st and update the license details if needed.
  • eP: We are about the end of the meeting. I suggest for the next meetings we slow down on the charter, to prioritize more technical matter. We've been doing a lot of chartering over the last few months.
  • WT: +1
  • SC: +1
  • SC: Given the amount of time and resources, I agree it's time for other things. That said, we needed that time for the two charters.

Rename 'Server' to something more specific — 'Resource Server' or 'Storage Server' or ...

URL: #548

  • WT: On a slightly more general note: I started a document comparing the shared definitions of all current reports. Can we have that as an organic definition document to refer to? Will create a PR (where?).

Return ETag headers on PUT requests

CommunitySolidServer/CommunitySolidServer#632

  • SC: Let's have additional eyes/minds on this. Cases in which the ETag header can(not) be used in PUT and PATCH responses. Potentially introduce a requirement or add advisory in Solid Protocol.
  • WT: What is the added value for the Solid ecosystem, on top of the affordances already provided by HTTP?