Re: next step for the Solid WG charter

On 2023-11-21 09:34, Kjetil Kjernsmo wrote:
> On fredag 17. november 2023 11:30:17 CET Pierre-Antoine Champin wrote:
>> : "we see an extremely broad problem space, and a single proposed
>> solution".
> 
> Indeed, I think that's a very fair description.


It is, but then again, we made no serious attempt to 
introduce/welcome/incorporate other/similar approaches. We have NIH/FUD 
syndromes :)

A revision to the charter should suggest solution *areas* (deliverables) 
to be discussed in the WG and that x, y, z (specs) can be used as input.

> If the Solid community, several years ago, had focused on bringing genuinely
> useful stuff that could be used right now to people, like late Aaron Swartz
> urged us to do many years ago:
> https://lists.w3.org/Archives/Public/public-sweo-ig/2006Dec/0138.html
> then, we might have been able to show that this single solution had merit. But
> that opportunity has passed, in fact, it might have already been to late in
> 2006.

Totally. I find all that to be social problems, not technical.

A lot of time is wasted on apathy and pedanticism.

It makes no sense right? We have much bigger vegan-fish to fry but here 
we are..

>> If I had to give an elevator pitch of the Solid protocol (i.e. the
>> expected deliverable of the proposed WG), it would be :
>> * a evolution of the LDP protocol


Solid Protocol is essentially not an evolution of the LDP protocol. 
Endlessly studied and lessons learnt? Definitely! I'll offer a 
background in a nutshell:

SP builds on HTTP.

Server implementation experience was used as input for the SP. LDP was 
briefly assumed to be what was being built upon but none of the servers 
actually conformed to LDP - ask me how I know - or required as per the 
early documentations of the specification or the CG's initial release of 
the specification (up until now).

Essentially that was about having the notion of the LDP Basic Container, 
placing something in a BC, containment statements, protecting 
containment statements. (I'm sure if you squint enough or dig around, 
you may find other things but that'll miss the point here.)

We've had endless discussions about the limitations of LDP for what we 
wanted Solid (Protocol) help us do. It wasn't enough. (I'd argue that SP 
is still not enough but that's another story..)

We've also considered using Solid's own solid:Resource (similar to LDP's 
interaction type), solid:Container (you guessed it) and solid:contains 
(essentially same as ldp:contains). In fact, if we added those and 
possibly another thing or two, we do not need to talk about LDP at all.

>> * + a standard way of authenticating users
>> * + a standard way of specifying access control
>>
>> So my idea is that, instead of pushing for a "Solid WG", why not propose
>> an "LDP 2.0 WG", chartered to produce 3 specifications : LDP 2.0
>> (client-server protocol), LDP-OIDC (authentication based on OIDC) and
>> LDP-AC (access control).


This is rebranding Solid to LDP.

Even if you were to paint Solid as LDP 2.0, the underlying problem that 
TAG and AC reviewers are raising won't be addressed.

LDP-OIDC makes no sense to me but if it does, I'm sure you can tell me 
LDP-HttpSig would too. Besides, you went from "specifying access 
control" to specifically LDP-OIDC. How is that in any way not a "single 
proposed solution" besides it not technically existing on paper, or that 
I fail to see a meaningful relationship between LDP and OIDC (based on 
Solid-OIDC I presume) beyond just use of JSON-LD. I mean, on a related 
note, we are even entertaining arguments about how a Solid WebID Profile 
does not need to be on a Solid server or writeable by its owner. You've 
read that right. Looking forward to marketing departments spin on that 
that control your own stuff =)

Besides all that, what you are actually suggesting is not just a mere 
change to the charter but the actual specs going in. WG should 
deliberate on what the specs may be. Again, to my earlier suggestion 
about having a just broad-enough deliverable description where there are 
a number of spec inputs. Some charters have done this for years (Social 
Web, Web Annotation..) I'm suggesting we revise along those lines.

(And maybe get a quick TAG review before running off to AC review? :) 
TAG has other useful input for us.. and some incorrect or inconsistent 
views from past reviews.)

That way, you/we can rally up folks/groups.

For example, there is great work in Fedora API Specification:

https://fcrepo.github.io/fcrepo-specification/

that can be used as input alongside the Solid Protocol. It covers 
versioning which is something the the Solid Protocol doesn't - although 
you can bet that we have loads of issues/deliberations on that too. It 
partly builds on LDP, but that's not the point here. The actual point is 
that all of these similar specs can be used as input towards a 
client-server protocol.

Ditto picking up notes/specs/drafts LDP Next left behind. Or at least 
better understanding *why* it didn't go forward right? I mean, you are 
pitching LDP 2.0 but not talking about why LDP Next didn't move forward 
either.

(I'm ill and my memory is not serving me well as I write this but there 
are other works that smells like SP or Fedora or whatever..)

Lastly, for such WG to go off on addressing some individuals and groups 
needs in society and leave out the "social" aspect falls short of the 
promise. From the spec end of things, that touches on notifications, and 
social agent profile descriptions, among other things. This should be 
integral.

Ditto hinting at server-server possibility. Because the Social Web / AP 
folks do want to move AP stuff forward too.

client -> server1 ( I published an article on my website )
server1 -> server2, server3 ( My server sends notifications to my 
friends or any defined shape of interest to send notifications to)

(I asked us to take server-server protocol seriously.. last century, 
that'd be a net gain for the Solid Project (to reach even wider interop 
with AP/Fediverse..) Or maybe I'll mention again in 10 years =))

> Without being engaged anymore, what I found, partly as working as Solid Editor
> for several years, is that LDP is a extremely overcomplicated and incoherent
> specification. Building on LDP to cover a broad problem space and getting wide
> acceptance is unlikely to succeed.

> LDP is basically the wrong thing to stick to going forward. Instead, the WG
> should be more open minded towards communities that do not see LDP as
> foundational, and see how knowledge graphs, hypermedia and self-contained
> semantics can be incorporated in that.
> 
> Kind regards,
> 
> Kjetil


I agree with Kjetil. Though, I would say the general understanding in 
the CG, including SP editors and many of its contributors.

Where are all the applications that can work with LDP 1.0 (2015) 
servers? If there is nothing significant to show, why are we investing 
more time on this than necessary?

We didn't dismiss LDP but way forward is not "LDP 2.0". "2.0" is a major 
change and wouldn't do anything beyond renaming Solid to LDP, and then 
forcing the WG to re-do/consider all that's been done in this Solid CG. 
It is not WG's place to go back to the drawing board (although 
everything is always on the table if there is a "problem"). Take a bunch 
of inputs, come up with something even stronger. If the Solid CG hasn't 
reached consensus (for any reason) on a particular problem space, then 
we should benefit from others' works. Can't say this enough.

Now I need to rest.

-Sarven
https://csarven.ca/#i

Received on Wednesday, 22 November 2023 12:54:25 UTC