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?

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