# W3C Solid Community Group: Weekly

* Date: 2024-11-06T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* [Sarven Capadisli](https://csarven.ca/#i)
* Tim Berners-Lee
* Erich Bremer
* Jessie Wright
* [Rahul Gupta](https://cxres.pages.dev/profile#i) (since 14:30 UTC)
---

## 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/w3c-cg/solid/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 Conduct](https://www.w3.org/policies/code-of-conduct/)
* 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
* Sarven Capadisli

### Introductions
* [name]:

---

## Topics

### Adding Solid Practitioners meetings to the Solid CG calendar
Proposed by eP

* eP: We have agreement and schedule. Chair were to have a conversation.
* VB: That did not happen but I have no objection. Can follow up with JZ re schedule and update calendar. One concern re agenda: want to have something in the calendar as agenda because if anything needs updating. Alternatively, for something fixed, people can look into it.
* eP: In Solid Practitioners repo, there is information about the meeting. Don't think the CG calendar needs to be updated every meeting for the agenda.

### Creating #solid-e2ee channel in Solid space on matrix
Proposed by eP

* eP: In the STM call on how to follow-up, the AU team uses direct emails. We suggested we can create a dedicated channel for exchange and coordination. They said they're open to it. Niko was also present (presenting NextGraph).
* VB: Can wait but personally think it is fine.

### Plans for DID focused meeting and scheduling it + inviting experts
Proposed by eP

* eP: Last week were discussing. Some people work on DIDs, e.g., did:web, maybe nostr too. We were thinking of using DIDs in Solid again in an organised way.
* SC: If people want to see the suitability of Solid DID method that is still there: https://solid.github.io/did-method-solid/ . Repo: https://github.com/solid/did-method-solid/
* eP: Since ActivityPods using Solid + NextGraph, ... we could have some mapping for HTTP and DID. They want to have interop to switch between them, e.g., Solid / NextGraph interface.
* SC: We should know the use case to know what people see limited in Solid protocol where people want DIDs. Also which of the methods or part of the system is useful. We did the solid method to have that mapping between http and did. People should bring those use cases forward.
* eP: Does it rely on DNS?
* SC: Not to my knowledge.
* eP: Let's document questions and have a meeting with whoever is interested.

### Bring your own domain name to Pod

* TBL: How about bring your own domain name to your pod? To help people to change service providers. And better change code to CSS.
* eP: Fully support this direction. Currently CSS is not designed to support it. At this point it needs a new instance for a domain. Probably a major release to have that feature. Interested in collaborating.
* TBL: It may need to be anothe config option in CSS. In Apache, you can have it as a virtual host.
* eP: I can take an action in CSS to bring it up.
* TBL: There is a [roadmap](https://solidproject.solidcommunity.net/Roadmap/) item in the Solid ecosystem: https://solidproject.solidcommunity.net/Roadmap/state.ttl#Iss1606741599846
* SC: Also a lot of migration related issues and intitual specs and implentation in solid/specification e.g., https://github.com/solid/specification/issues/462 , https://github.com/solid/specification/issues/474 . As well as [storage provisioning](https://github.com/solid/specification/issues/317). Let's revisit these.
* eP: Also in Social Web CG.
* SC: LOLA: https://swicg.github.io/activitypub-data-portability/lola.html
* SC: We didn't evealuate some of the spec proposals well or on time in the past, like PDS interop which implemented a Solid migrator. If we are going to look into migration we should evaluate those proposals.
* TBL: Nod. We need open source software to do it. We don't have to write big specs for those operations.
* SC: We looked at using HTTP COPY and archive packages and there is other stuff that we could revisit.
* RG: I didn't quite catch the migration/hosting.
* SC: It was about changing hosting providers and maintaining the URIs.
* RG: Not a Solid-centric problem perhaps.
* TBL: There is a Solid file pattern and a way to support that in the new place, e.g., ACLs.
* EB: There is a program called `rclone`. They have a backend extensibility, and adding Solid Protocol to rclone would be a nice project to see happen.
* eP: Having the user bringing their domain names, we need some of the functionality. If they bring their domain name, then they don't break their links. This requirement ot have a feature for custom domain names needs to come first before people migrating pods.
* TBL: Agree.
* SC: Agree. There is also a case of migratign from regular servers to Solid and requirements to support existing links. It is a good idea to keep distinction between those different described features. We want to make sure that Solid itself is not spec locking besides vendor locking.
* TBL: There are times I use CSS and NSS on the same data.
* RG: Things we need to do on the server implementatoin as well as service provider.

### Add advisement on applicability of security policy based on authentication state and resource semantics
URL: https://github.com/solid/security-considerations/pull/8

* eP: I suggest closing the PR, it can be reopened by providing requested example(s). The question is whether there is an example or not.
* VB: I'd like to review again.
* SC: Different layers with the concern. If there's a general consideration that needs to be expressed doesn't mean it is applicable to every section in the document. There is some text that doesn't belong, needs to be moved or expressed as a general consideration.
* eP: I am not saying it should apply to all, but for each consideration there should be an example. For this we have zero.
* SC: The first example was what's ??? The point is when reading this document people should not blindly put the considerations in place because there are scenarios where it does not apply. For example, if you're unauthenticated you won't be able to perform write operations. What security measures will the server be adding about write operations if the user can't perform them in the first place? The point is you don't need to. Cuts through the whole document. As editor if you can find a place where it applies that's fine.
* eP: My initial understanding you were proposing in relation to the example of ??? This does not apply to that example because initial request is not authenticated but execution of javascript opens up that possibility.

### Solid-ODI meeting on Friday
Proposed by eP

* JW: If anyone has questions, welcome. There is no pre-planned agenda for questions. It is setup as a webinar. We don't know how many will attend.

---

* VB: Passing these on for next week's agenda.

### Document threats where a Solid-OIDC issuer performs illegal activities
URL: https://github.com/solid/security-considerations/issues/21

* eP: Instead of creating issue for each possible party being malicious, we can describe trust model, recommended levels of trust for each party. And examples of consequences when each party acts in malicious way.

### Plans for Solid symposium 2025
URL: https://www.sosy2025.eu/

Proposed by eP

### Summary of E2EE STM and followup
URL: https://hackmd.io/zg2zvBafSauNydofOJY2Zw

Proposed by eP

* eP: