|
| 1 | +# W3C Solid Community Group: Weekly |
| 2 | + |
| 3 | +* Date: 2023-12-06T14:00:00Z |
| 4 | +* Call: https://meet.jit.si/solid-cg |
| 5 | +* Chat: https://matrix.to/#/#solid_specification:gitter.im |
| 6 | +* Repository: https://github.com/solid/specification |
| 7 | +* Status: Published |
| 8 | + |
| 9 | +## Present |
| 10 | + |
| 11 | +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) |
| 12 | +* Aaron Coburn (Inrupt) |
| 13 | +* Gordana Halavanja |
| 14 | +* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me) |
| 15 | +* Maxime Lecoq |
| 16 | +* [Michiel de Jong](https://michielbdejong.com) |
| 17 | +* Rahul Gupta |
| 18 | +* Hadrian Zbarcea |
| 19 | + |
| 20 | +--- |
| 21 | + |
| 22 | +## Announcements |
| 23 | + |
| 24 | +### Meeting Guidelines |
| 25 | +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). |
| 26 | +* [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md). |
| 27 | +* 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. |
| 28 | +* Join queue to talk. |
| 29 | +* 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. |
| 30 | + |
| 31 | +### Participation and Code of Conduct |
| 32 | +* [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/). |
| 33 | +* [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/) |
| 34 | +* 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. |
| 35 | +* If this is your first time, welcome! please introduce yourself. |
| 36 | + |
| 37 | + |
| 38 | +### Scribes |
| 39 | +* Aaron Coburn |
| 40 | + |
| 41 | + |
| 42 | +### Introductions |
| 43 | +* |
| 44 | + |
| 45 | +--- |
| 46 | + |
| 47 | + |
| 48 | +## Topics |
| 49 | + |
| 50 | +### WIP Implementation Feedback |
| 51 | + |
| 52 | +* eP: I started recording short videos showcasing `sai-js` |
| 53 | + * [YouTube playlist](https://www.youtube.com/watch?v=IXzdH1JqcOA&list=PLXBho_YohPB09B_ecOsABoI8Dc67v1H4O) |
| 54 | + * [SAI - Resource Sharing & Solid Notifications](https://www.youtube.com/watch?v=IXzdH1JqcOA&list=PLXBho_YohPB09B_ecOsABoI8Dc67v1H4O) |
| 55 | + * [SAI - Access Request](https://www.youtube.com/watch?v=1mfEHHsfyCE&list=PLXBho_YohPB09B_ecOsABoI8Dc67v1H4O) |
| 56 | +* eP: I'm starting to implement establishing reciprocal data-sharing relation using a pre-established text communication channel between two agents (SMS, email, IM, etc.). This also accommodates case where the invited agent doesn't have a WebID- and/or SAI-enabled pod. It will involve a rewrite of [SAI Invitation draft](https://github.com/solid/data-interoperability-panel/tree/main/proposals/invitation) |
| 57 | + * Makes use of capability URLs |
| 58 | + * Relies on agent registrations, no open inboxes |
| 59 | +* MdJ: are the invitations uni- or bi-directional |
| 60 | +* eP: bidirectional: at the end of the flow there is a reciprocal relationship between the agents; the relationships are private, only the owner knows the agent graph. Only the authorization agent has a list of all agents (doesn't use `foaf:knows`; uses the SAI predicates) |
| 61 | +* MdJ: we will want to think about compatability |
| 62 | +* eP: perhaps a special topic meeting (possibly 12 Dec) or contact on Matrix |
| 63 | +* GH: this seems aligned with the Solid Wallet project, similar to the "launcher app" |
| 64 | +* eP: launcher app and SAI seem to have a lot of overlap, sharing experiences would be productive |
| 65 | +* MdJ: +1 on a special topics meeting on launcher apps, would be good to converge on these |
| 66 | +* eP: proposes Dec 12 |
| 67 | +* Many approvals: MdJ, GH, AC |
| 68 | +* Maxime Lecoq: We are working wih INRIA and SiB on indexing in Solid ecosystem. Demo of a querying app using indexes. The app is able to find users spread across multiple Solid pods thanks to indexes, queried with Comunica. Indexes can be federated (merged into the pod of the federation) or local (on each federation pod). We replicated a use case to find and display users given two criteria: their skills and their location (city). Each skill and city is indexed in dedicated documents hosted on the general pod (the "org" pod used by the application). The simulation deploys 32 CSS instances (representing user communities) with 40 users, each of whom have 5 skills. |
| 69 | + * (screen share) |
| 70 | + * working with INRIA and startin blox |
| 71 | + * multiple pods (32) with 40 users |
| 72 | + * each use with skills: Java, PHP, Python |
| 73 | + * each lives in a city |
| 74 | + * App will query based on skill and city |
| 75 | + * Two scenarios for indexing |
| 76 | + * Global index (federation pod): the indexes of the whole federation are merged on one pod (the federation's). |
| 77 | + * Distributed index (each pod): each pod maintains its own index |
| 78 | + * Interface for entering skills and/or city. User can choose indexing strategy. |
| 79 | + * Federated query involves many more HTTP requests and can be slower |
| 80 | + * Using a direct pod traversal (per user) and is much slower |
| 81 | + * The examples use public data; there are some interesting use cases to explore with private data |
| 82 | +* PA: each pod is on a different docker container, can control the indexing strategy and explore the tradeoffs related to performance |
| 83 | + * The project is available at https://github.com/Wimmics/solid-start/tree/main/sib-replica |
| 84 | + * There should be more demos coming |
| 85 | +* eP: one potential real world candidate for this sort of indexing relates to bike commuting |
| 86 | + |
| 87 | +### Holidays break in December |
| 88 | +URL: https://www.w3.org/groups/cg/solid/calendar/ |
| 89 | + |
| 90 | +* eP: Last 2023 CG call on Dec 13th |
| 91 | +* eP: First 2024 CG call on Jan 10th |
| 92 | + |
| 93 | +### Special Topic Meetings |
| 94 | +URL: https://github.com/solid/specification/discussions/555 |
| 95 | + |
| 96 | +* eP: We should schedule or cancel the Jan 9th meeting |
| 97 | + * This should be decided on the 13 Dec CG call |
| 98 | +* eP: We can still schedule something on Dec 12th (currently canceled) |
| 99 | +* eP: Joint meeting with Social CG shows interest in future focused meetings. For example AuthN/AuthZ, data collections/containers, etc. |
| 100 | + |
| 101 | +ACTION: eP will ask Sarven about scheduling the Dec 12 meeting to discuss launcher apps |
| 102 | + |
| 103 | +### Solid CG Chair Election Procedure |
| 104 | +URL: https://github.com/solid/specification/discussions/582 |
| 105 | + |
| 106 | +* eP: One more week to vote: https://www.w3.org/2002/09/wbs/110151/cfb1563d-40eb-4c65-9859-30ee63e739bb/ |
| 107 | +* eP: Please double check if your name appears on https://github.com/w3c-cg/solid/blob/main/elections/2023/eligible-voters.txt |
| 108 | + * If your name is not listed, please raise an issue or make a PR |
| 109 | +* eP: Any CG member can use the online poll; only votes cast by names listed above will be counted! We plan to provide finalized list to W3C Monday-ish; last chance to raise issue if your name is not on it and you believe it should be. |
| 110 | +* AC: each organization has one vote; for example, for Inrupt, I am the designated voter. You can see Hadrian is not on the list of eligible voters. |
| 111 | +* ML: to be clear, if I am in an organization, I cannot vote? |
| 112 | +* eP: if you were the designated voter, you can vote |
| 113 | +* HZ: this is the result of the new charter: every organization has one vote. The designated member will cast that vote. If you are affiliated with an organization and not the designated voter, you cannot vote. If you are unaffiliated, you can vote |
| 114 | +* eP: a possible topic for 9 Jan could be a retrospective of the voting process |
| 115 | + * AC: +1 |
| 116 | + |
| 117 | +### Ideas for access modes and corresponding operations in the Protocol |
| 118 | +URL: https://github.com/solid/authorization-panel/issues/253 |
| 119 | +URL: https://github.com/solid/authorization-panel/issues/194 (Universal Access Modes API) |
| 120 | + |
| 121 | +* eP: WAC, ACP, SAI Data Grants, and Inrupt's Access Grants (I believe) all use common access modes. We could aim at a small spec which defines it independently of any specific AuthZ system. We should also clearly map the defined access modes to storage operations. |
| 122 | + * ...: WAC defines the access modes in the ACL vocabulary |
| 123 | + * ...: ACP uses those same access modes |
| 124 | + * ...: in SAI we use the same access modes |
| 125 | + * ...: Inrupt's Access Grants also use the same access modes |
| 126 | + * ...: This would be a good piece of work to focus on in January. The ACL defines write/append (some broad categories) |
| 127 | + * ...: SAI defines create/delete (more fine-grained modes) |
| 128 | + * ...: we shouldn't use the current access modes as the final set |
| 129 | +* AC: In our experience working with the existing access modes, we have run into issues with `DELETE` operations and how they work with `Write` access mode. Some things are not intuitive with current access modes. I would be interested in rethinking current access modes. Authorization came up as topic yesterday in joint meeting with Social CG |
| 130 | +* eP: this is a good candidate for a special topic meeting, possibly the 9th or 16th of January |
| 131 | +* eP: There is also an issue with server managed statements, `create(contained resource)` should not require update on the container itself. The server updates the container, or the server managed auxiliary in an alternative design. |
| 132 | + * ...: SAI has creator-specific rules using existing modes: if you created the resource, you get certain permissions (i.e., the access modes only apply if you are the creator) |
| 133 | + * ...: will bring this up at the next CG meeting for scheduling |
| 134 | + |
| 135 | +### Reorganize resources without breaking URLs |
| 136 | + |
| 137 | +* eP: Currently deciding on having resource contained in a container comes with a big commitment. Moving a resource between containers requires changing the URL. |
| 138 | +* eP: SAI uses shape tree references where predicates defines a relation, e.g., `Project 1 - hasTask -> Task 5`. Inherited Data Grants allow granting access to all the tasks of a specific project or a group of projects. |
| 139 | +* eP: As I understand, SolidOS also have somehow similar support for contact groups, where access to a group grants access to all the contacts in the group, even though the contacts are not `LDP:contain`ed in any of the groups. |
| 140 | +* AC: We also have found it as a pain point. Most users of Solid are not sold on the notion of container-based organization. This is not a big reason for using Solid. Often the container-based organization gets in the way. We put semantics in the URIs; it has some advantages but also a lot of disadvantages. There are some ideas for how we can work around that; for example, in your task and project example. If you were to issue a data grant to that, you would need to list a full URI. It would be an interesting mechanism to have a data grant to a category of data, e.g., Tasks. This could work with hierarchical container storage as well as non-hierarchical. Having alternative interface to LDP hierarchy would be powerful for Solid. |
| 141 | +* RG: One way to solve this is to have a client-client standard. Store everything in one folder. Or each resource has a canonical URL, independent of LDP hierarachy |
| 142 | +* ...: without the container model, it seems like a very different specification |
| 143 | +* PA: two questions — how do containers get in the way? One could use flat top-level container and apply hierarchy in other way. |
| 144 | +* PA: the average user will not host pod at home, maybe at some point decide that there is a better provider, which would lead to change of URIs of all the resources |
| 145 | +* AC: One could have flat top-level container. The challenge I see, today, access control is very much tied to the container hierarchy, and it is the only way to navigate the pod. If we had another way to navigate, it there would be no problem. If we had an alternative, not instead but in addition to, I would have no problem |
| 146 | +* RG: If you look at hypertext architecture, the hierarchy is only one way of organizing data. For example, Ted Nelson considers it evil. Hierarchy is also something in the filesystem, and we still want to map between filesystem and hypermedia space. We could, in principle, let people use their own domain. We could use that domain to create permalinks. Most universities have services to provide permalinks to papers. This could be extended for all resources in the storage. There are ways to mitigate those issues. |
| 147 | +* MdJ: (from chat) if it's just about moving data around, it would be nice if you could have variables to affect how relative URLs are parsed. This is a very common pattern in things like bash scripts. |
| 148 | + ``` |
| 149 | + BASE_URL=https://example.com/folder/ |
| 150 | + ADDRESSBOOK= {BASE_URL}subfolder/addressbook.ttl |
| 151 | + ``` |
| 152 | +* ... I don't think RDF supports this though. |
| 153 | +* MdJ: (from chat) You could also look at [Pod Migrator](https://dapsi.ngi.eu/success-story-pds-pod-migrator-migrating-your-solid-data/) which was a DAPSI-funded project by the PDS Interop team. It's about moving a whole pod, but might also be useful for moving just one file or folder around. |
0 commit comments