Re: Towards Solid Lite

Joining in applause. I might be something of a contrarian, but this is
solid work (sorry for any inadvertent pun).
*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>


On Thu, Nov 2, 2023 at 4:01 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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