Re: Towards Solid Lite

po 30. 10. 2023 v 22:20 odesílatel David Mason <vid_w3c@zooid.org> napsal:

>
> Hi again, thanks for your reply.
>
> On Mon, Oct 30, 2023 at 08:18:15PM +0100, Melvin Carvalho wrote:
> >    ne 29. 10. 2023 v**15:43 odes**latel David Mason <[1]
> vid_w3c@zooid.org>
> >    napsal:
> ...
> >      While I'm interested in Solid, I've been on the sidelines for the
> most
> >      part. A few years ago I made my own cargo-cult LDP implementation,
> and
> >      I set up a version of node-solid-server, but had to drop it to
> >      concentrate on full time work.
> >
> >    Great stuff.** Did you find your LDP implementation useful?** Do you
> still
> >    use it today?
>
> It was educational, but I got bogged down on a few details. I really just
> wanted to explore the juncture of Solid, Verifiable Credentials, and a
> markdown
> approach to creating linked data. I did try to use NSS but some things
> never
> seemed to work right, probably due to my own fog, so thought it might be a
> good
> exercise to create the essential pieces.
>
> I really got quite overwhelmed trying to keep up with or pretending I could
> participate in all the committees, chats, pages, and implementations, it
> was
> just too much with a day job, even though there could be a very strong
> applicability to that day job (standards & open source, though I'm just an
> opinionated worker in the group). I had a few Solid accounts on community
> servers, but they fell to attrition. Frankly every day I gain and lose
> ground
> in new practices, this tech has to help with that, not make it worse.
>
> >    What minimal viable use cases would you want from a simple solid
> (lite)
> >    server?
> >    I would say:
> >    - host identity (profile pane)
> >    - host user generated content (data pane)
> >    - view and edit source (source pane)
> >    any others?
> >    **
>
> Just as you've outlined, 'the basics,' but I think access controls and a
> database (below) are two key features that I know make discussions go into
> hyper complexity. But I don't think there's enough without them.
>
> What I'm mostly thinking about is putting it in a plain language test suite
> intended for everyone, including end users, so they have a path for deep
> understanding, in a show and tell / learn more kind of way. Simple
> sentences
> that can be put together to explain Solid apps. The educational element
> would
> make Solid a lot more interesting and appropriate, imo.
>
> To support that, specifying, verifying and documenting (including the
> "why")
> each feature, as a component of flows, would be really helpful, in
> something
> like a computational notebook environment.
>
> This is probably all available today, but as you pointed out below, the
> spec became more complex. From what I've seen, there really have been an
> extraordinary number of libraries, components and programs. If there's
> going to
> be a fresh-start simple route implementation, it should be able to learn
> from
> all the previous work but I don't think "just do it" is the right answer.
> I'd
> start with BDD tests for the component flows.
>
> >
> >      2. how does a Solid pod fit into the fediverse in terms of identity
> and
> >      open-ended data types
> >
> >    In theory compatible, in practice not.
> >    Solid is primarily 5* Turtle and RDF
> >    Fediverse is a different kind of JSON, and maybe 60%-80% RDF
> >    **
>
> imo it would be worth it to hold one's nose and find a way to make
> fediverse
> data fit into a Solid pod.
>
> I guess they will get to that in "Let's have a joint Solid CG and Social CG
> meeting" also on this mailing list.
>
> >
> >      3. what is the database of a simple Solid pod? this would be a large
> >      part of the value, and unless it's fully swappable, something people
> >      should know before buying in
> >
> >    It should work with simple file systems.** Anything more is a bonus.**
> >    What database did you have in mind?
> >    **
>
> It should be able to parse designated data files (JSON-LD, turtle?) in an
> *opportunistic* way (whatever a ready, supported, good quality library
> offers).
> It should support simple auth at the field level. It should allow basic
> queries, including ideally the most basic entailment. It should support
> publishing query results in a Linked Data format for federation. I think
> it is
> kind of pointless without these features. It should also provide or be
> built in
> a way to support queries that leverage the specialness of the data in a
> simple,
> obviously distinct, useful and accessible way, the larger "why are we doing
> this" (aside from decentralizing content) for example, shortest path or
> even a
> toy reasoner that the user can puzzle with (I'd literally like to see that
> a
> game people could while at in their spare time, without overselling the
> value
> of a simple reasoner).
>
> Implementation-wise, it should be as self contained as possible, with
> processing happening on the server or client. I suppose something like this
> could be useful, if it doesn't have too many thorns:
> https://github.com/jacoscaz/quadstore


