Re: Towards Solid Lite

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

Great comments, thanks.

I think we would first need to agree on the absolute minimum subset of the
tests that we cant live without.

For example, I think we need CORS as an absolute must
GET and HEAD to give the same thing as an absolute must

And so on.

There's a danger that the subset would be so small that it would be
useless.  But actually I think even GET + CORS is useful to web developers
today.  This might be a good starting point.

Then we could come to consensus on which of the test items we would want to
add.  There may be some difference of opinions there.

However there could be a signally mechanism by which the servers show which
test they pass in a test report.

I personally would not use typescript but a vanilla JS type thing, with one
of the common servers, so I'd pick one different to you I guess.

Obviously it would take quite a bit of time to put the structure, tests and
implementations in place.

But if there's enough interest I could take a stab at a minimal viable
subset, with a view to a first draft by end of year.  Then see if anyone
wants to implement it in 2024 and review at the end of next year.

The WG wont be finished until at least 2026, so we have time, and we also
get to see what target we are aiming at.


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