Re: Towards Solid Lite

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?

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

Received on Sunday, 29 October 2023 14:41:42 UTC