Re: Towards Solid Lite

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 

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

Received on Monday, 30 October 2023 21:23:20 UTC