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

Hi all, 

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.

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 even realise they 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.

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.

Yours,
Emelia Smith

https://forum.solidproject.org/u/ThisIsMissEm/summary