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

  • Pierre-Antoine Champin

Introductions

  • Sjoerd: we are PDS Interop, we do Solid stuff, created the Solid Nextcloud module/server
  • GH: for the few here who don't know me yet. I met late Henry Story 11 years ago, talked about Linked Data. We were involved together in multiple projects and start-ups, about Solid before it was called Solid. We have been mainly funded by the EU (Solid Control; Solid Wallet, previously Launcher app). I'm willing to continue even now that Henry's not here. Welcoming contributions from anyone interested. I have a background in economics, but always had an interest in technology. Willing to continue and connect the network of people working in Solid. Project should be finished by next spring. Difficult to survive and keep things going for open-source projects. I hope I can help gather the community. With more coordination, we could be more effective (avoid redeveloping the same small things multiple times). I have lived in multiple places: important to help communicate with various people.
  • SC: I know that you have been a member of this community for a long time. Henry was contributing to a number of specs and work items of this group; we need people there.
  • GH: I know the process, I can help in various places. I don't know if I could chair the group as well as Sarven, but would be happy to co-chair. Bridging the gap with non-tech people.
  • SC: happy to hear that, it is nice to have various background. We don't need to all have the same profile. When we have 3 chairs, there will be rotation in chairing the meetings. Some chairs may have different focus.

Topics

WIP Implementation Feedback

  • SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
  • eP: Time to talk about SolID OIDC. Version 0.1 has been published 1.5 years ago, still no implementation, except for the incoming Keycloak one.
  • SC: I would like to know where we are at re. Solid OIDC. Is the current editor's draft stable, or are there issues pending?
  • AC: +1 to eP, we need more implementation feedback. Surprised to hear that there are no implementation. Inrupt?
  • eP: I meant "no open-source implementation". I don't know what ESS is doing. CSS is only doing "global token" (?), I consider it as a pre-0.1 implementation. Issue for the client https://github.com/inrupt/solid-client-authn-js/issues/3181
  • SC: Could we update this: https://github.com/solid/solid-oidc/issues/19
  • AC: if there are no implementations, there may be reasons for that. Go back to requirements, mark features as at-risk, get feedback from implementers. Inrupt has an open-source Java client library that implements Solid OIDC claims-pushing.
  • SC: is it listed? Can you update the table?
  • AC: happy to.
  • eP: Was it discussed yesterday in Solid QA, are they ready to take leadership on that issue?
  • SC: no, it was not discussed. Solid QA can only gather test results from implementations. We do not track intents to implement or work in progress. We could integrate that but it would be a separate process.
  • eP: it would be useful to have signals of intent to implement (simple web form, as discussed yesterday on the chat).
  • SC: There is an index of applications and servers: https://solidproject.org/apps , https://solidproject.org/developers/tutorials/getting-started#own-server . The QA focuses on differentiating conforming from work in progress. It does not signal anything beyond that. If we were to invest more time for this kind of things, I want to make sure that there is synergy with what the Solid Team is doing, not repeating work.
  • eP: It is nice to have a basic list, but it does not tell much. Do the listed server implement storage, idp, authorisation, notification? We need a finer product class granularity.
  • SC: And that part belongs to the QA, and is already covered. Each collected report lists all the test-cases that an implementation passes.
  • eP: AC, I recall that you have written a test-suite for the issuer (OP aka. IDP). Is there an equivalent test for the client?
  • AC: only for the OP. Would be more complicated to make one for clients, but that would be useful for developers.
  • SC: we need to take Solid QA seriously, it is at the core of what we are doing. We need to prove that implementations are conforming with the specification. This is not a requirement for CGs. This work was for the WG to be able to advance on this, and prevent objections. Please let's create more energy around that.

Joint Solid CG and Social CG meeting

