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?

• 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 #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.

[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 👍

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

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