-
Notifications
You must be signed in to change notification settings - Fork 46
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Minutes 2023-09-19 STM client-client specs (#570)
* Minutes 2023-09-19 STM client-client specs * Apply suggestions from code review Co-authored-by: Sarven Capadisli <info@csarven.ca> Co-authored-by: Virginia Balseiro <virginiabalseiro@gmail.com> Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> --------- Co-authored-by: Sarven Capadisli <info@csarven.ca> Co-authored-by: Virginia Balseiro <virginiabalseiro@gmail.com> Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Loading branch information
4 people
authored
Sep 25, 2023
1 parent
39fb76d
commit 2e29ffc
Showing
1 changed file
with
139 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,139 @@ | ||
| # W3C Solid Community Group: Special Topic Meeting | ||
|
|
||
| * Date: 2023-09-19T14:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Chat: https://matrix.to/#/#solid_specification:gitter.im | ||
| * Repository: https://github.com/solid/specification | ||
| * Next meetings: https://github.com/solid/specification/discussions/555 | ||
|
|
||
|
|
||
| ## Present | ||
| * [Michiel de Jong](https://michielbdejong.com) | ||
| * Reza Soltani | ||
| * Tim Berners-Lee | ||
| * elf Pavlik | ||
| * Wouter Termont | ||
| * michal/mrkvon | ||
|
|
||
| --- | ||
|
|
||
| ## 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 | ||
| * Wouter Termont | ||
|
|
||
|
|
||
| ### Introductions | ||
| * name: text | ||
|
|
||
| --- | ||
|
|
||
| ## Topic: Alignment on generalized approach to client-client specs | ||
|
|
||
| Context: https://github.com/solid/specification/discussions/554 | ||
|
|
||
| * eP: Can Tim briefly introduce the new chat spec ([issue](https://github.com/solid/specification/issues/553) / [repo](https://github.com/solid/chat) / [matrix](https://solid.github.io/chat/#channel))? | ||
| * TBL: Basically we take a unix directory approach in the code we got working on pods. The same way we tried to follow macOS Address Book ([vCards](https://dbpedia.org/resource/VCard)) as basis. Everything else is under this thing. One difference for the chat is that people typically use one address book, while in Solid, people will also want to add more than one address book. | ||
| * ... There was a 'short chat' idea that worked in a single resource. Ruben suggested deprecating that in favor of one general 'long chat' approach: a folder with a master file on top; it stores the messages in a dated folder hierarchy, like the archive format. So you have a limited amount of chat per day, and then you move on. Then this day resource is appended to the master file. | ||
| * ... Jackson wrote an app that is compatible with Solid and SolidOS. I tried to put all these pieces into it. In particular, it got shapes in ShaCL. I now try to integrate with Rebel (?) for shape validation, and integrate with Slack functionalities (i.e., storing Slack data in my pod). | ||
| * eP: When reading a chat channel, links must be followed, with no assumptions about the URI, with an exception for the hierarchical data structure. Jackson wrote a [comment](https://github.com/solid/specification/issues/553#issuecomment-1688564415) saying: "The main flow lies in the dependency on the file structure. The entry point is `index.ttl`, but it does not point to where the chat is stored, so developers [must follow this convention]." This also seems to impede on the ... | ||
| * TBL: It would be nice to leave clues, e.g., with a UI template in the chat masterfile, indicating the form of the URI. It might indeed be handy to use other structures, but a date here is very common. | ||
| * ... The second point is rather philosophical. The main point is that when you create something in the chat (or whatever), you have to be given a folder; then you can do whatever you like with it. Similar to macOS (?). Example: | ||
| * ... `~/Photos/myPhotos.pholLibrary/` is a package and the user doesn't see the substructure of that directory; the app has it to itself. | ||
| * ... So you might find `../Originals/20023/09/imh61.jpg` as the structure within that directory. | ||
| * ... The rule is that an app gets to define the substructure of a directory. | ||
| * ... SolidOS uses that for trackers, chat, address book, etc. | ||
| * WT: Pavlik mentioned something about `index.ttl` which tracks different chat files, but it is not a type index. | ||
| * TBL: `index.ttl#this` is a chat channel. | ||
| * WT: This sounded to me like the issue I raised in type indexes, that there is some assumptions about the URL | ||
| * TBL: Type Index should only be links, not specific structure. | ||
| * WT: The solution with URI templates, could it also be done with the links from channel to the messages? Possibly messages linking to other messages. | ||
| * TBL: the problem is that if the channel links to everything, you could have an explicit list of everything today, replicating the folder structure. | ||
| * WT: If it's based on links, I don't have issues with it. | ||
| * MdJ: I have a question on the topic: one way is to read with how do we treat the way we are building specs? another is to design patterns for storing files in pod. | ||
| * TBL: responding to the first: when we have working code, we write down how we do it, use that as examples, analyse it to a shape etc. | ||
| * ... If you don't have existing code, e.g., bank statements, we go to existing stuff and try to map that. | ||
| * MdJ: I [wrote down](https://pdsinterop.org/conventions/chat/) three chat formats I was aware of two years ago, and I wrote an implementation of one of them storing chat messages in a person's pod. | ||
| * WT: We are talking specifically about this chat spec after my response to the proposal of chat spec. I would like to look at general patterns for the interop. I want to take opportunity of this use case to look how we can look at such use cases more generally. | ||
| * TBL: To work on two different things is a bit like working on HTTP and FTP at the same time. | ||
| * MdJ: What we tried to do in the [solid data modules](https://hackmd.io/@michielbdejong/HyIMjmoxn) project is to not have an idea about how storing data in a pod is good or bad, but just see what is there and what ends up in a pod. Whenever someone wants to write something in a pod, we make the data module compatible with that. | ||
| * TBL: When we talk about how we define c2c specs, there's an interesting part of Solid, when you talk about modularity. Typically, we modularize around data classes: I can handle an address book, a chat, etc. So in this way a chat app signs up for both long chat as 'message' data. | ||
| * ... Suppose I want to link a chat message to a task, in which case it becomes an issue. In other cases, one might take an issue and integrate it in a message... In the spec, we could add some integrations. | ||
| * WT: My main comment is that we can abstract from that and have a general spec which lets us integrate different types of data. The app can also ask a pod, "do you have this kind of data?" | ||
| * TBL: ... | ||
| * WT: One can write chat spec; someone else writes a spec for recipes. We can have a general spec which defines how those can be integrated with having dedicated spec for integration between any possible domains. | ||
|
|
||
| --- | ||
|
|
||
| * eP: Coming back a bit to the IRI template with dates, I think we should describe the requirements for that and distinguish it from other popular approaches like [ULIDs](https://github.com/ulid/spec). So what do we want to reach with it? This would also be more generally usable. | ||
| * ... Tomorrow I also want to briefly demo the updated Authorization Agent. It also relates in a general way to how the app knows where it finds data and how it gets access to that specific type of data: a common reference. I will demo how it would work for projects and tasks, and we can then see the general pattern that we would need for any kind of data. | ||
| * TBL: If we want other things than type indexes, one thing to do is to standardize a javascript API. | ||
| * eP: I do have a [typescript implementation](https://github.com/janeirodigital/sai-js) of [SAI](https://solid.github.io/data-interoperability-panel/specification/), which I will use in the demo. But I don't think we can rely too much on one specific programming language. | ||
| * ... Also, here's a link to the [previous demo](https://www.youtube.com/watch?v=CvTunOWu7mM). | ||
| * TBL: ... (something about websockets) ... That's why I'm thinking we could have abstraction in the code which helps people move from one to the other. | ||
|
|
||
| --- | ||
|
|
||
| * TBL: I am a bit worried about things being treated the same if they are the same type. Some address books might have different needs to access. | ||
| * eP: I agree. But I will show on the demo tomorrow, e.g., distinguishing between data from different storages. It also uses an authorization agent, which the user can trust and is easily used because of the familiarity of the UI. | ||
| * TBL: In SolidOS, we have an access control pane, which is used within an app, so you can show the same access control pane as everywhere else. It can also show, e.g., per person, what they have access to. | ||
| * WT: Tim, do you have demo of access control pane in Solid OS? | ||
| * TBL: I can share the screen. | ||
| * ... [Shows access control pane] | ||
| * ... I can see the different modes of access, and who has them. I can drag any WebID into them. Indirect/inherited rights are grayed out; I can override those by adding specific ACL. I can also select whether or not to include a link in the (public) type index, etc. In the chat app, I can then view all the chats in the (public or private) type index. | ||
| * WT: Is that based on WAC or ACP? | ||
| * TBL: On WAC. | ||
| * WT: I'd be interested in how this would work with OAuth/UMA. | ||
| * TBL: There are two aspects of this. I can add a WebID for anyone logged in, or per origin. I guess you could add that in there. It is a pretty straightforward app. You can also use trusted applications. | ||
| * eP: Are all the human readable labels a name, or are they taken from a label? | ||
| * TBL: In general, labels are used if they are there. Sometimes we cheat and use the URL and add spaces. | ||
| * eP: Is it using rdfs:label, or ...? | ||
| * TBL: In the SolidUI library, there is a set of labels (predicates?) that are updated every now and then. Languages are important too. In my profile, I have put the languages I speak. | ||
| * eP: When I asked about the labels, I wanted to point out that in the demo I am relying on ShapeTrees, that has a predicate that indicates the predicate to follow to the label (cf. [example](https://github.com/janeirodigital/sai-js/blob/main/packages/css-storage-fixture/shapetrees/trees/Project%24.ttl#L12-L13)). | ||
|
|
||
| --- | ||
|
|
||
| * WT: Is there an approach we want to take for aligning the c2c specs, or do we just ... Can we do a monthly meeting between use cases? | ||
| * TBL: The Solid spec is quite incompatible with the way ... Things like shape indexes, discovery, etc., should have its own WebID. I think it is useful to align on TypeIndexes. I know you have something different, but I would like something simple, to just show different types of things. ... I wouldn't want to force everybody to use the same framework, really. | ||
| * ... Would shapetrees be possible to describe a chat? | ||
| * eP: For example, in the chat spec you have a directory with chats according to a shape. In shapetrees, we can actually link to that shape in a follow-your-nose approach. | ||
| * TBL: So when you're looking for something in a pod, does it then declare what shape it is? | ||
| * eP: In SAI we use data registries which link data to a shapetree which contain shapes. | ||
| * TBL: Do shapetrees have uri templates? | ||
| * WT: Yes, you can specify the name of a path. | ||
|
|
||
| --- | ||
|
|
||
| * eP: What did you say about the app has an id? ... this seems to clash with colid-OIDC? | ||
| * TBL: For example, if I have a timbl-bot, it has a has a pod and can run tasks like importing matrix chats, etc. If you look at [timblebot](https://timblbot.inrupt.net/profile/card#me), it is a bot I control. I use WAC to give it access as an agent to my pod, and it just logs in. It's not an OIDC flow. | ||
| * eP: We have a separate [issue](https://github.com/solid/specification/issues/504) about server-side clients. We had a talk about that two weeks ago, and we agree there needs to be a better way. We just assume clients have their own ID. | ||
| * TBL: I agree that from the point of view of CSS, it is indistinguishable from a person. | ||
| * eP: We also want to offer cases where different users could use the same bot. | ||
| * TBL: You could imagine it creating a new agent/WebID specifically for the task of a specific user. | ||
|
|
||
| --- | ||
|
|
||
| * eP: I want to ask michal/mrkvon and Reza to share their opinion. | ||
| * RS: I was just listening for a while. You mentioned the issue about a bot that users can use to access a pod. ... I do not know specifically what I can say here. | ||
| * eP: I would be interested in requirements and use cases. | ||
| * RS: Let me talk to Michael and come back to you. | ||
| * ... Is there any way we can authorize the application as itself? | ||
| * eP: Yes, [CSS has a way](https://communitysolidserver.github.io/CommunitySolidServer/6.x/usage/client-credentials/). It is not standard, though. There is also the issue (linked above) in which we are talking about alternative flows, and there is a similar [document](https://github.com/solid/solid-oidc/blob/main/alternative-flows.md) in the solid-oidc repo. | ||
| * mrkvon: I came expecting a bit of talk about solid chat. I have one specific issue. I think the current approach is that all messages are stored in one person's pod. I find the [approach](pod-chat.com) Michiel hinted at — of having messages in multiple people's messages — more equal. We use that for an implementation (https://sleepy.bike/). | ||
| * eP: I think there are advantages, but it might impact replication, e.g., when there is only one copy of a message, and a pod is down, we would lose part of the conversation. | ||
| * mrkvon: Fair enough, but we could see replication as optimization. I do not think it is much of a problem if there is | ||
| * eP: I think there should be some agreements, have a canonical version and then some replication. I also don't think this is chat specific. We also need this for other data. |