Re: Towards Solid Lite

ne 29. 10. 2023 v 10:47 odesílatel Michiel de Jong <michiel@pondersource.com>
napsal:

> Thanks for bringing this up Melvin, I agree with a few important points
> here. In my words:
>
> * the 0.10 spec has become quite complex in terms of how the DPop tokens
> work for simply accessing a document, and this makes it hard to tinker
> with. Compare for instance to
> https://datatracker.ietf.org/doc/draft-dejong-remotestorage/ which has a
> much simpler approach to GET/PUT/DELETE with OAuth, and which both you and
> I contributed to in the Unhosted CG. And it was mainly you who, around 2013
> I think, reached out from the Solid CG to the Unhosted CG to promote
> collaboration between these W3C CGs, thanks again for that!
>

Thanks for the reminder.  The main issue was that Solid used URIs for
identity, and remoteStorage insisted on user@host for identity

Back then I was trying to converge the two, does it make more sense now?

I realized this morning that there's a set of principles that informs not
only solid-lite, but solid 1.0 and remote storage, that talks about reading
and writing to the web.  I wrote this, this morning, which is more a stub
than a draft:

https://www.w3.org/community/rww/wiki/Principles

I think
AWWW
-> RWW Principles (general)
  -> Solid (specific)
  -> Solid Lite (quite general)
  -> Remote Storage (mix)
  -> Others



> * for years, not in the least through my work in the Solid Test Suite
> Panel, I have been one of the most die-hard proponents of an “all or
> nothing” Solid spec so that all Solid apps will work with all Solid IDPs
> and all Solid storage servers. However, informal discussions we had at TPAC
> (among others with members of the Internet Architecture Board) made me
> change my mind, and realise that a monolithic Solid spec also has
> downsides, so I’m now thinking more about how Solid can be a more modular
> concept.
>

Solid was always supposed to be designed as a modular set of specs.  It did
have idea drift towards a monolith in recent years.  Both models can work.

It's good to have different approaches to doing things, IMHO


> * even within the 0.10 spec there are choices, like WAC or ACP,  and if
> you look at newer (proposed) spec features like UMA and SAI, they can be
> used without either of them, and maybe that provides an opening for
> breaking open our notion of what Solid is.
>

I guess different people will have different opinions on WAC vs ACP vs UMA
vs SAI.

Again it comes down to the modular vs monolith approach.

If you have to support all that gives a lot of complexity though.

>
>
> As an example outside of Solid, think about how browsers are free to
> support any subset of the things a progressive web app needs, a user agent
> could even be text-only and we would still call it a browser, thanks to the
> “graceful degradation” architecture of the web. Maybe we can do something
> similar for personal data stores.
>

Yes, many projects are moving in that direction


>
> I’m also looking forward to reading what Robin Berjon will write in
> https://berjon.com/next-web/ and hopefully we can make Solid something
> that’s more than just some grand-sounding RDF-thing that others can safely
> ignore.
>

He is a so-called "web3" advocate.  I find most of the arguments of that
group unconvincing, and share the opinion of many that "web3" has nothing
to do with the web.

Too often they write about creating a "new web", normally powered by their
premined token.  I dont call this an open web, I call it a prison.  If i
have to pay a royalty to change the state of my data, that is not to my
taste, and I'd argue that it was not the spirit in which the W3C was
created.

Instead of making a new web, I much prefer to use the existing web and push
it to do more things.


>
> Let’s think about how we can develop these ideas further!
>

Great, thanks alot for the encouragement!


