Re: Towards Solid Lite

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
>