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.
>
> 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?
>
> 2. how does a Solid pod fit into the fediverse in terms of identity and
> open-ended data types
>
> 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
>
> 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.
>
> 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.
>
> 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?
>

Hi David

Have a look at this, I have completed draft 0.0.1.  I will work on a
javascript server now.

https://solid-lite.org/

A typescript implementation would be welcome!

Perhaps different node servers would help with diversity, if so.

The MUSTs are very light, and everything else will go in extensions.  So
the code might take no more than 500 lines total.  Wouldnt that be nice!


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