>
> Cheers,
> Michiel
> On Sat, 28 Oct 2023 at 19:47, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> so 28. 10. 2023 v 19:08 odesílatel Aron Homberg <aron.homberg@mailbox.org>
>> napsal:
>>
>>> Hi Melvin,
>>> Hi Vivien,
>>> Dear Solid community,
>>>
>>> I'd definitely welcome something like a Solid Lite spec, or in other
>>> words, a minimal viable subset of the Solid spec being defined as a
>>> starting point for developers new to Solid, like me.
>>>
>>> I've read/analyzed the code of NSS and CSS and also read some parts of
>>> the specs, made a few experiments etc., as this is usually how I learn in
>>> the most efficient way: The pragmatic way. I believe that I'm also familiar
>>> with most concepts... but there's still a lot to learn for me.
>>>
>>> I was also thinking about implementing the spec myself aka. "If you can
>>> build it, you truly understood it"..., but given the size of of the spec,
>>> it seems like quite alot of work. Having a defined set of features for an
>>> MVP-style Solid server would be much appreciated.
>>>
>>> The tech-set I'm thinking about is Astro + TypeScript + React for the
>>> frontend, and the backend implemented with Node.js + TypeScript in a more
>>> functional and "serverless" architecture (lamba functions, basically, and
>>> as horizontally scalable as possible, even though this is probably not
>>> necessary atm.; just as a fancy design goal). The impl. I imagine would be
>>> modern, less complex and able to be one-click deployed & hosted on Vercel,
>>> Netlify & co. with a single click (fork on Github, depoy via cloud based
>>> CI/CD), and for free (for personal use at least).
>>>
>>> I think something like a Lite spec + most simple impl. could maybe also
>>> attract a wider developer community...
>>>
>>> However, I'd like to suggest that such a Lite spec should better not
>>> derail from the main spec too much but rather just pick the important parts
>>> (if thats even feasible), if it is intended to be compatible with existing
>>> implementations. "Derailing" would probably create chaos and effectively
>>> become a spec fork, as soon as the diff is too large. "Lite"
>>> implementations would then become non-interoperable with NSS, CSS etc.
>>>
>>> The test suite is pretty amazing, I must say. If defining the "Lite"
>>> subset of the spec would start with marking the necessary paragraphs with a
>>> tag and simply providing only the relevant subset of the tests as a  "lite"
>>> testsuite subset, it would be a pretty straight-forward and pragamatic
>>> approach that I'm sure, would help developers like me, navigating the most
>>> important parts.
>>>
>>> However, one concern I have is, if it would be even feasible to define a
>>> Solid Lite spec without derailing? Like... how would CSS and NSS deal with
>>> a server only implementing half of the endpoints / data models / modes /
>>> etc.pp. ? :)
>>>
>>
>> Solid Lite servers should send some kind of header saying that they dont
>> implement the full spec.  Then CSS and NSS will know what to expect, and
>> they should be back compatible with the plain old web anyway by the time it
>> gets to 1.0 REC.
>>
>>
>>>
>>> Even if all tests are green, the system would not coherently behave "as
>>> intended by the main spec". I can only guess, but my guts feeling is that
>>> the error handling of current impls. would not cover such cases of "missing
>>> data" etc. or behaviour change like "link instead of n-depth-level-object"
>>> etc., ...and all that essentially already means that once a Lite spec is
>>> born, CSS and NSS would need to handle those "missing feature"/"small
>>> different behaviour" cases to be interoperable with future Lite servers?
>>>
>>> Well... Please correct me, if I'm wrong.
>>>
>>> Thanks and best,
>>> Aron
>>>
>>> ---
>>> https://github.com/kyr0
>>> https://fluctura.com
>>>
>>>
>>> Am 28.10.2023 22:38 schrieb Melvin Carvalho <melvincarvalho@gmail.com>:
>>>
>>>
>>>
>>> so 28. 10. 2023 v 16:21 odesílatel Vivien Kraus <vivien@planete-kraus.eu>
>>> napsal:
>>>
>>> Hello!
>>>
>>> Le samedi 28 octobre 2023 à 15:34 +0200, Melvin Carvalho a écrit :
>>> > What do folks think about a simple lite subset of solid, with a
>>> > streamlined process, set of test, developer on ramp, lighter process
>>> > and useful eco system with full upgrade to 1.0 when it is there, via
>>> > adding additional tests, from the test suite.
>>>
>>> I definitely would like a lighter specification, as I would like to
>>> implement my own server and client. Obviously everyone would want their
>>> own definition of “light”, so maybe this would not be as useful as
>>> wanted.
>>>
>>> Here is my idea for a complexity ladder:
>>>
>>> 1. Everything is either public or private to the “owner”. Authorization
>>> is much simpler, authentication need not be decentralized.
>>>
>>>
>>> +1
>>>
>>>
>>>
>>> 2. Everything is only writable by the “owner”, but other people can
>>> read specific parts with (read-only) WAC. Authentication is done with
>>> HTTP signatures.
>>>
>>>
>>> +1 good starting point
>>>
>>>
>>>
>>> 3. The DPoP-based authentication scheme is supported.
>>>
>>>
>>> +0 DPoP is still quite complex and a learning curve, perhaps that could
>>> be in the upgrade path?
>>>
>>> I still dont fully understand DPoP inside out.  Could it be simplified?
>>>
>>>
>>>
>>> As for other features, I would say:
>>>  - json-ld is too complex to implement; there are libraries for some
>>> languages but not all, and as we saw with ActivityPub, most projects
>>> won’t use them anyway;
>>>
>>>
>>> It's hard but useful, there does need to be some way to do data+links,
>>> even in JSON
>>>
>>>
>>>  - trying to sandbox applications is a bad idea in my opinion; we
>>> should rather empower user to reject malicious applications;
>>>
>>>
>>> +1
>>>
>>>
>>>  - I don’t think we should let other people write to our own pod. As we
>>> saw with ActivityPub, we can have decentralized discussions where each
>>> actor host their side of the discussion;
>>>
>>>
>>> +1 that could work, but use cases such as chat become harder, where do
>>> you write to?
>>>
>>>
>>>  - LDN inboxes should accept only links, and the sender should host
>>> their notifications on their own pod, so that we don’t have to check
>>> who is posting to our inbox. If the link dereferences to a notification
>>> hosted on someone’s storage, then we can trust it is not forged.
>>> Notifications can also be retracted or edited more easily;
>>>
>>>
>>> There was actually a system like this about 15 years ago called ripple,
>>> I'll see if i can find some links to it.
>>>
>>>
>>>  - automatically editing RDF resources (when the containment triples
>>> for a container change, or when processing a PATCH request) is a little
>>> uncomfortable, because we lose some of the readability of Turtle
>>> (comments are discarded, blank nodes are made explicit). I don’t think
>>> it is a big problem though.
>>>
>>>
>>> we could start with simpler ways to edit, simple use cases, such as a
>>> JSON patch, not sure there
>>>
>>>
>>>
>>> Please don’t get disappointed if your idea of a lighter specification
>>> is the exact opposite of what I describe here!
>>>
>>>
>>> I love it, thanks alot!
>>>
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Vivien
>>>
>>>
>>>