URL: https://lists.w3.org/Archives/Public/public-solid/2023Oct/0036.html

  • SC: Thread also at https://lists.w3.org/Archives/Public/public-swicg/2023Oct/0060.html
  • SC: There is interest from participants in both groups. Let's make it so
  • SC: for example, the Linked Data Notification developed by the Social Web WG was done with collaboration from MIT at the time, and is compatible (and used) by both Solid and the Social Web people.
  • SC: the work of each group is not conflicting with the other. E.g. Solid Protocol is about client-server interaction, while ActivityPub focuseS on server-server federation. A given server could possibly implement both.
  • SC: SocialCG's meetings are on Friday. Our Tuesday (Special Topic Meeting slot) may be best.
  • SC: Any thoughts, suggestions, concerns?
  • eP: it might be useful to have a short pad for drafting topics, so that both side can prepare the meeting. Would make the meeting more productive. Example: authentication/authorization, media-types. About the server-server interaction: one of the server sometimes just acts as a client. All this could be prepared in advance.
  • SC: we did this for WebAgents. I agree we can do that. Authentication is a tricky topic: there are at least 4 ways how it is done (Fediverse, IndieAuth, Solid, ActivityPub).
  • GH: It is so much wider. IETF people working on HTTP would also be interesting discussing with. I'm not saying we invite them all together, or a conference-style event, but may groups might be interested in joining this.
  • SC: HTTP-Signature is also used in Mastodon and Solid. We need to look at the details.
  • eP: Solid is really focused on REST, while ActivityPub is more event oriented. In the Fediverse, many people use a client to interact with their own server only. In Solid, a given client may interact with many different servers. We should discuss those different approaches and the ideas behind them.
  • Hadrian: there are differences, but I don't see them as "fundamental".
  • SC: whether we discuss these topics or not with them, it is good to discuss them here. It was quite a difficult topic in the Social Web WG we won't solve it in one meeting!
  • SC: I'll see if our Tuesday meeting can work for them, as it is a 2h slot. I'll follow up on the mailing list.

Updating Solid EDs SotD to remove Solid Process

WG Charter PRs from Reviews

  • SC: We are over time, but the following PRs on the WG charter are mostly editorial. I would like to get rid of them. I'll assign them to PAC, and he can merge them if there are positive reviews after a week since their creation.
  • SC: https://github.com/w3c/charter-drafts/issues/461 relates to https://github.com/w3c/charter-drafts/issues/459
  • PAC: thanks for bringing that up to the more general level. However, regarless of whether this is integrated in the template or not, I would prefer to keep it in our charter. Every charter discussion is different and justifies adjustments to the template. As for "It goes without saying", it could be counter-productive, but I want to emphasize the fact that we do not consider this as a "gift" that we are doing we know that this is how things are supposed to be.

extend timeline

URL: https://github.com/solid/solid-wg-charter/pull/57

clarify position wrt to other processes

URL: https://github.com/solid/solid-wg-charter/pull/58

add liaison with IETF HTTP WG

URL: https://github.com/solid/solid-wg-charter/pull/59

URL: https://github.com/solid/solid-wg-charter/pull/60

Solid CG Chair Election Procedure

URL: https://github.com/solid/specification/discussions/582

  • HZ: as a volunteer, I took a snapshot of the participants list, with a link to the Wayback machine.
  • SC: the list that you have is not accurate, it includes anybody. The procedure requires us to have only one participant from each affiliation. That's the part that I am trying to iron out with W3C staff at the moment.
  • HZ: then the procedure we agreed upon last week is not correct.
  • SC: the text says "only one participant per affiliation". Does the list you have comply with this?
  • HZ: I have a list of all participants, with affiliation. That's the only thing that W3C is providing. We can refine this list to make it compliant, but do we want every volunteer to do this independently?
  • SC: I would rather produce the list with W3C, and send it to each volunteer for them to check. We can go different ways: each organization chooses one representative voter (difficult); we pick one at random (not reproducible)
  • eP: how many case do we have of multiple participants for one affiliation?
  • SC: I don't have the numbers, but we have several.
  • eP: suggest to reach out to the concerned organization.
  • HZ: Not all lists have the affiliation mentioned (API list does not, web page does).
  • SC: I would rather wait until I have contacted W3C staff.
  • HZ: So we don't have a choice but to delay deadline?
  • SC: Right. Perhaps 2023-10-25.

i18n and n11n of resource identifiers

URL: https://github.com/solid/specification/pull/575

  • SC: All, please review.
  • SC: Didn't get a chance to review but very interested in us getting this (in one shape or another) into 0.11.0.

Solid Protocol Version 0.11.0

URL: https://github.com/solid/specification/milestone/7

  • SC: Let's make sure to add any missing issues/PRs that can reasonably make it into this release. The ED includes class 3 and higher changes, and some in the pipeline. See Solid Protocol ED Changelog.
  • SC: Unless there is new information to discuss, I suggest we keep this topic short and only for awareness.
Select a repo