-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chat Client-Client spec new work item #553
Comments
While I think shapes and other definitions for the interoperability of chat apps using Solid are a great idea, I agree with @elf-pavlik that we should carefully consider whether Solid itself should incorporate such domain specific definitions, given that we are already working on generic interoperability mechanisms in which such definitions can be plugged. @elf-pavlik already proposed to take that question up during the next meeting. EDIT: I created a discussion to go into this on a more general level, not to hijack this issue. |
Responding to the requests in in the process:
Write a specification for a person or an organization being able to host a chat channel (like matrix or gitter) on their pod.
This is how it is done today.
Not a new approach, existing practice
Not location-based.
There should be user manuals etc for the implementations but the spec itself is for developers, not users. |
In #549 (reply in thread) there is a discussion about the possibility of including chats into apps focused on some very specific domains (eg. hospitality exchange for people traveling by bike). IMO solid should allow such build in chat while having authorization capable of limiting which chats such very specialized apps can access. |
@elf-pavlik well any other app which needs to incorporate chat functionality should be able to make a folder with the right permissions for the use case, and instantiate a chat in that folder. Lots of apps will use chat in different ways. Here is a diagram of chat data being part of all kinds of other in a pod arranged though the way different activities have happened |
@timbl could you please answer this question from the proposal template?
I think having at least 2 people who are committed to dedicate their time to advance the work item is a reasonable requirement for it to move from icebox to in progress. |
@elf-pavlik I could be one of the 2 people. I don't know if @timbl plans to be one as well, or he was looking for some response for the community. As I mentioned on the call, I agree with yours and @woutermont 's warning that we should be very careful about engaging in domain-specific work. That said, chat and communication should be a core service for Solid, like authn/authz is. |
SGTM @hzbarcea 👍 Let's clarify all the details during the next CG call. It would be great if @jaxoncreed who developed mentioned LiquidChat would also provide some feedback. For me, it would be essential to make sure we address use cases like #549 (reply in thread) and take the opportunity given by implementation @mrkvon is working on. To have expected authorization and interop between apps it most likely won't be enough for one app just create a container. |
No links about the work was mentioned. Is this proposal specifically about https://github.com/solid/chat or intended to be broader? Is there room to leverage AS2 and AP (client-server) with the benefit of wider interop? (I'm fairly aware of histories of works moving in parallel timeline... but am hoping that a major opportunity to align things is not overlooked.) Noting that the copyright on Solid Chat changed from Solid CG to Solid Org (~3h ago): solid/chat@a1e3fad#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R641-R642 . Some of us must have missed that CG decision ;) but let's chalk that up as a template copy/paste error for the time being. It may not be appropriate or even possible to have CG contributors accept and advance some document or software - under the legal framework of W3C CG - meanwhile another entity other than W3C (CG) holds the copyright throughout. (IANAL. This is a general point, not an invitation to be lectured where people think Solid Org or CG or WG or something else starts/ends or how decisions made or...) |
I wonder why you think so. Solid aims to empower people in control of their data. For that we need a storage protocol, an authorization protocol, a notifications protocol, and an interoperability standard. Without any of these, reaching the goal is very hard. Chats, on the other hand, are just data, and in some use cases they are important, but in a lot of others they are not. |
I hope we can find some middle ground during our next CG call. While I agree that Solid CG can't dive into all the possible business domains. I think we still need a handful of domains to field-test all the generic specifications. Most CG participants are familiar with domains like messaging, online discussions, project management, and basic multimedia (we need to start publishing our demos). We could dive into those specific (while still pretty commonly used) domains, with the understanding that there still will be a need to provide a process for coordinating interop in a more diverse set of business domains. There was a prior conversation about creating W3C Business Groups to work with verticals. Once we notice the demand for diving into less common domains we can explore that direction. |
I completely agree, but this seems not the way the "chat spec" is being proposed. The only somewhat general interop spec we currently have is SAI, so an actual field-test would try to use SAI to implement chat interop. |
I think this relates to what @hzbarcea mentioned during the last call about top-down vs. bottom-up. |
Personally I feel that there is a big difference between field-testing a general spec (which aims for feedback), and building a specific spec on its own (which might someday provide input to a general spec). We already have a number of domains more specific existing specs of which the authors and users by all means resist attempts to generalisation (e.g. WAC/ACP, TypeIndexes). So I am reluctant to make this into another one. But since I feel like I am the only one with this opinion, by all means start working on it. I am not the one to stop you. |
Late to comment. I don't have the capacity to participate in any official sense, but my two cents is that if we're codifying a chat schema, it this is an opportunity to drastically change it. The current Chat schema is flawed. Liqid is designed to be interoperable with SolidOS, so I had to implement everything, even if I disagreed with it. The main flaw of the current chat schema lies in its dependence on knowledge of the file structure. For example, a typical chat layout might look like this:
The entry point to the chat is Another big problem with this current method of storing chats is the way it works with access control. There is no form of verifiable provenance for chat messages. This means that if everyone has As for the vocabulary itself. I would much rather it be more in line with the activity-pub/matrix world as that already has some adoption. Full interoperability between Solid Pods and Matrix would be fantastic. I could see a future where a Solid Pod could serve as a matrix server with some light modification. But, as it stands now, the vocabulary selected comes mostly from |
I think it would be good to capture the comment above as implementer feedback in https://github.com/solid/chat @woutermont in the end CG can't publish TRs only CG reports. If we can't find a consensus on a single approach I see it possible that Solid CG can publish competing reports which at some point can be picked up by a future WG. |
I would advise a single report, which puts whatever competing approaches we have side-by-side, for further evaluation, comparison, consideration, etc., by whatever future CG and/or WG picks up the work. |
to add to that, i personally like the approach pod-chat.com has taken: each participant in the chat hosts the messages they authored, and these are related via This equalizes control over the chat. I think the main implementation stores all messages in single pod, and owner has therefore full power to edit or delete them. It's partially resolved by signing and verifying the messages, but i think owner can still delete or damage messages as they please. In sleepy.bike i also implemented pod-chat approach, and i hope spec authors can consider embracing it, or resolving the underlying power imbalance issue in other way.
💯 That would be awesome. Me and people i collaborate with would love Matrix- and/or ActivityPub- compatible messaging. (not sure how compatible Matrix is, but ActivityPub sounds (vaguely) compatible) I'd be very happy to rewrite our implementation towards such solution(s). |
@woutermont I think I understand your point, and I agree. My answer(s) would be that: 1. we need much more than that, e.g. strong auditing and a non-repudiation protocol, trust models, etc (you could argue that those would be at different layer, true, but then even the standards you mentioned are layered already, with storage and notification depending on authn/authz; and 2. chat is tightly related to notifications, imho would be a good driver for it. |
Totally agree. But it's only a good driver if it actively engages with ongoing efforts, instead of building something isolated. I have so far seen no indication of engaging with the Solid Notifications Protocol, and explicit disengagement with Solid Application Interoperability. Especially the latter is worrying. |
Accepting a work item doesn't mean rubber stamping a specific proposal. If we can't agree on a single proposal CG can publish rivaling alternatives. In the recently discussed https://www.w3.org/Guide/standards-track/#criteria we can see:
I think while we work on some example domains we will have a better chance to understand the benefits of generalized approaches like SAI. |
For those not present at today's meeting (minutes upcoming), the general consensus was that going forward with this Work Item is a good idea, but a special topic meeting on the alignment on a generalized approach to client-client specs has been proposed on Tuesday 2023-09-19 (at 14:00 UTC). I hope there is lots of motivation from everyone to indeed align on the best way forward. Things that remain to be cleared up around the work item are:
|
Again, special topic meeting has incorrect link. This is correct link. |
That's also what I did in https://pdsinterop.org/conventions/chat/#one-to-one-chat |
So what are the steps required now to resolve this issue? |
"Shoulders" is not a known role for a specification work item :) So, I'd like to make sure that the roles are at least editor or author. @timbl appears to be the current editor of the spec. What role would you like to contribute with @hzbarcea ? I'd appreciate a response to the points in #553 (comment) (in particular copyright). |
Resolved by #578 . Agreed in 2023-10-04 CG meeting to accept as new work item. Some relatively minor todos to follow. |
This is to propose new work item according to https://github.com/solid/specification/blob/main/CONTRIBUTING.md#new-work-item-proposal
The item is to create specs and associated materials for Solid Chat functionality between different clients.
The work is to document existing practice. Existing implementations include
It may be useful to document different levels of conformance
The products of the work may include
Shapes.
An definition of the time series way of storing chat files under the date
A definition of the Class or classes to used for example in a type index
Examples
User guides
Tests?
A list of implementations (existing or under development)
The text was updated successfully, but these errors were encountered: