Re: Towards Solid Lite

ne 29. 10. 2023 v 15:43 odesílatel David Mason <vid_w3c@zooid.org> napsal:

> Hi all, I hope you don't mind me jumping in, these convos often seem to
> be the same people. What follows is opinions and ideas and
> propositions, which since I haven't participated in a while go in
> some directions, still I hope people can use the principle of reading
> people's words with charity, cause I could use it. (-:
>
> 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?


>
> A big part of my work is to try to make very transparent, spec driven
> "tests." I put tests in quotes, because I think somewhere concepts
> should concretely link to specs, into the implementation, to the
> documentation, these days to the LLM which can answer questions or be
> its interface (particularly interesting in connecting symbolic with
> deep learning approaches), which as a whole should be verifiably
> consistent, up to date, and useful to developers and end users; a "view
> source" of how it all works.
>
> Maybe instead of users getting hooked on Instagram and, over time,
> learning all its labyrinth and corporate biased ways, there could be a
> way to make Solid their interest; their data garden and shared
> knowledge, their gateway into ideas, a more specific, less "click on
> this thing" way to connect and secure information, and so on.
>
> I feel like the best solution would counter how the web has gone from a
> pretty simple idea, where everyone always had someone they could ask
> "what does this mean," into a lot of block box/rube goldberg machines;
> into a more dystopian world.
>
> Here[1] is a recent presentation on this transparent approach. I am
> working toward the viewer being able to link right into the tested
> source code because it can and should. Please don't get turned off by
> the fact screenshots are in Azure, it's environment independant. I've
> been working on this approach (Haibun[2]) for a few years, however it's
> a slow project and I don't have the capacity to support it for more
> projects. But I'd consider working on specific puzzle-piece Solid tests
> that are generally useful.
>
> I notice solid-contrib/specification-tests[3] is now using a somewhat
> similar approach, BDD for Python systems. Obviously Python is a
> widely used language and "Karate" is a more widely used test suite, but
> I think it takes the project into the server-side Python world rather
> than learning about web standards and viscerally "inside" the browser
> as Haibun is meant to, including a focus on composable flows with
> maximum reusability. In other words, something like Karate is only for
> the product test team. There is a resistance to "ball of wax"
> approaches to instead make each concern separate, but I think there
> are ways to avoid problems like "the tests pass because they're the
> library."
>
> Personally, I am focused on Javascript for its isomorphic properties,
> but I am genuinely puzzled by the resistance to Typescript. It is an
> extremely helpful approach to large projects in Javascript. These days
> I don't want to touch any code that is written in plain Javascript, and
> there's a reason very few significant projects don't use Typescript for
> its benefits. At the best of times, coding is like solving crossword
> puzzles, Typescript enhances this experience immensely, makes using
> libraries much more clear, and makes refactoring much more practical.
> Polyfills are hardly an issue these days, so bundling using tools like
> rollup really doesn't add much overhead. Pretty much all the "worst of
> times" versions of this are because of untyped Javascript and untested
> code.
>
> I also think it's important to recognize current "trends" and missing
> pieces for even or especially a simple relevant implementation, and
> address them;
>
> 1. what are some use cases of this simplest Solid server?
>

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?


>
> 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


>
> 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?


>
> Maybe it's not obvious, but what I'm trying to say is make the spec a
> manageable learning experience (it's impossible and kinda
> unforgivably craycray-making for most people to try to stay on top of
> all the formal spec outlets), that links into the implementation, that
> provides out of the box useful solutions, that addresses important
> trends today.
>

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.

The reason was that Solid's participation was at risk because it was a
working system (back then it really was!) but with no formal spec.

We had it all in our heads form what we'd done in the read-write web
community group, so Andrew just wrote it all out.

It was simple, useful working, and popular.  The whole thing was about 5
pages, and easily implementable, it was easy to build an app.  As an app
maker I was able to build one micro app in a day.  It's harder now

After that the spec grew increasingly complex, and developer interest also
lessened.

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.

[image: image.png]



>
> 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:

https://microfed.org/


>
> But I just want to add a couple questions to my open-ended message; how
> does https://semapps.org/ fit into all this? And is the Belgian
> government producing any open work we can refer to?
>
> David
>
> 1.
> https://docs.google.com/presentation/d/1dNNzyAijC51wpWK5B00d4t1oJeUKQOMeMwgm6zjQuE8/edit#slide=id.g29412c50876_0_26
>
> 2. https://github.com/withhaibun/haibun/tree/reworking-artifacts
>
> 3. https://github.com/solid-contrib/specification-tests/#karatedsl
>
>
>
>