Chat Client-Client spec new work item

[timbl]

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

• The SolidOS chat functionality in solid-ui
• Liqid Chat by Jackson Morgan
• A matrix-solid gateway

It may be useful to document different levels of conformance

• without threads
• with threads.
• possibly, with also digital signature

The products of the work may include

• Shapes.

  • The shape of a chat day file.
  • A shape for the chat channel main file, with metadata about the chat

• 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)

[woutermont]

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.

[timbl]

Responding to the requests in in the process:

• Explain what you are trying to do, using no jargon or acronyms.

Write a specification for a person or an organization being able to host a chat channel (like matrix or gitter) on their pod.

• How is it done today, and what are the limits of the current practice?

This is how it is done today.

• What is new in your approach, and why do you think it will be successful?

Not a new approach, existing practice

• How are you involving participants from multiple skill sets and global locations in this work item?

  • [x] technical

  • [ ] design

  • [ ] product

  • [ ] marketing,

  • [ ] anthropological

  • [ ] UX

  • Global locations:

  Not location-based.

  • What actions are you taking to make this work item accessible to a non-technical audience?

  There should be user manuals etc for the implementations but the spec itself is for developers, not users.

[elf-pavlik]

In https://github.com/solid/specification/discussions/549#discussioncomment-6606617 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.

[timbl]

@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

[elf-pavlik]

This is to propose new work item according to https://github.com/solid/specification/blob/main/CONTRIBUTING.md#new-work-item-proposal

@timbl could you please answer this question from the proposal template?

List and link to owners (at least 1 person for advancing the work item and 1 other person).

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.

[hzbarcea]

@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.

[elf-pavlik]

SGTM @hzbarcea :+1:

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 https://github.com/solid/specification/discussions/549#discussioncomment-6606617 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. I can think of a way of taking advantage of SAI Inherited access to solve that problem but this is not an issue to dive into all the details. We should just make sure that this use case is documented and derived requirements included.

[csarven]

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): https://github.com/solid/chat/commit/a1e3fad2ac7b7586f6657887bc8fea72c96ba447#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...)

[woutermont]

[@hzbarcea:] That said, chat and communication should be a core service for Solid, like authn/authz is.

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.

[elf-pavlik]

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.

[woutermont]

[@elf-pavlik:] I think we still need a handful of domains to field-test all the generic specifications.

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.

[elf-pavlik]

I think this relates to what @hzbarcea mentioned during the last call about top-down vs. bottom-up. IMO we can start from both directions and meet somewhere in the middle. If one effort starts with chat + discussion forum + project management + basic media service. We will start seeing some things that can be generalized. As the generalizations are being proposed we should easily be able to compare them to SAI and see if they meet the same security and privacy requirements.

[woutermont]

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.

[jaxoncreed]

It would be great if @jaxoncreed who developed mentioned LiquidChat would also provide some feedback.

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:

chat1/
 - index.ttl
 - 2021/
    - 11/
       - 30/
          - chat.ttl
    - 12/
        - 04/
           - chat.ttl
        - 17/
           - chat.ttl
 - 2022/
    - 01/
       - 08/
          - chat.ttl

The entry point to the chat is index.ttl, but index.ttl does not provide any triples indicating where the content of the chat is stored (it's stored in chat.ttl split between the various dates). This means that developers MUST be aware of the folder structure when implementing chats and cannot "follow their nose," by following links in the initial document. It also means that developers MUST split chats by date, and there very well might be other ways developers might want to split chats.

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 append access to a chat (as is the case for the current implementations), it's completely possible for me to append a message claiming to be a different person. Liqid-chat had a hacky work-around where every message included a signed credential from Liqid Chat (through a <https://liqid.chat/terms/liqidChatSignedCredential> predicate). This is obviously not a feature that can be interoperable because only Liqid Chat has access to the private signing key to generate the credential. The solution to this is building infrastructure to give every user their own signing key so that they can create a credential to prove the provenance of their chat message (or any other data in Solid).

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 http://www.w3.org/ns/pim/meeting and http://rdfs.org/sioc/ns#, two vocabs I haven't seen used outside of this context.

[elf-pavlik]

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 honestly think that this effort can actually help us clarify the benefits of general approaches like those used in SAI. Of course, this draft starts with 0.1 and we all should expect breaking changes or even being superseded with an alternative draft if we encounter a need for major redesign.

[TallTed]

competing reports

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.

[mrkvon]

take the opportunity given by implementation @mrkvon is working on

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 http://purl.org/dc/terms/references predicate (i.e. one chat references the other, and together they give the whole conversation)

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.

I would much rather it be more in line with the activity-pub/matrix world as that already has some adoption.

:100: 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).

[hzbarcea]

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.

@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.

[woutermont]

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.

[elf-pavlik]

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:

If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional W3C Community Group Charter Template contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point.

I think while we work on some example domains we will have a better chance to understand the benefits of generalized approaches like SAI.

[woutermont]

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:

• Apart from @timbl, is @hzbarcea indeed the second person to put his shoulders behind this proposal?

• Can we confirm that this specifically concerns the work started in solid/chat?

• The concern @csarven raised about the copyright change in that document: if this is accepted as a CG work item, it will fall under the CLA and be copyright of the W3C rather than the Solid Project (like all our documents are).

[TallTed]

Again, special topic meeting has incorrect link. This is correct link.

[hzbarcea]

• Apart from @timbl, is @hzbarcea indeed the second person to put his shoulders behind this proposal?

Confirming.

[michielbdejong]

@mrkvon

I personally like the approach pod-chat.com has taken: each participant in the chat hosts the messages they authored

That's also what I did in https://pdsinterop.org/conventions/chat/#one-to-one-chat

[hzbarcea]

So what are the steps required now to resolve this issue?

[csarven]

"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 https://github.com/solid/specification/issues/553#issuecomment-1687023788 (in particular copyright).

[csarven]

Resolved by https://github.com/solid/specification/pull/578 . Agreed in 2023-10-04 CG meeting to accept as new work item. Some relatively minor todos to follow.