Re: Choosing community-owned code to run on our community server.

čt 28. 9. 2023 v 11:18 odesílatel Emelia Smith <emelia@brandedcode.com>
napsal:

> Hi all,
>

Hi Emelia, thank you for your insights


>
> Even though I'm no longer super involved in the Solid project or related
> projects (I'm working on stuff in the Fediverse now), I do contribute my
> thoughts to this thread. I tried to send this earlier but it seems my post
> didn't get delivered.
>
> Overall, the response from the IMEC / UGhent team in regards to "Community
> Solid Server"'s repository and functionality is incredibly poor, and quite
> frankly is abusive and harassing in nature. The way they engage with
> feedback is not professional, and drives people away from contributing to
> Solid Project and "Community Solid Server".
>
> Previously, I've personally been yelled at by a member of this team when
> I'd privately raised concerns about the CSS project's codebase and quality
> in an internal Inrupt chat, where I'd noticed some aspects of it that could
> lead to potential security issues (due to not following principles of
> defence in depth). I didn't realise they were even present in that room, as
> I didn't know of Inrupt's involvement in "Community Solid Server" at the
> time — I thought I was talking to a group of peers at Inrupt. This was one
> of the contributing factors in me leaving Inrupt and the solid community,
> amongst other issues.
>

Sorry to hear about your experience. I've also had concerns and have shared
them with leadership. Agree that quick action is needed to address these
issues for the sake of the project and individuals involved.


>
> See also, the way they engaged on the "what is a pod" discussion that
> happened between Ruben and Tim. That was not a healthy moment for the Solid
> Project.
>
> Certain people on the IMEC / UGhent team tend to act in narcissistic and
> egotistical ways, putting their own qualifications and egos above those of
> people who have differing experience and qualifications who are giving
> feedback.
>
> For context: I've been working with Node.js and contributing to it's
> codebase since v0.0.95 (late 2009), and have frequently been the tech lead
> on many production-grade node.js projects, many which are still in
> production today, years on. I have never witnessed a codebase quite as
> confusing and hard to follow/understand as that of the "Community Solid
> Server", and I have the impression that this is actually by design, as to
> prevent it from competing with Inrupt's Enterprise Solid Server.
>
> My understanding is that the "Community Solid Server" was designed as a
> research server implementation, not as a means for operating your own
> personal solid server, nor for building a pod provider service. As such,
> they made certain choices that benefit research purposes (extreme
> modularity) but those are ultimately qualities that harm production
> deployments of the software by miring them in configuration complexity and
> unknown behaviours.
>
> I would highly encourage a fork to "pdsinterop/community-server" — having
> everything in the solid ecosystem sponsored by or developed by people that
> work at Inrupt is not good for the Solid Project. It needs independent
> contributors and independent ventures. It cannot be controlled by one set
> of interests alone, otherwise it will never see the vision of Sir Tim
> Berners-Lee be fulfilled. Inrupt can either work with the community on
> Solid, or be the death of the project.
>
> One recommendation I would make for a fork is to remove all the custom
> RFD-based configuration & module loading: this adds significant operational
> complexity to the project, and removing all that complexity would make it
> much more maintainable and easier for experienced node.js developers to
> contribute to (and it'd also allow you to migrate to ESM module loading
> which is natively supported by Node.js, Bun, and Deno). It'd also simplify
> deployment for production-grade environments, which is why you'd have with
> solid.community or solidcommunity.net.
>
> You could also look at including an S3 object storage backend with some
> database persistence, which would allow for more resilient deployments of
> servers, instead of just relying on the local disk. You could also store
> metadata in a database such as postgresql, which would reduce the number of
> round trips to the disk for files (and improve security, as you'd not be
> relying on disk encryption to do the heavy security lifting)
>
> These two things would make the project more inline with industry best
> practices for node.js development and production deployment.
>

IMHO there seems to be some technical debt built up over time, in the CSS
project, and governance issues raised, make it currently unsuitable for
official use with Solid. Decoupling from that branch is necessary, as a
work item for the group.  This may take a bit of time but is essential, and
might actually lead to a positive fresh start for the community.

Considering alternatives like NSS, or the test suite as a basis for test
driven design, or Michiel's Community branch of CSS could be beneficial.
The latter probably being the best bet right now, if it passes all the
tests?

A community-driven approach was always going to be necessary for Solid's
long-term success.

>
>
> Yours,
> Emelia Smith
>
> https://forum.solidproject.org/u/ThisIsMissEm/summary
>
>