- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 28 Oct 2023 16:38:46 +0200
- To: Vivien Kraus <vivien@planete-kraus.eu>
- Cc: public-solid <public-solid@w3.org>
- Message-ID: <CAKaEYh+nWO6TA6LbwJbs0qPEK=AnPWkUiAge7jbOc=HRF_Qb2w@mail.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 >
Received on Saturday, 28 October 2023 14:39:04 UTC