Re: Towards Solid Lite

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!
* 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.
* 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.

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.

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.

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

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