Create 2026-05-13.md

meetings/2026-05-13.md

@@ -0,0 +1,129 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2026-05-13T14:00:00Z 
+* Call: https://meet.jit.si/solid-cg
+* Repository: https://github.com/solid/specification
+
+## Chair
+
+* elf Pavlik
+
+## Present
+
+* Christoph Braun - [uvdsl](https://github.com/uvdsl)
+* Precious Oritsedere - [ODI]
+* [Luke Dary](https://w3c.social/@lukedary)
+* [Erich Bremer](https://ebremer.com)
+* [Niko Bonnieure](https://nextgraph.org)
+* [Rui Zhao](https://me.ryey.icu)
+* [Jesse Wright](https://www.jeswr.org/)
+
+## Regrets
+
+*
+
+---
+
+## Scribe
+
+* Theo @thhck
+
+
+### 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.
+
+---
+
+## Introductions
+* None
+
+## Announcements
+* None
+
+## Topics
+
+### Action review 
+
+ - Theo: DONE have a meeting with Niko for e2ee 
+ - JW: have a discussion with Christoph about the way forward for Solid26
+ - JW: propose change on spec on point 3.1
+
+### Solid Planner Demo: Simple yet useful weekly planning app 
+
+* RZ: A local-first TODO app, but focused on automatic weekly planning to get things done [https://github.com/renyuneyun/solid-planner](https://github.com/renyuneyun/solid-planner)
+ - RZ: local first task manager
+ - RZ: possible to synchronize with Pod
+ - RZ: due date, planner, "focus now" and upcoming features
+ - RZ: build with Noel de Martin Soukai lib
+ - CB: what vocab ontology used ?
+ - RZ: No specific vocab used currently
+ - eP: Jesse what the process to have same shape shared for all task related app ( like Noel Focus App )
+ - Jesse: Someone should PR a shape on the solid/shape repo and tag other dev using similar shape 
+ - CB: what Auth lib ?
+ - RZ: inrupt's , but curious to use others.
+ - Th: FedCM would probably not work with inrupt's lib. 
+ - eP: Do you know how does it sync ?
+ - RZ: Forgot about the details
+ - eP: LWS only use POST, but Noel use PUT or PATCH for sync ? Is this an issue we should bring to LWS ?
+ - ...
+ - RZ: I have another branch to link task to calendar. Can be set in a config file, but where / how to discover config file without hardcoding it ? Haven't found lib that does that. 
+ - Jesse: WebId should have a "preferences" section
+ - RZ: But is there lib ? because webid critical, would like to use a tool made for it, not edit it myself.
+ - eP: App specific config or general config ?
+ - timbl: check solidos codebase for preferences , has cool features
+
+### E2EE encryption for Solid Pods
+
+ - Jesse: Niko flagged that we should look at e2ee for Solid. My POV is that it  should be a client spec. Can Niko give us a overview ?
+ - Niko: critical needs of e2ee for pods, since all sensitive data ( banking, health.. ) stored in a single place. Data always like at some point. E2ee exist in Solid chats but needs solution for all data. I can help with spec, bring my experience. Austrian team had 2 papers at SoSy, they already do e2ee using Solid. 
+ - CB in chat: do they use GnuPG under the hood ? 
+ - Jesse: use to work with them 5 years ago, back then had to enter pod credential + enter a decryption key. 
+ - eP: if we create a special topic with Australian team, we need to change our meeting usual timezone. 
+ - Jesse: link to the paper: https://openreview.net/pdf?id=cq5shCCwC0
+ - Niko: e2ee: only client can decrypt data, master key should only be in possession of the user. It get difficult with collaborative document where multiple keys needs to be shared. If only client can decrypt, then it fits very well with localfirst philosophy, and then the server is  optional, work is done on the client and then sync with the pod when online. Needs some metadata around CRDTS and encrypted blobs for the CRDT and keys etc.. and Metadata should be stored as triple. Australian has an ontology to describe key, key rotation etc.. With NextGraph we don't store this metadata in RDF but in binary format, because no needs for triple at that point and once the operation has been process you end up in the graph for the data. But OK to use RDF too for those metadata. 
+ - eP: is this metadata CRDT specific ? Noel don't do encryption, just CRDT. Does this have impact on encryption ? 
+ - Niko: for text ...should be orthogonal.. for binary file ( image etc.. ) easy because they are immutable. 3rd case is collaboration on text, in this case CRDT are not adapted for RDF but raw text
+ - RZ: binary format interesting, Noel store Metadata in same resource as data which can create corruption sometime ( eg.  parallel operation ) . Did you experienced data corruption ? 
+ - Niko: No, but we don't use Solid. 
+ - timbl: Can you talk about key management ? And how can they store data in different way ? what are the option
+ - *Pavlik showing a nitrokey on the cam*
+ - Niko: Keys for personal data is simple. Complex when one needs to control who can Read, who can Write. On NextGraph, for READ purpose, we encrypt each update separately with a random symmetric key; then pass this key to all people involved in the doc, by encrypting the symmetric key with each public key; we have an ACL list with all the participants with READ access to the doc and their public keys; we send the update and the encrypted key to them. For WRITE, same we have ACL with list of participant of the doc who have WRITE access; but writer need to sign the update with their key, otherwise the client rejects the update; signatures also add integrity for the reader (updates are temper proof); like in git we make a trail of all the updates/commits. Then we sometimes need to rotate keys, when changing READ or WRITE permission, otherwise previous permission still applies. 
+- eP: you implemented WAC in java, I'll be curious how the WAC plays with encryption. specially with LDP containers.
+- RZ: ... How does ACL synchronize ? 
+- Niko: NG not implemented WAC for now. Did it for ActivityPod, but for now this would break e2ee so not implemented. If we start with private/public key for user and start with CRDT updates, good start, but this is costly because need crypt operation on each update. Later we can talk about optimization. 
+- Niko: I can champion e2ee for solid. How would it work with LWS?
+- Jesse: has been considered but currently the spec won't be able to expand from it's current scope ( which doesn't include e2ee)
+- chat: https://matrix.to/#/#solid-e2ee:matrix.org 
+- Niko: where should we store key ?
+- *Pavlik showing his nitrokey again*
+- eP: very related to open source tooling, devs don't want to roll their own crypto. 
+
+
+
+
+
+## Actions 
+
+ - eP : PR a shape for task on solid/shape repository
+ - Theo: invite people to join the chat, set a meeting , solid forum , mailing list, invite Noel, the Australian team
+ - invite someone that use ACP to next meeting discussing Virginia's proposition #787 
+
+## Decisions
+
+ - Niko champions solid e2ee effort with help of Theo 
+
+## Links
+- [Solid E2EE Matrix Chat](https://matrix.to/#/#solid-e2ee:matrix.org)
+- [https://github.com/renyuneyun/solid-planner](https://github.com/renyuneyun/solid-planner)
+- [Solid e2ee paper](https://openreview.net/pdf?id=cq5shCCwC0)