# W3C Solid Community Group: Weekly

* Date: 2023-02-01T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* [Arthur Joppart](https://github.com/belgiannoise)
* [Wouter Termont](https://github.com/woutermont)
* elf Pavlik
* Tim Berners-Lee
* [Ted Thibodeau](https://github.com/TallTed) (he/him) (OpenLinkSw.com)
* [Matthias Evering](https://solidweb.me/testpro/)
---

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
* 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
* [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/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Virginia

### Introductions
* name: text

---

## Topics

### 2023-02-08 meeting
* SC: I can't make it to this meeting but I can prepare an agenda.
* SC: VB will moderate/chair the meeting.

### Matrix for CG Chat
URL: https://blog.gitter.im/2023/01/16/gitter-is-going-fully-native-matrix-in-feb-2023/

* SC: Gitter is moving to Matrix on 2023-02-06.
* SC: Some considerations and discussions:
* https://gitter.im/solid/specification?at=63d817920c94855213d77fb4 and after.
* SC: Any objections to stick to Gitter->Matrix transition?
* SC: I don't know some details: what happens to URLs, does it redirect.. what happens to current admins of channels. If anyone knows anything about these considerations, please share so we can be prepared.
* SC: I posted on the channel about why sticking to this change is simpler. If there are other approaches, please share.
* WT: I support that, sticking with that plan.
* PAC: Just to mention I have never used Gitter, other than via a Matrix client, works fine.
* SC: W3C also have Matrix available but doesn't seem active. some working groups made that move long ago, but general channels seems nobody is really using.
* TBL: Do we have any alternative?
* SC: Only alternative proposed is Solid Chat but there are questions around that: how ready it is, how much support it will have.. Roadmap to switching is a separate topic.
* TBL: We need to have a roadmap for using Solid Chat.
* TBL: You can get notifications on a webpage (on Solid Chat ???).
* SC: Since this change is next week, and moving the CG needs planning, I want to look at the simplest thing right now. If there are any objections to let the switch however it happens to go through.
* TBL: We need to switch the logger
* SC: That's not a dependency of CG. That's Solid Chat's TODOs.
* TBL: For the community to move to Solid Chat.
* SC: To wrap up: on Feb 6 Gitter is going to do something and switch to Matrix. Can we just roll with that and use Matrix? Some people are already using it.
* TBL: If you go to gitter will you get a Matrix client?
* SC: That's going to route you using the Element app.
* TBL: Will Gitter be a Matrix node?
* SC: I think it is already because people are able to see.. at least there's a bridge. I assume they will preserve existing channels.
* WT: Yes, it will remain as a Matrix node so if you go to gitter.im you will arrive at the same node.
* SC: What happens to existing roles/accounts? I have an account on Matrix and I'm an admin but I don't have admin permissions to the bridge node on Matrix.
* TBL: There's a whole structure on GitHub ???
* eP: My guess is they will do their best not to break things. I expect glitches earlier but think the transition will be smooth and you won't have to do anything. Is your Matrix account linked to your Gitter account?
* SC: It's a separate account.
* eP: Then I wouldn't assume you have special privileges.
* SC: I don't know who has admin permissions.
* SC: Are we good to go ahead and see what happens?
* TBL: I think the answer is yes.
* SC: Then let's resolve.
* eP: (from jitsi chat)
* To be clear: Gitter will not be going away. All of your Gitter rooms and content will be accessible via Matrix and the gitter.im
* homeserver will continue to live on and be open for everyone to sign-in, interact, and chat like normal. Gitter has effectively been uploaded into (the) Matrix!
* "Because we will be invalidating all access tokens on Gitter, this means that any bots/scripts that use the Gitter API will stop working. You can prepare for the new Matrix world by adapting your code to use https://spec.matrix.org/latest/client-server-api/
* You won’t have access to all of your Gitter data to test against before the cut-over but testing against your own Matrix sandbox room should be sufficient for any use case."

### Solid-based chat for CG Chat
* SC: We can work on a plan to use a Solid-based chat for the CG. Some discussion:
* https://lists.w3.org/Archives/Public/public-solid/2023Jan/0015.html and thread.
* https://gitter.im/solid/chat?at=63d95207fb5fe8552e594d49 and after.
* SC: Thoughts?
* SC: Solid OS Team Chat: https://solidos.solidcommunity.net/Team/SolidOs%20team%20chat/
* SC: There are questions about features and how suitable it is, how much support it will have, who owns the storage.
* eP: I do support having further down the roadmap switching to Solid. I have two requirements: official storage is solidproject.org, and that there are at least 3 clients and at least one of them works on mobile.
* TBL: If it was on solidproject.solidcommunity.net, would that work?
* eP: We can discuss but I'd like solidproject.org.
* SC: I think what's important is the commitment to ???
* TBL: solidcommunity.net and solidproject.org are both maintained by the Solid team.
* SC: We discussed some of that on Gitter yesterday, but I want to acknowledge eP's suggestions and requirements. But all that we should have written down and revisit.
* TBL: is it okay for mobile app to be a web app?
* eP: a Progressive Web App works fine.
* SC: Can I ask for this to be passed on to the Solid Chat team? Can the team document what's possible and what they're willing to support with?
* TBL: We have one in SolidOS, Jackson made one..
* SC: Would you put this on SolidOS team agenda? Or should I join a meeting and suggest?
* TBL: Maybe make an issue in SolidOS to create a proposal.
* SC: Ok.

ACTION: SC to create an issue on SolidOS to create a proposal for Solid Chat.

* WT: I wanted to confirm that I think this is not a priority for CG/WG. If we have a chat that works, it works, and if it's to be a showcase of Solid, which I would support, then I think it can't just be one central chat client over one server storing all the data. we should have multiple clients by multiple developers with data storage in user's pods for it to be showcased at all.
* PAC: Regarding the distribution of the data, I understand it is important to demonstrate this in a Solid showcase app, but it raises the question of archives, because I expect personal pods might come and go, and do we accept the drawback of losing a part of the conversation? There's a tradeoff.
* TBL: If you look at IRC chats on W3C there are RDF descriptions of IRC chats going back for 25 years. When solid chat runs it just creates the archive ??? . As people chat it adds messages into the archive directly. So with chat systems there is the question of how to archive. With Solid Chat the archive is the chat. At the moment solidproject.org has a persistence policy for the TR space and we can make a persistence policy. Once you write a chat into Solid chat, that URL of that message will be available forever.
* SC: Is there an authoritative version of a message? Is it one storage that has that?
* TBL: At the moment a pod has it, yes.
* TBL: You can keep synchronized copies of that chat.
* SC: Maybe it needs to be on solidproject.org or solidcommunity.net
* eP: When it comes to data distribution I agree on a chat room on a single storage. At the same time I think each user should be able to create chats within their storage. Replication would be an extra, nice to have.
* TBL: with solidOs you can create a folder in your pod and put all kinds of things including a chat and that use access control systems to give groups access to them. When you look at someone's profile at the moment there is a "chat with me" button that creates a chat between the two of you.
* WT: I don't think it is a problem to store a chatroom in a single pod, but we cannot depend on this choice of one ??? a chat based on Solid would be a perfect choice that we will encounter limits on interoperability as soon as we try to chat implementations to work together. It is not the case one follows the other in the way they store data.
* TBL: The way we're working at the moment is that we are developing things ??? so the chat shapes, when the Oviedo students had as a student project to make a chat, they were given the chat shapes so that the requirement was that it will be compatible. So when Jackson made a chat, that is compatible I think. What the Solid CG could look at doing is making those specs match. Taking those existing shapes we have putting them into some lightweight document that other people can see. we can argue/have discussions about whether ??? and whether you prefer a different ontology.. I hope that stuff gets standardized soon.
* eP: I think that ??? implementation should be independent, but this task force would focus on agreeing on shapes and then have a couple of different interoperable implementations in maybe half a year and have monthly meetings to coordinate in one place.
* TBL: If we can find people that would be great. The danger is we make a task force and nobody comes.
* SC: Let's start with the ACTION and get people to discuss.
* SC: I think people should be given an option of making a chat in their storage and send a copy to the central storage. Web Annotation has something where there is ??? I do this in dokieli. When you write an annotation, if you have a storage you can decide to put the copy of that in multiple places. If a document offers a shared ??? service and you have a storage you can use both or only one. I think the problem is not different for Solid chat but it depends on how these apps are designed. Whether to use one storage or offer people to write to their storage. Some of the problems are solved from other communities.

### Add Solid QA
URL: https://github.com/solid/specification/pull/495

* SC: Any comments here? Objections to merge?
* TBL: Where does this come from?
* SC: Part of the test suite panel work. Pete and Michiel are co-authors and we have open meetings. Also based on W3C QA work.
* SC: Preview of Solid QA: https://htmlpreview.github.io/?https://github.com/solid/specification/blob/53cbcefa5a93c444ad40798d01f0fa1287e4d3d8/ED/qa.html
* SC: We're treating this as a spec in that we have some expectations from ??? so that we have a uniform approach .
* TBL: How dow e know it won't be too bureacratic?
* SC: I don't know. There is confusion as to what qualifies as a correct test. These are some rules as to what the reports should look like, what the test suite needs, etc. It's a work in progress. But the specification tests that Pete wrote does conform to most of this.
* TBL: There should be a condensed ??? so I don't have to read through the document.
* SC: Comments or question on the direction we're going with this?
* TBL: If this is what test suite folks are happy with, can you get someone to review it?
* SC: Both approved.
* TBL: It needs an abstract which summarizes what it describes, but I support.
* SC: Is this your review before merging or something you want to add to the PR?
* eP: This morning I joined a call with people working with [Keycloak](https://www.keycloak.org/). Justin and JaneiroDigital are working on adding Solid-OIDC and were asking about test suite. It'd be interesting to work with them, someone who is not a solid insider to implement a solid spec and use test suite to provide the reports. Good opportunity to get feedback.
* SC: People are welcome to join the CG or if any existing members want to collaborate with them that's fine.
* eP: I'd expect that'll be Justin and maybe I will help.
* SC: Ok. I won't merge now.
* TBL: There's a person on the W3C team. He couldn't go to the ??? conference. He sat and read all the abstracts and said "now I don't have to go to the ??? conference" because he relied on the fact that the abstract can save you ??? if you have more time you can read through. Maybe you can get ChatGPT's eyes on it.
* SC: I'd be happy to be replaced by a script.

### Too Slow: Please provide Updates-Via shortcut to secure web socket address
URL: https://github.com/solid/notifications/issues/110

* SC: Call for response to questions 1-5 in comment: https://github.com/solid/notifications/issues/110#issuecomment-1406336400
* SC: Let me know if clarification needed.
* SC: Resolving this issue may help with the TR/2022/notifications-protocol-20221231 release, and moving that forward can help with the TR/2022/protocol-20221231 release:
* https://github.com/solid/specification/pull/491
* https://github.com/solid/specification/pull/492
* TBL: You said to look at two questions. Is one of those "is ??? always bad"? and the other one was about caching issues with metadata?
* SC: I can summarize. As I understood how people's assumptions are, I see no security differences with either two approaches. I am asking for people to point to me why is one less secure. It seems one of the approaches has caching issues that need to be taken into account. The HEAD response seems to have more of a caching issue than POST on a subscription service. No security differences, yes a difference in caching.
* TBL: I disagree that there is no difference when you have sensitive information in the URL. Anytime the client contacts the server sensitive information will be coming back ???
* SC: Both are authorized requests, if either are not they will get a 403.
* TBL: These happen thousands of times in option A and much less in option B.
* eP: Is this a roadblock for the PR or something we want to resolve for next version?
* SC: It is not but hoping it can help move. The PR is there and there are zero reviews. Only issue I can find to move the PR is either accept PR for next release or refuse this publication. People have different positions. If they want to battle out how it should work they should hash it out and come back to me. I don't see any security differences. The questions are there. Just need to be responded.
* SC: If yo;'re unauthorized to read ??? you will get a 403 and in that 403 you should not see the ??? revealing
* TBL: Right. The profile is topic resource. Aaron is worried about leakage of info because every authorized fetch gets ???
* SC: Whether the URL is the same for every response..
* TBL: Sensitive information goes too many times over the net for Aaron's liking.
* SC: That is not in the thread. Going over the wire, whether under TLS and so on, is exposed more.. that information is not in that thread so if that is something we need to factor in when deciding whether to accept or reject approach A, I'm fine with that. I just need to know.
* eP: We shouldn't make it a roadblock. My strong preference is we go with PR since this is an optimization. Not breaking anything in the PR.
* SC: I agree.

---

### Topic Proposal
URL:

* SC: Proposed by: