# W3C Solid Community Group: Weekly

* Date: 2023-11-29T14: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
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* Aaron Coburn
* Michiel de Jong
* Hadrian Zbarcea (Inrupt)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* Gordana Halavanja
* Tim Berners-Lee
* Michael Toomin
* [Ted Thibodeau Jr](https://github.com/TallTed) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
* Jeff Zucker

---

## 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 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

### Holiday Break
* SC: We can use a break, and there is the general holiday time in December for some. We can cancel the following meetings: 2023-12-20, 2023-12-27, 2024-01-03. Any objection?
* SC: No objections.

### Special Topic Meetings
URL: https://github.com/solid/specification/discussions/555

* SC: Poll for Solid and Social CG joint meeting time: https://github.com/solid/specification/discussions/594
* SC: Draft agenda: https://hackmd.io/QOpHN7LsRQO5FwLLjD2zTg . Feedback still welcome.
* SC: Announcement: https://lists.w3.org/Archives/Public/public-solid/2023Nov/0070.html
* SC: Last call. I think we (Solid CG) are okay to go with 2023-12-05 unless Social CG feels otherwise.

### WIP Implementation Feedback

* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
* eP: RG is not present but asked MT to present [Braid](https://braid.org/). We should prioritize since MT is present today.
* SC: 10 minute demo would be great.

### Braid Overview and Demo
* MT: Braid is working on state synchronization, adding to HTTP, which Solid can use to get real-time updates of your state.

[demo/screenshare]

* SC: Is the extension available publicly?
* MT: Yes
* SC: https://github.com/braid-org/braid-chrome
* eP: How does it work with media types? How does it work with HTTP, does it use fetch?
* MT: Implemented on top of fetch. We have a library, `braid-http`, that wraps fetch and parses response. It can work with any media type.
* TBL: You can pretty-print RDF and it reads like JSON.
* eP: (chat) or <https://www.w3.org/TR/rdf-canon/>?
* MdJ: ??? get a generic way to deal with collaboration. Different systems express changes in different ways. Second problem is differing algorithms for computing state based on sets of changes. People say it's impossible. What do you think?
* MT: ??? we have taken corner cases and looked at them. As we prove algorithms converge to same ???, that problem goes away.
* HZ: Are you familiar with [Apache Wave](https://incubator.apache.org/projects/wave.html) (previously known as Google Wave)? What are the differences?
* MT: Google used ??? for synchronization.
* SC: I work on an authoring tool and one of the questions is how to do synchronization. Is the spec work being carried out at IETF?
* MT: There's interest in HTTP WG.
* SC: Solid might be looking at ways to extend for RDF for example.
* MT: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http
* eP: If someone wants to make a Solid app using Braid, I understand there's a fetch extension. ??? could be used on server.
* MT: [`npm` braid-http package](https://www.npmjs.com/package/braid-http) has both client and server code
* TBL: SolidOS code has a very ??? stack using websockets. We change the Solid API library and ???

### Solid CG Chair Election Procedure
URL: https://github.com/solid/specification/discussions/582

* SC: Eligible voters: https://github.com/w3c-cg/solid/blob/main/elections/2023/eligible-voters.txt
* SC: Candidates: https://github.com/w3c-cg/solid/blob/main/elections/2023/candidates.md
* SC: Waiting for W3C Team Community Process to review/confirm the questionnaire on W3C WBS. Will publicise to public-solid mailing list right after.

### W3C Solid WG Charter Proposal

* SC: PAC can process these now. Please review. See also https://lists.w3.org/Archives/Public/public-solid/2023Nov/0083.html and thread for discussion.
* PAC: Few clarifications: this is a straw-man proposal. Goal is to explore a possible direction. It might be useful to make a distinction between Solid as a vision/problem-space and a solution/set-of-specs. Effort on mailing list towards an explainer might help because it addresses both sides. If we can make it clear what the problems are and how we are currently solving them, it might help the case that it is about Solid, but open to other solutions.
* SC: My interpretation was that it was exploratory, as opposed to a concrete proposal. There's a history of why we ended up here with decisions around Protocol, LDP, and so on. We need to keep that in mind and not go back to drawing board or re-do the protocol. We need to look at what's really intended.
* eP: For me, the main step would be focusing on authorization. One thing Solid adds is access control aspect. Given experience with WAC, ACP, access grants, there's ??? There could be different systems. We have enough to look at minimal ways to achieve that.
* TBL: As SC said, these decisions were made and everybody agreed and we have code implementing those decisions. The idea that we should start from scratch means running code would not be able to use that. We could call it something else but it would be confusing.
* PAC: I understand decisions were made for good reasons. W3C does not want to create a group whose sole mission is to rubber stamp something from outside. Solid specs would be used as inputs, but other inputs should be welcome. Need to define problem space so that decisions made by Solid can be argued as a good way to solve that problem space. This should be a consequence of how well we define the problem space, as opposed to coming with an existing spec.
* SC: The way WAC is written is not at all coupled with Solid Protocol, but it can work alongside Solid Protocol, LDP, ActivityPub. Would you consider that as an example where it's not a solution looking for a rubber stamp? Is that the kind of framing that may help?
* PAC: It's another aspect. Having pieces of the work framed in a way that can be used in other contexts is a good thing. Boils down to describing the problem space and then, once we have it precisely described, we can identify connections with other existing specs. For example, AP could benefit from WAC because WAC solves a bigger problem that exists in both Solid and AP. That'd be a nice side effect of focusing on the problem space.
* SC: And again anything using LDP that needs authorization.
* PAC: Yes.
* MdJ: Some of this is about branding. PAC and I had a meeting and I proposed to have Solid as a ???, not naming it after a solution. There are other specs that will be worked on in the CG that are also part of Solid. WG should have Solid 1.0 as an end result, 2 years from now. We have lots of things that we don't have working like fine-grained access control. Maybe it's more honest to say the specs we have now do not solve all the problems we want to solve which is part of what TAG was poiting at. Rebranding the WG might help.
* SC: One thing we didn't do right was looking at related or similar works/specs that address the same problem space. I replied to PAC on the mailing list, one example was Fedora spec. They have worked with LDP and put out stuff we haven't even touched like versioning. I can see that being put under the same umbrella. Input for that would be Solid protocol, Fedora, and others, and we can go through that with authorization, and other specs with track record of incubation, and the WG can make the best of it to solve the general problem. Right now it's Solid-centric and I understand why that doesn't fly with everyone else outside Solid.
* MdJ: Even if you take versioning, you still don't have client-client specs in WG. It's more honest to say the WG will ??? what server does and a lot more happens on client side.
* TBL: We can reverse engineer the requirements from the spec? Maybe. We have to make sure that we get everything which has been maybe implicit over the years. Process to start again with requirements? Requirement: everyone who writes a Solid app has the benefit that they don't need to make any changes to the server. Other platforms people have brought up don't have that property.
* GH: There are companies and foundations e.g. using the name Solid, ??? in an economic sense we are not able to quantify potential future losses for not having Solid the way it has been used in the world/industry.

#### clarify scope
URL: https://github.com/solid/solid-wg-charter/pull/62

#### clarify the handling of low-maturity normative references
URL: https://github.com/solid/solid-wg-charter/pull/63

#### First phrase, 'a' protocol
https://github.com/solid/solid-wg-charter/pull/64

#### Mention Unhosted/remoteStorage as a non-normative input
https://github.com/solid/solid-wg-charter/pull/65

## i18n and n11n of resource identifiers
URL: https://github.com/solid/specification/pull/575

* SC: All, please review.

## Solid Practitioners
URL: https://github.com/solid-contrib/practitioners/

* JZ: We started a new group called Solid Practitioners. Purpose is to work bottom up rather than top down. Focus on people actually creating usable products with Solid, especially those producing social benefit. We have a repo, chatroom, and meetings. Next one is tomorrow at 1700UTC. We intend to focus on project being worked on. Currently homelessness projects in Portland, bike project worldwide, Flanders, group from Mexico City. Some production, some approaching.
* SC: Glad you're leading this work. Important for ecosystem and community.

---

## Work on "launcher apps"
* MdJ: Something we might want to coordinate through the CG in the coming months/years:
When you start using a new Solid app for the first time, you have to grant it access to your storage.
Hopefully this is fine-grained access to just a small part of your storage. :)
There is a useful interaction between
- discovering apps that others recommend ("app store")
- granting fine-grained access to an app
- remembering which apps you used in the past
- revoking access

The Solid Wallet project implements a "launcher app".
The Solid-Nextcloud server includes a screen from which you can "allow and launch" apps.
A SAI authorization agent can also play the role of launcher app.