W3C Solid Community Group: Meeting Title

# W3C Solid Community Group: Special Topic Meeting * Date: 2023-09-19 14:00 UTC * 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 * 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 ### Introductions * name: text --- ## Topic: Alignment on generalized approach to client-client specs Context: https://github.com/solid/specification/discussions/554 * eP: Can Tim shortly 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 code we got working on pods is we take a unix directory approach. The same way we tried to follow macos address book (vcards) 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. * TBL: There was a 'short chat' idea that worked in a single resource. Ruben suggested to deprecate 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 hierachy, 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. * TBL: Jackson wrote an app that is compatible with Solid and SolidOS. I tried to put all these pieces in it. In particular it got shapes in ShaCL. I now try to integrate with Rebel (?) for shape validation, and integrate with Slack functionalities (store Slack data into my pod). * eP: When reading a chat channel, links must be followed, with no assumptions about the URI, with the 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 dependenceof the file structure. The entrypoint 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. * TBL: The second point is rather philosophically. 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 `../Orignals/20023/09/imh61.jpg` as the structure within that directory. * The rule is that an app gets to define all the substructure of a directory. * SolidOS uses that for trackers, chat, addressbook, 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. * TBL: 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 as workin 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 having an idea about how an idea of 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 the 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. * TBL: 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 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 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 form other popular approaches link [ULIDs](https://github.com/ulid/spec). So what do we want to reach with it? This would also be usable more general. * eP: Tomorrow I also want to dmeo shortly the updated Authorization Agent, it also relates to a general way on which way the app knows where it finds data and how it get's 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 to much on one specific programming language. * eP: Here's also 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. distinguish between data from different storages. It also uses an authorization agent, which the user can trusts and 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. * TBL: [Shows access control pane] * TBL: I can see the different modes of access and who has them. I can drag in any WebID to 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 on this. I can add a WebID or 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 to. 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 ... CCan we do a monthly meeting between use cases? * TBL: The Solid spec is quite incompatible with the way ... Things like a shpe indexes, discovery etc hsould have it's 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 use everybody to use the same framework really. * TBL: Would shapetrees be possible to describe achat? * eP: For example, in the chat spec you have an 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) is a bot I control. I use WAC to give its 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 as 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. * RS: Is there any way we can authorize the application on 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 to expect a bit of talks about the solid chat. I have one specific issue. I think the current approach is that all messages are stored in one persons pod. I find the [approach](pod-chat.com) Michiel hinted at of having messages in multiple peoples 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.