Just covering this one point for now.  So a big design decision is files vs
database.  NSS is files, for example.

If going for a database the feature set you describe is quite big.

Certainly possible, but I'd be concerned that a lite spec would be losing
its "lite" tag if straight off the bat it was offering more than NSS

Reason being that I'd like something that could be implemented quite quickly

The other option would be a lightweight quadstore or JSON(-LD) library in
common usage that has been battle tested.

Just some high level thoughts, all is up for discussion

When you said it should be no more than a few thousand lines of code, I had
to double take.  My hope was for something to start with under 1000.  Am I
being hopelessly naive?

I mean even in CSS if you do a search for communica alone, there are over
3800 files.  Yes, files!  Not lines of code.

My mental modal would be to cut out 90% of the rarely used items.  And
focus on the 10% most valuable, that provides 90% of the common use cases.

Then after folks can see what Solid can do, they can get interested in
finishing the other 10%.  Or whatever that number is 20% etc.

>
>
>
> The simple server shouldn't be more than a few thousand lines of code,
> relying
> again on good quality support libraries, with interfaces for more advanced
> features. For example, the provided access control could be simply
> private/public. It might be possible to use full-spec Solid interfaces for
> this
> purpose, but I have a feeling most spiral into complexity.
>
> At a certain point containers &c make sense, in fact they can drastically
> simplify things, but they can also create a barrier, so to be inclusive the
> whole thing should start with at most a couple commands and a very basic
> config
> file. It would probably be smart to base it on an accomodating existing
> widely
> used web framework, but I haven't used much past Express.
>
> >    I guess most people here wont know this but we made the original solid
> >    spec in a weekend.** When I say we, it was almost all done by
> Andrei.**
> ...
> >    Part of the motivation for a lite spec would be to recapture that
> >    developer enthusiasm and DX (which peaked around v0.7) so that new
> >    developers can get started easily, and have ah upgrade path to new
> >    features.
>
> It's great to hear this backstory, and confirmation for the idea of a lite
> spec.
>
> >      An example use case could be a fediverse adjunct someone could use
> day
> >      to day, that enables bookmarking their favourite conversations. I
> >      don't think it's smart to ignore fediverse, it has and deserves the
> >      momentum today, but this would be a way to build out the linked data
> >      facilities usefully.
> >
> >    Yes this could be done.** These are the kinds of micro apps that
> would be
> >    useful, and that it would be useful to guide users to build without
> them
> >    needing a big learning curve.
> >    I'll note a little project I have in design which could unite
> fediverse
> >    and solid via micro services:
> >    [3]https://microfed.org/
> >    **
>
> That looks really smart and appropriate.
>
> I wonder if a spec / verification tests / documentation of features that
> together serve as a tutorial could be a good "product." It could be built
> around a project like tracking a subject based on fediverse and local
> content,
> and answer questions like "who do I know that said something about this
> topic?"
>
> Ultimately,  as in your project, even Solid Lite needs to be more than a
> personal Web file folder, it needs to look to fediverse, it could need to
> look
> at what's happening in Large Language Models, which past all the hyper are
> so
> useful.
>
> Going back to outer space again, but *opportunistically* on Solid bones,
> these
> days we can run decent summarizing and extraction tools locally, even in
> the
> browser[1]; anyone could curate their own knowledge store. [2] is such
> wonderful inspiration in terms of linking symbolic with vector knowledge,
> so it
> should fit into that world. Maybe we could help move the Web from the 1990s
> pages and links and BBS style comments with 21st century exploitation, to
> shared knowledge stores with well-described information and reliable
> decentralized digital assistants.
>
> I am still curious about how semapps might fit into this. I could probably
> research it myself, but I don't want to get into the rabbit holes again.
> Anyone
> on that project on this list?
>
> David
>
> [1] https://github.com/huggingface/candle
> [2] https://docs.cozodb.org/en/latest/releases/v0.6.html
>
>