Re: Input needed on the scope of use cases for the LWS Protocol v1.0

Hello Christoph!

> - How do we define the boundaries of the core protocol? For instance, our charter [1] tasks us with a web protocol for client-server interactions. How should we approach e.g. use cases that require standardizing primarily local, offline-first behavior ([UC#24], [UC#101]), which are not explicitly mentioned in our deliverables?

Insofar as my understanding of the scope of this group, these use cases should not be approached at all. They simply fall outside of the scope. This may sound adversarial but I assure you I do not mean it as such, not even in the slightest. I admire what NextGraph is building, for example, and the fact that effort is being put towards making NextGraph compatible with Solid is a wonderful thing. Insofar as possible, this group should try not to inhibit these efforts.

However, as I’ve recently argued in [1], specifications must be constrained in order to have reasonable chances of widespread adoption and real interoperability. As such, I believe that extending the scope to use cases outside of the client - server model or to use cases depending on protocols other than HTTP would prove extremely counterproductive, leading to a level of complexity that this group would be unable to contend with.

> - What is the role of the LWS protocol versus the applications built on top of it? For demanding requirements like non-repudiation ([UC#14]), end-to-end encryption ([UC#44]) or data verification ([UC#138]), should our focus be on ensuring the protocol supports it, or on standardizing the implementation of it?

I suggesting starting with merely supporting these requirements and then, *after* having delivered a first version of the spec, progressing onto standardisation. Preferably after having seen real growth in adoption. IMHO, standardisation without any sort of market feedback is extremely likely to fail.

> - How should we interpret ambiguous requirements? Concepts such as "verifiable proof" ([REQ-F#141]) or "verifiable consent" (as in the current Use Cases draft document [2]) remain open to interpretation. A shared understanding of what these terms mean in the context of our charter would help us focus our design.

I do not think that interpreting ambiguous requirements should fall on the shoulders of this group. Given clear, unambiguous requirements, this group should decide whether to cater for them or not. However, the burden of clarity should fall on the shoulders of those who present the requirements. For example, looking at [2], one cannot help but think about things like PGP signatures, Verifiable Credentials and the likes. Proposing support for one or the other is something that should be done by proponents of that use case, just as explaining exactly what is meant by “verifiable”. 

IMHO, and critically, this group does not have the resources to research and specify all use cases that could potentially be catered for. What this group should do, however, is engage and foster a community of proponents willing to work on their use cases until sufficient levels of clarity are achieved.

Obviously, this applies to my own use case [3], too, which at the moment is *extremely* under specified. I would have to do a lot of work on it in order to formally present it to the group for consideration. This is a *good* thing, not a bad one. Presently there does not seem to be much interest in it and I can’t justify allocating time to it; it is only right, therefore, for the group to leave it aside. However, it’s still good to have it on GitHub, even as an underspecified draft, to gauge interest.

Once again, I do not mean any of the above in an adversarial manner. However, we’ve already seen efforts in this space collapse into nothingness and I’m worried that by taking on too many things all at once we’re inadvertently setting ourselves up to repeat history.

Best,
Jacopo.


[1]: https://github.com/w3c/lws-protocol/issues/24#issuecomment-2961798432
[2]: https://github.com/w3c/lws-ucs/issues/141 
[3]: https://github.com/w3c/lws-ucs/issues/6

Received on Friday, 11 July 2025 13:41:36 UTC