# W3C Solid Community Group: Solid Editors * Date: 2021-10-06T13:00:00Z * Call: https://meet.jit.si/solid-specification * Chat: https://gitter.im/solid/specification * Repository: https://github.com/solid/specification ## Present * [Sarven Capadisli](https://csarven.ca/#i) * Kjetil Kjernsmo * Justin B * Dmitri Z * Tim Berners-Lee --- ## 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. * Use panel chat and repository. Queue in call to talk. ### Participation and Code of Conduct * [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) * [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) * If this is your first time, welcome! please introduce yourself. ### Scribes * Sarven * Justin ### Introductions * name: text --- ## Topics ### Triage and prioritization * KK: Objective: Have a clear prioritization and commitment of resources for issues to work on for the next month. * KK: Use the list of nominations: https://github.com/solid/specification/labels/status%3A%20Nominated and based on commitments of resources add to the Monthly Milestone: https://github.com/solid/specification/milestone/5 ### Ad-hoc meetings * JB: Let's coordinate better on ad-hoc meetings. * KK: There were only 4 people that responded.. so, it didn't happen. * JB: We also talked about issue-specific.. but at least this one what you and SC were doing this morning.. was background prioritisation and grooming. Should we have a monthly cycle that's dedicated to that.. it'd be longer. Sounds like needed? * KK: Yea, needed. We spent 5 hours today. But for monthly cycle, yes. * JB: Figure out a meeting for monthly cycle. * KK: +1. Background grooming session * SC: General agreement. No objection. * TB: If there are issues for the version of Solid on NSS and in the databrowser and in CSS when wwe have the auth-upgrade software in the open source stack. That version of Solid is highest priority to document that. So, any discusion.. basically.. so long as the things we selected... we can spent time on grooming.. but if we don't have it worked out for that version of hte release.. then we are wasting time. So check off anything that's not required for the next release. * KK: That's what SC and I did.. it is in there now. They go in the milestone. * KK: Things we need urgently. The problem is we don't have committed resources besides SC and I. What is it that we can achieve within a month? Tough on ourselves.. assigning stuff to ourselves. * TB: Do you assume when you talk to .. when you lookup Websocket spec.. do you assume that you will get time from people that coded it up, like Aaron. * KK: When it comes ot WebSockets.. that's outsourced to notifications-panel so. * JB: Want to ge ta clarification on the versoin that Tim is referring to and the one you're referring to KK. It seems different. * TB: I want WebSocket for Solid 0.9 or 1.0.. So fallback to old addage. If it is not in NSS, then it is future Solid. We did get the auth upgade which was massive. THe interop that we get.. for the auth upgrade.. there is huge amount of stuff we can do but all that stuff in the data browser needs websocket.. so we can't .. i propose a midnight effort.. KIDNAP Aaron over a drink.. (Scribe does not approve this.).. just exagerrating. Treat WebSockets as a security issue. Current Solid in the spreadsheet is insecure websockets.. then solidos breaks. This it the latest solidos it has the latest auth upgrade. So, current solid we need to standardise need not. does that make sense? * KK: There aren't a lot of stuff that deviates from NSS. I know this from the test suite.. which is not complete * TB: Which? * KK: Mostly the one I created fro mthe back in the day.. most of that is ported. But there isn't things clear.. we are not trying to make Solid different than NSS. Because I wrote a lot of the nsS code as well. so know it fairly well.. so the main problem that we are addressing is more around the corner cases also where things are unclear. * DZ: 1) big +1 to narrow focus on getting the versoin and iterating.. questoin: would it be overkill to do feature detection / protocol versioning.. to ask which spec I'm talking to? * TB: For WebSocket.. it makes sense.. are you saying that for the whole protocol? ACTION: Schedule a monthly backlog grooming session each month to coincide with the specification cycles ### Feature detection * DZ: if we are goin to version.. socket.. what to do * JB: I tihink they are closely related. +1 to feature detection.. as versioning is an element of that. notifications protocol considers versioning. id be fine with these pattersn. we are now incorporating shapetree validation to demonstrate that. eg. does this server do <> validation on the server side or not.. and just have a pattern to utilise for this. what i like about .well-known for precident .. * TB: mashlib has a json object that captures the npm version bits.. does like an npm list into .. and actually captures that as actually code. when debug'd. when you do it for the server, the software modlues would be linked. people can of coruse thell you that's a security liability.. we need to figure out which version of the protocol.. does this have this sort of thing. the high levle would be like solid protocol level. * JB: the may alone wouldn't tell you. * TB: everything should be must. more or less. * JB: for a spec with musts, some of those implementations may differ because of configuration? im' not arguing about versioning.. but we may want to provide more info then that. * TB: we should have an RDF graph to pull all kinds of stuff * DZ: can we do conneg for it? * TB: what i propose for now is if there is no version.. it is 0.9. but for 1.0 we can put the version. ### Should the server always advertise the owner link relation? URL: https://github.com/solid/specification/issues/266 * TB: I propose to remove 'owner' from milestone. it is icing on the cake Shoudl the server always advertise the owner. * TB: What is crucial was because of damage control.. the owner gets implicit control. there is no code that discovers the owner.. users use the fact that they can fix their acl files. it'd be useful for the next version. not urgent. * JB: This can be clear if we start by saying.. if we use versions as a guide. What's the goal for it. There is probably a mental struggle between what the next version is going ot be and the one after that. The reason there is a lot of stuff here is perhaps because they are raised because of activity etc.. but TB wants what out in the field.. useful for user community. * SC: owner advertisement is currently not MUST in Protocol. it can wait. ACTION: Remove 266 from milestone. ### Discover of storage URL: https://github.com/solid/specification/issues/310 * KK: Hard for tests.. and I'd like it to be testable. * TB: Any code needs it? * KK: My tests need it. I can't test the spec as it is. * TB: blocker for you on the test suite.. but can't you pass the storage as a parameter? * KK: There are things that can be done there.. when we get to it we can consider what can be done. * TB: but NSS get by it without it today. * TB: I propose we remove it from 2021-10 milestone. ACTION: remove from 2021-10 milestone. * JB: Just to clarify what's nominated.. I'm having a hard time following.. in or out what? my guess: tB you are talking about immediate . * TB: NSS and CSS * JB: So that's 0.9 today. That's totally fine.. and I think we need to organise something based on that.. and apply that to the nomination process. * TB: we never challenged these milestones.. * JB: we haven't identified what should go where. * TB: The spreadsheet is a guide for that. It hasn't got numbers on it .. i'd say "yeabut". we need remove things from the list so we can get the things out.. * KK: ... so NSS and CSS deviate on some things. many of hte thigns that are prioritised are because of the test suite.. the TS tells me where they go in different directions. if no TS, then there is a lot of work to determine whether we are describing the behaviour that we see. that's one of the reasons why we emphasised the TS. * KK:... on the other hand, solid/test-suite is testing the "good path". we could use that as a guidance. that is a possibility. but to align with the spreadsheet.. we can cut down quite a lot e.g. sparql update is clearly in.. the container listing stuff is in.. other htings eg. solid server is compliant if it doesn't provide Write methods. write is optional in the current spec. i don't agree wit hthat.. so that's one of hte issues with that. ### Write methods as requirements URL: https://github.com/solid/specification/pull/304 * TB: that is a philosophical thing.. from the branding point of view.. whether we allow people.. you mean if you have a public data.. * TB: I don't find this.. a useful discussion. it is too philo.. doesn't effect protocol or code. i would suggest * KK: the problem is we need to redesign the test harness around that problem because it effectively makes everything around write operations a may. * TB: no no no..it doesn't. * SC: [explains issue] * TB: Keep in milestone. ### Face To Face meeting * KK: Need to have a more high-bandwidth conversation around issues. * SC: Suggest to start with people showing up to online meetings.. and then try having a full day meeting.. and then if we still need more engagement.. consider F2F. ### New Editors URL: https://github.com/solid/process/pull/268 * SC: if Tim is present in meeting we can take this up. Related: https://github.com/solid/process#editorial-structure * JB: TB you felt that there should be more input before adding.. do you want to get that input.. for more time or another channel? * TB: process is not clean for confidentiality. PROPOSAL: Editors Team to discuss and propose the process on confidentiality for new editors additions. RESOLUTION: Discuss next meeting. ### Spec version and milestones * JB: It'd be good agree on 0.9+ * TB: we're close to it.. I propose to rename October to 0.9. * SC: Point of Oct milestone was like a homework for this month. * TB: 0.9 is really urgent. What I'm suggesting is.. lets close this by this version.. without diving into the details. * JB: let's come back next week. * TB: .. and put absolutely minimum. * KK: yea. always had that as a goal.. and also testable is important.