Skip to content

Latest commit

 

History

History
140 lines (106 loc) · 9.01 KB

2022-05-18.md

File metadata and controls

140 lines (106 loc) · 9.01 KB

W3C Solid Community Group: Solid Editors

Present

Announcements

Meeting Recordings and Transcripts

  • 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.

Participation and Code of Conduct

Scribes

  • Sarven Capadisli

Introductions

  • name: text

Topics

Change Reference to Solid-OIDC?

ACTION: SC to update Solid Protocol ED.

Change Reference to Solid Notifications Protocol?

ACTION: SC to update Solid Protocol ED.

  • SC: What about the current "insecure" WebSocket referenced in the spec?
  • TBL: Require both for the time being. Deprecate later.
  • JB: CSS implements the insecure version. CSS prefers to wait until something is part of the spec and then prioritised for implementation. I don't think the new one is supported yet but when it will be in spec, it will be prioritised.
  • TBL: You got to be realistic with these things. There are complaints about Web apps not being updated. For something like this, moving on from insecure.. there is a lot of chat where this happened which is being communicated ??? we haven't done a threat analysis with the insecure. Reasonable for us to do the proper thing. Keep the existing spec that currently works with ??? that does live update. New one doesn't work in anything.
  • SC: Pending issue 355 to be actually usable/interoperable.
  • KK: Set sunset date for the old one?
  • TBL: Hard to say. You don't know when things will be actually implemented.
  • JB: We got the new one in - existing spec said what will come. We just need to modify that language a bit. This new protocol has secure auth mechanism. We have two sections for notifications and live updates. I think that's a bit confusing. For WebsocketsAPI, we have SHOULD. We need to determine the MUST. IMO, Notifications Protocol is MUST. We had SHOULD because we didn't have secure. Maybe bullet as action items.
  • SC: Would it be sufficient to resolve 355 and then MUST Notifications Protocol.. or do we need the implementations?
  • TBL: Do you want a draft of this what the next version will say? "Solid Protocol 0.9.0 .. MUST do authenticated. And 0.9.1 MUST do both?"
  • SC: No. When 355 is resolved and Notifications Protocol leaning on it. We can MUST Notifications Protocol. No strong opinion on deprecating the other but shouldn't MUST for both.
  • TBL: SARVEN!!!! I got code.. There has to be a sequence for the transition. Need a period to support for both. Until in practice in the field people have moved.
  • JB: "Your apps are going to break tomorrow.. but if you care about the legacy one.. you have an acceptable amount of time to get there. This is in process..." Can we say server MUST support one or the other?
  • TBL: Then doesn't have to support either.. and break. What about MUST support one or the other but server must maintain the legacy.
  • TBL: SHOULD the old one .. MUST new..
  • JB: What's the forcing function to get applications supporting legacy notifications to change?
  • TBL: ??? upgrading to get there. If we have a year people are using useful apps, even with insecure protocol, it is not the end of the world. The timing of when it is all updated. It is not a huge threat.
  • KK: This is not necessarily spec work. Community outreach. We don't use the hard power of Solid editors..
  • TBL: SDKs will change. If they have the secure one.. and fallback on the less secure.
  • KK: Lets MUST on both.. and communicate to the community that they'll have to update.
  • TBL: At the moment we have 0.9.0. Should we now start thinking about 0.9.1
  • SC: I don't mind waiting on 355 to be resolved and then 0.9.1 MUSTs for Notification Protocol (1.0.0) to be actually useful/implemented.
  • TBL: I propose we make it clear in the 0.9.0.1 document that servers and clients MUST support the old version of live update, and then fork the 0.9 document to make a 0.9.1 document and in that we explain that (s) servers must support both and (c) clients must try the new one if available and must use the old one if the new one is not available
  • KK: I think that's unnecessarily complicated. We should rather just update 0.9.1 right now and it is a MUST for the old one. And 0.9.2 MUSTs both.
  • TBL: Linearise?
  • KK: Yes, rather than forking.
  • JB: We have a new one.. why would we make a version it doesn't include it?
  • TBL: 0.9.0 is a documentation of existing practice. It should already be clear.
  • SC: It already is.
  • KK: We shouldn't update the documents without changing the version. call it 0.9.1 and change SHOULD to MUST.
  • TBL: I'd be inclined to say that's a bug. If fixing that bug it should be 0.9.1 as you say, that's fine.
  • SC: -1 on changing legacy to MUST and deprecating later. Just move it down.. MAY.
  • TBL: Shame that we had SHOULD.
  • SC: Why not MAY?
  • TBL: Need to support old features as a MUST for some time until community uses the new one and old one out.
  • SC: Can we move on.. revisit next week.
  • KK: Pushback might be from some implementations.
  • TBL: Say in 1.0.0 you don't have to support the old version.

Add version scheme to Contributing Guide

URL: #407

  • SC: I can wrap up minor suggestions.

ACTION: SC

Test Suite Panel Charter

Require TRs in HTML+RDFa

  • SC: Must be Linked Data.
  • SC: All significant units of information (concepts, requirements...) MUST have a URI and description in RDFa.
  • SC: There are tools that's using this on some of the publications already as well as intents to use.
  • SC: I'm preaching to the choir but wanted to make sure we are on the same page.
  • SC: {reads the room} We are.
  • SC: Needs to be in CONTRIBUTING. No requirement on tooling/applications for the output.. No different than decoupling apps and data in Solid. solidproject.org will use a Solid server (CSS).
  • KK: Need to do that part of the prioritisation process.
  • JB: Not against at all. Think it is useful. If we need to do that in the CONTRIBUTING, needs more detail.
  • SC: It will. I held off on details until we agree. There is Spec Terms etc WIP that covers that. There are TRs/work items publish this way already and some in the pipeline.
  • KK: We've specification-tests using the requirements from the specs.
  • TBL: Agree with having URIs and the whole space connected.

Milestone / Roadmap / Prioritisation

Authorization

ACTION: SC to draft an agenda for a meeting/workshop on Authorization architecture/compatibility/convergence/features/framework/use cases

  • JB: +1

Data Validation

  • SC: +1
  • JB: +1
  • SC: Perhaps have a thin panel that collaborates with other CG/WGs